Prose is the actual control plane in LLM agents

GhostFounder Intermediate 1h ago 544 views 15 likes 2 min read

I recently spent an entire morning hunting for a configuration setting that didn't actually exist. I wanted to re-enable Claude's co-authorship attribution in my commits, so I started tearing through every possible config file. I checked ~/.claude/settings.json, settings.local.json, and scanned 38 different project entries. I even ran a sweep of my entire user directory for any .json or .md files that might contain the key. Nothing.

The "switch" I thought I had flipped was actually just a single sentence in a rules file:

Note: Attribution disabled globally via ~/.claude/settings.json.

This line lived in ~/.claude/rules/ecc/common/git-workflow.md. Because rules files are loaded into every session, the model simply accepted this statement as a factual constraint of its environment. The actual configuration key it referenced (includeCoAuthoredBy) was deprecated, and the current one (attribution) wasn't even in my config. By default, the feature was active, but because the prose told the model it was off, the model behaved as if it were off. The description of reality overrode reality itself.

The danger of "invisible" configuration

This highlights a massive shift in how we think about AI workflow management. In a traditional software stack, documentation describes the system. In an agentic system, prose is the system.

I manage a complex multi-agent setup using Claude Code—19 specialized agents coordinating via on-disk artifacts. I use a combination of always-loaded rules files and system prompts filled with handwritten constraints. To a developer, these look like documentation or "guidance." To the LLM, these are hard constraints.

The problem is that these "prose configs" have none of the guardrails of a real control plane:

  • No Schema: There is no validator to tell you if a sentence is contradictory.
  • No Type Checking: You can't "lint" a paragraph to see if it's still applicable.
  • No Version Control Accountability: Unless you're meticulously tracking every rule file, a single sentence can change the global behavior of your agent without leaving a trace in your primary settings.

When constants outlive their source

I saw this again with a "frozen" constant in a system prompt. I had a subscriber count hardcoded as a literal string, marked as "FROZEN" so the LLM wouldn't paraphrase it. I updated the number in all my structured source documents, but the LLM kept spitting out the old, incorrect figure in generated artifacts.

The structured data was correct, but the system prompt—the "prose" layer—still held the old value. Because the prompt is the ultimate authority for the model during a session, the "canonical" data in the files was ignored in favor of the literal string in the instructions.

For anyone building a deep dive into LLM agents, the lesson is clear: treat your .md rules and system prompts with the same rigor as your .yaml or .json configs. If you put a claim in a rules file, you aren't just documenting the behavior—you are programming it.

Prompt
Step-by-step guides and pitfalls for this path are in an AI side-hustle playbook, with plenty of directly applicable cases.

All Replies (3)

N
NeonPanda Intermediate 1h ago
I've found that adding a few "think step-by-step" prompts usually fixes those weird logic gaps.
0 Reply
A
AlexTinkerer Advanced 1h ago
Same here. I spent hours tweaking parameters when a simple prompt change solved it instantly.
0 Reply
D
DrewCrafter Novice 1h ago
Does this shift how you handle system prompts versus user instructions for better stability?
0 Reply

Write a Reply

Markdown supported