Context Governance for AI Coding Agents: Practices for Collaboration

AI coding agents do more than send chat history to a model. Their results depend on what the context contains, when content is trimmed, which constraints must survive across turns, and how complex tasks are divided among different roles. Understanding these mechanisms has more lasting value than memorizing the commands of any single product.

1. What Goes Into the Context Window

Many developers think of context as “what I asked and what the model replied.” Conversation history is only one part of it. In engineering practice, the context usually includes at least seven kinds of material:

1. Conversation history: the user’s goals, clarifications, confirmations, and model replies.
2. File contents: source code, configuration, and documentation fragments that were read or modified.
3. Command output: results from builds, tests, and static checks.
4. Project rules: persistent instructions stored in the repository and reloaded in every session.
5. Cross-session memory: preferences and pitfalls the agent has accumulated from earlier tasks.
6. Activated skills: complete operating instructions injected when a certain type of task is triggered.
7. System instructions: the tool definitions, safety boundaries, and calling conventions of the agent framework itself.

These seven types compete for the same limited window. Files and command output tend to be large and short-lived. Rules and system instructions are small, but if they are lost, later behavior drifts in a systematic way. The first principle of context management is therefore not to include as much as possible. It is to organize information in layers, based on how quickly it goes stale and how strongly it constrains behavior.

2. What Happens When the Window Fills Up

Common strategies work in two steps. The first step clears early tool results, such as large file reads, long logs, and old output that later edits have overwritten. These are removed from the window first. The second step summarizes the remaining conversation, condensing specific wording, values, and code snippets into outlines.

Compression always loses detail. A naming convention emphasized in the third turn, or an interface boundary agreed on in the fifth, may shrink to a single sentence saying the architecture was discussed. This is the main reason an agent suddenly “forgets” instructions in a long conversation. The model has not become less capable.

The fix belongs in the mechanism, not in repeated verbal reminders:

• Constraints that must hold across turns should go into a project rules file, not stay only in the chat. Rules are re-injected after compression, so a summary does not overwrite them.
• Add a “preserve on compression” section to the rules. List the interface contracts, prohibitions, current milestone, and open questions that must survive.
• When a phase of work is complete, trigger a focused compression on purpose and state what to keep. For example, keep only interface changes and failing test cases, and drop debugging branches that are closed.
• Sync key decisions into short documents in the version control repository. This turns code and its documentation into retrievable facts, instead of leaving decisions only in session memory.

3. Project Rules: Moving Constraints Out of the Conversation

Project rules suit content that is stable, reusable, and applies to every task: tech stack boundaries, directory conventions, test commands, code style, modules that must not be changed, and a pre-commit checklist. They are not suited to one-off debugging steps, temporary assumptions, or large blocks of pasted source code. Otherwise, the rules themselves crowd out the window.

A usable rules file should be short and firm:

• Goals and non-goals: what this iteration does, and what it explicitly does not do.
• Constraints: language version, dependency policy, and security and compliance red lines.
• Verification: how to build, how to run the minimal test suite, and which log to check first when something fails.
• Preserve-on-compression items: decision records, unfinished work, and key identifiers.

Changes to the rules should go through code review. Verbal additions can apply to the current conversation, but only content merged into the rules file should be treated as a long-term contract.

4. Hooks: Inserting Deterministic Actions at Key Points

Hooks are checks or scripts that run at fixed points in the agent’s lifecycle, such as session start, before and after tool calls, after a file is written, and before a task ends. They handle cases where relying on the model’s own discipline is not enough.

Typical uses include formatting code automatically after writing it, running static checks before a commit, blocking changes to sensitive directories, and writing test failure summaries back into the task notes. Hooks should be idempotent, make failures visible, and have a time limit. Putting all business logic into hooks makes troubleshooting hard. Hooks suit guarding a process, not replacing design.

The following illustrative rules use plain constraint statements, not the proprietary syntax of any specific tool:

After modifying source code: run the project's formatting and minimal test commands
If tests fail: stop spreading changes further, and first summarize the failing assertions
Prohibited: modifying secret files, and lock files unless the task explicitly requires it

5. Skills: Packaging Repeated Tasks as Triggered Instructions

A skill is a set of operating instructions loaded on demand. When it is not triggered, it does not enter the context. When it is triggered, its complete instructions are injected. This avoids carrying the full manual on every task, and it keeps complex procedures from being compressed into vague sentences.

Good candidates for skills include a checklist for adding an API endpoint, steps for a database schema change, a pre-release verification list, and a template for a defect review. Each skill should state its trigger conditions, inputs, steps, completion criteria, and fallback actions on failure. Skill text should also be concise, because once it is loaded, it occupies part of the window.

The division of labor is as follows. Rules are always present and describe global boundaries. Skills appear with a task and describe local procedures. Neither should copy large blocks of source code, because the repository is the source of truth for code.

6. Delegating Subtasks and Executing Plans

When a single agent handles research, code changes, test runs, and summary writing within a very long context, these activities tend to contaminate each other. A safer approach is to separate planning from execution and delegate by role:

• The planning role produces only the task breakdown, risks, and acceptance criteria. It does not modify files directly.
• The implementation role changes files within a limited scope and reports the diff and its reasoning.
• The verification role judges pass or fail based only on test and static check results. It does not rewrite requirements.
• The summary role merges the conclusions and writes the decisions that must be kept back into the rules or task documents.

When delegating, limit each subtask’s context to the relevant files, the relevant failure logs, and the acceptance criteria. Subtasks should return a short conclusion with the location of the evidence, not a full copy of the raw output. This way, the main session serves as an index, and the details stay in the repository and logs.

The plan-and-execute model also requires that plans can be revised. If execution reveals that a premise of the plan is wrong, return to the planning role to update the plan. Do not keep adding patches on top of a faulty premise.

7. Using Memory, Retrieval, and Web Information

Cross-session memory suits stable preferences and recurring pitfalls. It should not store secrets, one-off experiment data, or unconfirmed guesses. Memory entries should be deletable and overwritable, and each should note its scope of applicability.

Retrieval-augmented generation suits looking up evidence in repositories, documentation, and failure knowledge bases. Retrieved results are evidence, not instructions. When they conflict with project rules, the rules and the current code take precedence. Public external material can supplement concepts and general practices. Before adopting it, however, verify it with the repository’s tests, so outdated approaches do not end up in the code.

8. A Practical Sequence of Steps

1. Write the project rules and verification commands first, then let the agent start changing code.
2. Turn repeated procedures into skills, and walk through each one manually the first time it is used.
3. Use hooks to enforce formatting, testing, and protection of sensitive paths.
4. When a task grows long, compress proactively and specify what to keep.
5. When a task spans many areas, split it into planning, implementation, and verification, and limit what each role can see.
6. Before each merge, move the real decisions from the chat history into repository documentation.

Following these six steps shifts an AI coding agent from “occasionally writing code quickly” to “stable constraints, reviewable processes, and failures that are easy to locate.” Context, rules, hooks, skills, and delegation are not interchangeable features on a checklist. They form one engineering control system that keeps the limited window focused on the information the current decision actually needs.