AI Coding Agent Core Mechanisms: Context, Persistent Rules, Hooks, Skills, and Subagents

Over the past few years, AI coding assistants have evolved from simple code completion tools into agents that can plan tasks, read and write files, and execute commands. Many developers ask a common question: if both a chatbot and a coding agent are powered by large language models, why can the coding agent complete a full workflow such as reading a codebase, locating a problem, modifying multiple files, running tests, and fixing errors, while a chatbot only handles one question and one answer?

The answer is that the capability of an agent is often determined not only by the underlying model itself, but by the engineering mechanisms built around the model. This is commonly referred to as an agent runtime harness. Among these mechanisms, five are especially important: context management, persistent rules, hooks, skills, and subagent delegation. This article breaks down the internal principles and practical points of each.

1. Context Window: The Agent’s Working Memory

Many beginners assume that an agent’s context is simply what the user says and what the model replies. In fact, conversation history is only one of seven types of content in the context window. A complete context usually includes:

• Conversation history: interaction records between the user and the model;
• File contents: source files that the agent has read or edited;
• Command output: results returned by terminal commands;
• Persistent rules: project-level configurations that remain effective across sessions;
• Automatic memory: learning records that the agent saves across sessions;
• Loaded skills: full instruction text injected when a skill is triggered;
• System instructions: the harness’s own operating rules and tool definitions.

Understanding this distinction is important: when users say the context is full, what is usually displaced is not the conversation itself, but large file contents and command outputs.

What Happens When the Context Is Exhausted

Because a model’s context window has a fixed size, most agents implement an automatic compression strategy. This usually happens in two steps:

1. Remove earlier tool-call outputs first. Content that occupies a lot of space but has low timeliness, such as file-read results and command-execution results, is removed first.
2. Summarize the conversation history. Concrete wording, numbers, and code snippets are condensed into an overview.

The Cost of Compression: Information Loss

Compression is lossy. A rule or architectural decision emphasized repeatedly early in a conversation may be reduced to a vague summary. This is a common reason agents appear to forget instructions in long conversations. It is not necessarily because the model is unreliable, but because information is lost during compression.

There are three practical ways to reduce information loss:

• Write long-term rules into persistent rule files, as described in the next section, instead of leaving them only in the conversation;
• Use explicit compression instructions to manually specify what should be retained, for example, “Focus the summary on interface changes”;
• Save important conclusions as files or comments promptly, so critical information always has an offline copy.

2. Persistent Rule Files: The Project Constitution Across Sessions

If conversation history may be compressed and discarded, constraints that need to be followed long term should be fixed in files. A common practice is to maintain a rule file in the project root directory, usually in Markdown format. It is reinjected when a session starts or after context compression, so it is not affected by summary compression.

A typical rule file can be organized as follows:

# Project Rules
## Technology Stack
- The backend uses a mainstream language and web framework
- The frontend uses a component-based approach
## Coding Standards
- Every function must be accompanied by unit tests
- Mutable global state is prohibited
## Compression Retention Instructions
- During summarization, always retain: database schema changes, API contracts, and security constraints

The “Compression Retention Instructions” section is especially important. It acts as a meta-instruction for the compression algorithm, telling the agent which information must not be lost during summarization and helping preserve key constraints in long sessions.

3. Hooks: A Programmable Lifecycle

Hooks are mechanisms that trigger user-defined logic at key points in an agent’s execution. They turn agent behavior from a black box into an observable and intervenable workflow. Common hook points include:

• Before a tool call: validate arguments, check permissions, or warn about risks;
• After a tool call: format results, record logs, or run automatic formatting;
• When a session starts or ends: load the execution environment or clean up temporary files.

In configuration, hooks are usually described declaratively as what action to execute on which event and under which condition:

{
  "hooks": {
    "before_tool_call": [
      { "matcher": "write_file", "action": "run_lint_check" }
    ],
    "after_tool_call": [
      { "matcher": "edit_file", "action": "auto_format" }
    ]
  }
}

The value of hooks is that they turn team engineering conventions, such as “format before commit” or “run tests before writing files,” from verbal agreements into automated safeguards. They do not rely on the model’s self-discipline, which is important for ensuring consistency and security.

4. Skills: On-Demand Professional Capabilities

Skills are professional modules for an agent. When a task involves a specific domain, such as a particular coding standard or release process, the agent dynamically loads the full instruction text and temporarily gains domain-specific capabilities.

The core idea of skills is to load on demand rather than keep everything in memory at all times. If all domain knowledge were placed in system instructions, the context would quickly become saturated. Skills are injected only when triggered and released after use, enabling efficient use of the context window.

This also explains the agent’s progressive disclosure design: first provide a summary description, then load the full content after relevance is determined. This balances capability and cost, allowing a limited context to support a richer set of capabilities.

5. Subagent Delegation: Divide and Parallelize Tasks

For large tasks, the capacity and attention of a single context window become bottlenecks. Subagent delegation allows the main agent to assign a subtask to an independent subagent. Each subagent has its own context window.

This model provides three clear benefits:

• Context isolation: the intermediate process of a subtask does not pollute the main context; the main agent only receives the final concise result;
• Role specialization: assistants with different responsibilities can be configured for the main agent, such as code review, test writing, and documentation generation, each following different rules and tool sets;
• Parallel processing: multiple independent subtasks can be delegated at the same time, significantly improving overall throughput.

However, delegation is not always better when there are more subagents. If subtasks have strong dependencies, excessive splitting may introduce additional coordination costs. In practice, teams should follow the principle of high cohesion and low coupling, and delegate only when task boundaries are clear.

Conclusion

Context management, persistent rules, hooks, skills, and subagent delegation together form the capability skeleton of modern AI coding agents. Understanding them helps developers shift from passively chatting with an agent to actively designing agent behavior: fixing constraints with rule files, enforcing standards with hooks, extending capabilities with skills, decomposing complexity with subagents, and managing memory with compression strategies. With this methodology, developers can make any intelligent coding tool more reliable and efficient.