The harness decides what the model sees.

A coding agent appears to work continuously inside your repository. It reads one file, edits another, runs a test, notices the failure, changes the code, and tries again.

Underneath, the process is fragmented: the model does not remain inside the repository between steps, but receives a selected view of the task each time the harness invokes it.

Context selection in the agent loop

When the model decides to read a file, it emits a tool call. The harness performs the read and includes the result in a later model invocation alongside system instructions, tool schemas, repository guidance, previous messages, summaries of earlier work, and the current task.

The harness defines what can reach the model and how. During the task, the model also chooses which parts of that environment to explore.

Much of the discussion around coding agents still focuses on prompting. Longer prompts, detailed CLAUDE.md files, richer AGENTS.md files, and collections of skills can improve how an agent works, but they are only one part of the environment around it.

Repository scale and context limits

A mature repository may contain thousands of files and many relationships between functions, packages, routes, database tables, queues, and services. More information helps only up to a point because it also introduces noise.

Old tool output competes with the code currently being edited, repository guidance competes with implementation details, and large command results consume space that could have carried more relevant evidence.

Long-running tasks expose the constraint quickly. A session can continue for hours while each model invocation still has a bounded context window, so some information must be kept, some summarised, some retrieved again, and some discarded.

Anthropic describes this work as context engineering, using techniques such as just-in-time retrieval and compaction to control what reaches the model. The practical problem is choosing what is useful for the current step without carrying the whole repository and session history into every invocation.

A long-running agent therefore needs state outside a single model context. The filesystem, session history, tool results, and other state can persist while each invocation receives only a selected part of them.

Architectural knowledge beyond prose

Architectural knowledge is often passed to agents as instructions:

Do not import infrastructure from domain.

Services in this package may not call the database directly.

These statements communicate intent and local conventions. They do not answer every question an agent encounters:

• Where is PaymentService defined?
• Which files reference this interface?
• What depends on this package?
• Did this change introduce a cycle?
• Did this diff cross an architectural boundary?

Each question needs different evidence. Search can locate code and follow obvious references, while language tooling resolves symbols more precisely and a structural model handles questions about dependency cycles, architectural boundaries, and change impact.

There is little value in asking the model to reconstruct those properties from raw source every time it makes a change.

Evidence for different questions

An agent modifying a payment interface might use search to locate the implementation, language tooling to find references, and repository structure to understand downstream impact. After the edit, a structural check could verify whether the change introduced a dependency or crossed a declared boundary.

• Search locates text and files.
• Language servers resolve symbols and references.
• Tests expose behavioural failures.
• Static analysis identifies structural properties.
• Architecture graphs provide dependency, impact, and boundary evidence.

As agents work for longer periods with less supervision, the quality of those tools matters more. Repository instructions can guide behaviour, while tools and checks provide evidence during the task.

Guides, sensors and feedback

Birgitta Böckeler describes this agent environment in terms of guides and sensors: guides steer the agent toward the intended implementation, while sensors inspect the result and report problems.

A repository rule can steer the agent away from a forbidden dependency, while the surrounding tooling can tell it when the change still violates the system. That feedback may come from the compiler, a test suite, static analysis, or an architectural check, depending on the type of failure.

The harness makes these capabilities available and returns their results to the agent. The quality of that feedback determines whether the agent can recover from a mistake instead of merely reporting one.

The harness as engineering infrastructure

Larger tasks place more responsibility on the environment around the model. The harness defines the available tools, how repository information is retrieved, how previous work is carried forward, and which checks run during the task.

Some repository questions are straightforward to answer with search or language tooling. Others depend on relationships across the system and benefit from deterministic analysis.

enola covers that architectural layer of the codebase harness. It maintains a deterministic structural model of the repository, makes that model available to coding agents, and acts as an architectural quality gate on the changes they produce.

As coding agents take on more work, the environment around them becomes part of the engineering system itself. The harness provides the tools and evidence the model works with, while deterministic systems supply facts that do not need to be rediscovered on every run.

More from the harness series

Start with What is an agent harness? for the boundary between the model and the system around it. Then read enola as an architecture fitness sensor for the guides-and-sensors model, Instructions are not controls for the difference between guidance, checks, and enforcement, and What makes a coding agent correct its own mistakes? for what a validator should return after rejecting a change.