The most underused feature in a command center isn't a new API capability — it's a plain text file. CLAUDE.md and agents.md are control files: they tell the model who it is, what it knows about the project, what it must always do, and what agents it can delegate to. A command center without control files is a command center that resets to zero at every session. Control files are how you make the model's context persistent, structured, and auditable.
Without control files, every session begins with a ritual: paste the project description, remind the model of the tech stack, re-explain the coding conventions, list the sub-agents available. It takes time, it introduces drift, and it's invisible — you can't diff it, you can't audit it, and you can't hand it to someone else. Control files replace the ritual with a structured artifact. The model reads it at session start. Everyone can read it any time.
A developer running a command center for a software project notices that every new session starts with the same setup ritual: paste the project description, remind the model of the tech stack, re-explain the coding conventions, and list the sub-agents available. This takes 3–5 minutes per session and introduces drift — the model gets slightly different context each time, producing slightly inconsistent behavior.
Two months in, there are three different versions of the project description floating around in different session histories. One of them has the wrong tech stack listed. Another omits a key coding rule that was added six weeks ago. The third is closest to current, but nobody is sure it's the canonical one. The developer can't point to a single file and say "this is what the model knows about this project."
When a new team member joins and asks how the command center is configured, there's no answer. The configuration is distributed across dozens of session-opening messages, reconstructed from memory each morning, and never written down in a form that can be reviewed or audited.
The developer knows this is a problem but has been treating it as a workflow issue — "I just need to be more consistent." The actual fix isn't better habits. It's a control file. One canonical CLAUDE.md that the command center reads at every session start. One agents.md that says exactly which agents exist, what they do, and when to use them. The ritual becomes a file. The drift becomes a diff. The configuration becomes auditable.
Control files are the persistent layer of your command center's intelligence. Prompts tell the model what to do in a session. Control files tell it who it is and what it knows across all sessions.
This distinction matters practically: a prompt is consumed and forgotten when the session ends. A control file is read at the start of every session, every time, by every instance. When you change a behavioral rule in CLAUDE.md, it applies immediately to all future sessions. When you add an agent to agents.md, it becomes available across the entire command center. The control file is the single source of truth the prompt cannot be.
What is this system and what does it do? One paragraph, no jargon. This should answer the question a new developer would ask in their first five minutes: what are we building, what problem does it solve, and who uses it? If a new developer reads only this section and nothing else, they should know what the command center is for.
Tech stack, conventions, key architectural decisions, current phase of development. This is the information the model needs to give contextually appropriate responses — not general best practices, but the specific choices this project has made. Include what to use and what not to use, and why, when the "why" is non-obvious.
What the model must always do and must never do in this context. These are not preferences — they are constraints. "Always validate at system boundaries." "Never hardcode credentials." "When the task involves user-facing copy, check the tone guide first." Behavioral rules are the control file's most powerful section: they encode decisions made by humans and enforce them consistently across every session.
When this file was last updated and what changed. One line. This is the audit trail. A CLAUDE.md without a version date is a file that has probably drifted from the system it describes — and you have no way to know when or why. The version note is your forcing function: every time you update a behavioral rule or add an agent, you must also update the version note. That means you can look at any session and know exactly what the model knew when it ran.
Name — the agent's identifier, used in delegation instructions. Role description — what the agent does, in one to two sentences. Not "handles complex tasks" but "reviews authentication and authorization code for security vulnerabilities before any commit touching auth." Tool access — what tools this agent can call. Delegation criteria — the specific condition under which the model should delegate to this agent rather than handle the task inline. Vague criteria ("use for hard tasks") are not criteria — they are deferred decisions that will produce inconsistent behavior.
Persistent context belongs in CLAUDE.md. Session-specific task state belongs in the prompt or chat history. The test: if you started a brand-new session on this project tomorrow, would you need this information? If yes, it belongs in CLAUDE.md. If it's specific to today's task, it belongs in the prompt. Common mistake: putting session-specific task context in CLAUDE.md, which causes the file to bloat and the model to waste context on information that's no longer relevant.
GOVERN asks: what decisions have been made about this AI system, who made them, and how are they enforced? Control files are the answer. CLAUDE.md documents the decisions about what the model knows and how it behaves. agents.md documents the decisions about what capabilities are available and when to use them. Versioning them with dates and change notes creates the audit trail GOVERN requires — you can look at any version and see exactly what the system knew, when, and why.
MAP asks: what is the full context in which this AI system operates? For a command center, that means documenting not just what the model does, but what it knows (CLAUDE.md) and what capabilities surround it (agents.md). MAP requires that this documentation be current — which is why the version note is non-negotiable. An undated CLAUDE.md fails the MAP function.
Systems evaluation applied to control files means asking: is CLAUDE.md an accurate model of what the system actually needs to know? Is agents.md an accurate model of what agents actually exist and how they behave? Gaps between the control file and the system it describes are evaluation findings — not minor inconsistencies, but risks that will produce unexpected model behavior.
Art. 4 requires that AI systems be used with sufficient understanding of how they work. Control files are a literacy tool: they make the model's context visible and auditable to anyone who reads them. A command center with well-maintained control files is a command center that can be understood, reviewed, and handed off. One without them is a black box that only its original operator understands.
Writing control files badly is worse than not writing them at all. A bloated CLAUDE.md that mixes persistent context with session-specific state wastes tokens and produces confused responses. An agents.md with vague delegation criteria produces an agent topology that exists on paper but doesn't influence behavior. Three design decisions, made before you open a text editor, determine whether the control files work.
Bloat creates noise. The test: if a new developer joined the project tomorrow and needed to understand what this command center knows, what would they need to read? That's your CLAUDE.md. Not everything you could say about the project — everything they must know to work effectively in it. Apply the test ruthlessly: if a piece of information would only matter for a specific task, it belongs in the prompt for that task, not in the control file.
When should the model handle something inline vs. delegate to an agent? The agents.md entry should state this explicitly — not "use this agent for complex tasks" but "delegate when the task requires tool X or when the output will be used by another agent" or "delegate whenever the code change touches the authentication module." The delegation criterion is a rule the model can apply consistently, not a quality judgment it has to make. Quality judgments produce inconsistent delegation. Rules produce consistent delegation.
Control files go stale. The version note is what prevents silent drift: every time you update a behavioral rule or add an agent, you must also bump the version and write one line explaining what changed. This is the audit trail NIST GOVERN requires — and it's also a practical forcing function. If you find yourself reluctant to update the version note because it feels like overhead, that's a signal that you're treating the control file as a one-time document rather than a living artifact. The version note turns the control file into something that must be maintained rather than something that can be forgotten.
In the lab, you'll apply all three decisions. The AI will review your control file drafts and check whether each section passes the minimum viable test, has explicit delegation criteria, and carries a version note. It won't accept vague entries. It will ask for specificity on each field before moving on. The goal is a control file pair that actually works — not one that looks reasonable on paper but resets to noise after three months of use.