How AI Coding Agents Work: Context, Rules, Hooks, Skills, and Subagents

As large language models evolve rapidly, terminal-based AI coding agents have become a standard part of many developers’ toolkits. The value of these tools lies not just in the model itself, but in the “execution framework” built around it—including context management, rule injection, automation hooks, skill extensions, and task delegation. Understanding how these mechanisms work internally is the key to using these tools effectively and adapting them to your own models.

This article walks through five core concepts to explain how these coding agents actually work under the hood.

1. What’s Actually Inside the Context Window

Many people think of context as just “what I said and what the model replied.” In reality, a typical agent session’s context window is composed of seven types of content:

1. Conversation history: the back-and-forth between the user and the model—the most intuitive part, but also the one that bloats fastest;
2. File contents: source files the agent has read or edited, which often consume a large number of tokens;
3. Command output: results of terminal commands such as build logs or test reports, which can easily run to thousands of lines;
4. Project-level rules: persistent project conventions that get injected into every session;
5. Automatic memory: records the agent saves across sessions, such as project structure preferences and frequently used commands;
6. Loaded skill instructions: the full instruction text injected when a skill is triggered;
7. System instructions: the agent framework’s own operating rules and tool definitions, including available tools and calling formats.

Understanding these seven components has a direct practical benefit: when the agent “misbehaves,” you can first identify which category of content is at fault—unclear rules, conversation history losing details during compaction, or a conflict between system instructions and project rules.

2. When Context Runs Out: Compaction and Its Cost

The context window is a finite resource, and long sessions inevitably trigger compaction. The mainstream strategy works in two steps:

Step one: purge large, low-value blocks. File read results and command outputs—which take up space but quickly lose relevance—are removed first. The logic is simple: a test log from a few hours ago has little marginal value for the current task, and can be regenerated by re-running the command if needed.

Step two: summarize the conversation history. Specific wording, numbers, and code snippets are condensed into high-level summaries.

Compaction inevitably loses information. For example, coding conventions you emphasized in round three, or the architecture decision settled in round five, may be reduced to a vague one-line summary with all the details gone. This is the real reason agents “forget” earlier instructions in long conversations—the model didn’t get dumber; the original text carrying those instructions was compacted away.

There are two effective countermeasures:

Option 1: Put persistent rules in a rules file, not in conversation. Conventions that need to persist across turns—code style, directory structure, build commands—belong in a project-level rules file (naming varies across tools, but it’s essentially a Markdown file at the project root). Rules files get re-injected into context after every compaction, unaffected by summarization. You can also add a “compaction instructions” section to the rules file, explicitly telling the agent what must be preserved verbatim during compaction—for example, “the current branch name, the unfinished TODO list, and confirmed API contracts.”

Option 2: Trigger targeted compaction proactively. Most agent tools offer a manual compaction command that lets you specify what to keep. Rather than passively waiting for the system to compact hastily near the limit, run it proactively after completing a milestone:

# Compact proactively and declare what to keep
/compact Focus on the current database migration design decisions and pending TODOs

This turns compaction from an “uncontrollable risk” into a “controlled cleanup action.”

3. Rules Files: Your Project’s Persistent Memory

Rules files offer the best return on investment in this whole system. In practice, organize them in layers:

• Repository level: placed at the repo root and version-controlled, shared by the whole team. Content covers general conventions such as language versions, directory standards, and commit formats;
• Directory level: placed in specific subdirectories and applied only when working on files in those directories. Ideal for module-specific conventions, such as “tests in this directory must follow a fixed framework-specific pattern”;
• User level: placed in your home directory for personal preferences, not distributed with the repo.

One important principle when writing rules files: write constraints and facts, not vague advice. Statements like “code should be clean and elegant” have no execution value. “All API errors must be returned through the unified error-wrapping function; throwing bare exceptions directly is forbidden” is an instruction the model can actually act on. Rules files also consume context, so keep them concise—don’t dump everything in.

4. Hooks: Enforcing Automation at Critical Points

Rules files are essentially “advice”—the model may follow them or drift away. Hooks are “enforcement”: they run pre-configured shell commands deterministically at specific points in the agent’s lifecycle. Common trigger points include:

• Before tool calls: intercept and inspect commands or file edits before the agent executes them. A typical use is blocking dangerous operations, such as writes to production configuration files;
• After tool calls: automatically trigger formatting or static checks after a file is modified, ensuring that no matter how the model edits the code, the result on disk meets team standards;
• Session events: such as sending a notification when a task completes—useful for unattended long-running jobs.

A simple illustrative configuration:

{
  "hooks": {
    "after_file_edit": [
      { "command": "formatter --write $FILE" }
    ],
    "before_bash": [
      { "command": "guard --deny 'rm -rf' 'git push --force'" }
    ]
  }
}

The value of hooks is upgrading “soft constraints” into “hard guarantees”—a key tool for safeguarding quality baselines in team settings.

5. Skills and Subagents: Extension and Delegation

Skills are instruction packages loaded on demand. Wrap the complete playbook for a type of task (such as “how to release a version” or “how to write a database migration”) into a standalone document that the agent loads and injects only when it determines the current task matches. This “load on demand” design avoids stuffing every piece of guidance into the context upfront, making it an important lever for controlling token costs. Skills are ideal for capturing repetitive process knowledge within a team.

Subagents solve a different problem: pollution of the main context and dilution of attention. When a subtask is highly independent and generates lots of intermediate output (such as “search all call sites globally” or “review this module”), you can delegate it to a subagent with its own independent context. The subagent runs in isolation and returns only its final conclusions to the main agent. This brings two benefits: massive intermediate results never crowd out the main context, and each subagent can be configured with its own system prompt and tool permissions for separation of duties—for example, a read-only subagent for code investigation with no write access.

6. Wrapping Up

Together, these mechanisms form a clear layered system: rules files provide persistent constraints, hooks provide deterministic guarantees, skills provide on-demand knowledge extensions, subagents provide isolated execution spaces, and context management is the foundation everything else runs on. This framework-level design is largely model-agnostic, so teams can pair it with models from their preferred providers to build efficient, controllable AI coding workflows. Mastering these five concepts is the dividing line between merely using AI coding tools and using them well.