Prose Is the Effective Control Plane for LLM Agents

I spent an entire morning searching for a configuration setting that did not exist. I wanted to re-enable Claude's co-authorship attribution in my commits, so I began searching through every possible config file. I checked ~/.claude/settings.json, settings.local.json, and scanned 38 different project entries. I even searched my entire user directory for any .json or .md files that might contain the key. Nothing.

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

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

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

The danger of "invisible" configuration

This reveals a major 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 always-loaded rules files together with system prompts containing handwritten constraints. To a developer, these appear to be documentation or "guidance." To the LLM, they are hard constraints.

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

• No Schema: There is no validator to identify a contradictory sentence.
• No Type Checking: You cannot "lint" a paragraph to determine whether it remains applicable.
• No Version Control Accountability: Unless every rule file is tracked meticulously, one sentence can change an agent's global behavior without leaving a trace in its primary settings.

I encountered the same issue with a "frozen" constant in a system prompt. I had hardcoded a subscriber count as a literal string, marking it as "FROZEN" so the LLM would not paraphrase it. I updated the number in every structured source document, but the LLM continued producing the old, incorrect figure in generated artifacts.

The structured data was correct, but the system prompt—the "prose" layer—still contained the old value. During a session, the prompt serves as the model's ultimate authority, so the literal string in the instructions took precedence over the "canonical" data in the files.

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. A claim in a rules file does more than document behavior—it programs it.