Day 08: Context Builder for AI Coding Agents

Previous article：Transcript Logging for AI Agent Runs
Next article：Context Explorer: Debug AI Agent Prompts and Token Usage
中文版：Context Builder：AI Coding Agent 上下文构建器

Introduction

Day 08: assemble system instructions, user requests, tools, rules, and project snippets into inspectable context. This chapter keeps the implementation deliberately small: the point is to make one boundary explicit, testable, and easy to inspect before adding more autonomy. Day 08 diagram

Context is a deliberate assembly step

A coding agent is more than a model response. It needs a runtime that can turn a request into controlled work, preserve the intermediate state, and explain what happened afterwards. Day 08 focuses on that runtime boundary instead of hiding it behind a single prompt.

system instructions + user request + rules + snippets + tool schemas → model request

Structured parts and sources

The implementation uses explicit data structures and narrow interfaces. The model proposes the next step; the harness owns validation, execution, limits, and structured results. That separation lets the same capability work in a CLI today and in a richer product surface later.

Represent each context contribution as a part with a source.
Keep the system prompt, rules, tools, and file snippets separately measurable.
Make the final request reproducible from structured input.

Budgets, snippets, and rules

Reliability comes from treating failure paths as normal paths. Inputs are bounded, unsafe or malformed requests produce recoverable errors, and the run records enough evidence to let a developer understand the decision. This is especially important when later steps can touch a real workspace.

npm run dev -- --context-report "build context for this repo"

System prompt          system        ~1,023 tokens (context-builder)
User request           conversation  ~7 tokens (argv)
History summary        conversation  ~11 tokens (context-builder)
Tool definitions       tools         ~391 tokens (tool-registry)
Project snippets       files         ~492 tokens (README.md, package.json)
Conversation           conversation  ~2,394 tokens (agent-loop)
Agent steps            tool-results  ~1,701 tokens (agent-loop)

User task
  -> system instructions
  -> project rules
  -> selected files
  -> tool schemas
  -> conversation summary
  -> recent messages
  -> model request

Making context observable

With this layer in place, later chapters can add capability without weakening the boundary: tools can be registered and observed, context can be measured, writes can require approval, and every run can be replayed. The result is not a general autonomous system; it is a compact harness whose behavior remains understandable.

Key takeaways

Build the execution boundary before adding more tools or model freedom.
Keep model intent separate from runtime authority.
Make limits, validation, and failure results visible.
Use structured observations to support debugging and future extensions.

Demo

The accompanying implementation and runnable examples are available in the cli-harness repository.