AI Coding-Agent Architecture: The Layers Between a Model and Production

A Coding Agent Is Not Just a Model — It Is a Stack

The word “agent” hides a lot of machinery. A model, on its own, is a function: text in, text out. It cannot read your repository, run your tests, open a pull request, or check whether the change it proposed obeys a decision your team made two years ago. Everything that turns a model into something that ships code is built around the model, not inside it.

Anthropic’s guidance on building effective agents makes the same distinction from the model builder’s side: the foundational block is “an LLM enhanced with augmentations such as retrieval, tools, and memory,” and an agent is that model “using tools based on environmental feedback in a loop.” The model proposes. The system around it acts, observes, and decides what to do next.

Once you accept that a coding agent is a stack rather than a model, the useful question changes. It is no longer “which model is best?” It is “which layers do I have, and which am I missing?” Most teams have more of the stack than they realize, and are missing the same one or two layers as everyone else.

The Layers, Bottom to Top

Read the stack from the ground up. Each layer depends on the one below it and hands a well-defined job to the one above.

• The model. This is the generator. Given a task and some context, it produces candidate code: a diff, a new file, a shell command, a plan. It is remarkably good at this and remarkably indifferent to whether the result fits your system. The model has no memory of your architecture and no stake in your conventions. It generates; it does not govern.
• The harness / execution layer. This is what makes the model useful. It assembles context (which files, which errors, which docs), exposes tools (read, edit, run tests, search), runs the model in a loop, and contains the work in a sandbox so a bad step is recoverable. The harness is the difference between a chat window and something that can actually operate on a codebase. We treat this layer in depth in what harness engineering is; the short version is that a better harness makes a model more capable and more reliable, and it is where a great deal of current engineering effort goes.
• The governance layer. This is the layer that checks a proposed change against your recorded architectural decisions before the change lands. It does not generate code and it does not run tools. Its single job is to answer one question deterministically: does this diff violate a decision we already made? If the agent tries to add a second HTTP client, reach across a service boundary, or ignore a naming convention, the governance layer is what catches it — at generation time, not in a human review three days later. See governance layers for AI coding assistants for where this sits in a real stack.
• The intent layer. This is the durable material the governance layer enforces: the architecture decision records (ADRs), the engineering standards, the approved technologies, the project constraints. It is the answer to “what did we decide, and why?” expressed as data rather than prose. When intent lives as executable architectural intent instead of a wiki page nobody reads, the governance layer has something concrete to check against. Models change; this layer does not, which is the whole point of treating intent as the stable asset.

Each layer has a job it owns and a set of jobs it deliberately refuses. Confusing the boundaries is the common failure: asking the model to remember your architecture, or asking the harness to enforce it, puts a responsibility on a layer that has no mechanism to carry it.

Where Most Tools Stop

The industry has invested heavily in the bottom two layers, and it shows. Models are more capable every quarter. Harnesses have improved just as fast: better context assembly, better tool interfaces, tighter loops, safer sandboxes. This is real progress. A team with a strong model and a strong harness can hand an agent a genuine task and get a working result back.

But almost every tool stops at the harness. The pitch is capability: this agent can do more, do it faster, do it with fewer interventions. And capability is worth having. The problem is that capability is not the same as consistency. A more capable agent produces more code, more quickly, across more of your system — which means a more capable agent produces architectural drift more quickly too, unless something above the harness is checking its output against your decisions.

This is why harness work, on its own, reaches a ceiling. We have written before that harness engineering still needs governance and that the shift from prompt engineering to harness engineering moved the frontier without closing it. The harness controls how the agent works. It does not control what the agent is allowed to build.

Why the Governance and Intent Layers Are Usually Missing

These two layers are not missing because they are unimportant. They are missing because, until recently, humans carried them implicitly.

On a human team, architectural intent lived in senior engineers’ heads and surfaced in code review. Someone who knew the system would look at a pull request and say “we don’t add HTTP clients, use the shared one” or “that service can’t read the billing tables directly.” The governance layer was a person. The intent layer was their memory. It worked, slowly, because human throughput was low enough that a human check per change was affordable.

Agents break that arrangement in one specific way: they raise the rate of change past what a human governance layer can keep up with. When an agent opens fifteen pull requests in an afternoon, the reviewer who used to hold the architecture in their head becomes the slowest part of the system, and the temptation is to wave changes through. The intent that used to be carried informally now has to be made explicit — recorded as data, retrieved automatically, and checked by machine — because the informal carrier no longer scales. This is the core argument for governance infrastructure: at agent velocity, the rules have to live somewhere the machine can read them.

How the Layers Compose

The four layers are not a pipeline you run once. They compose into a loop that runs on every proposed change. The model proposes, the harness executes, governance checks against intent, and only compliant changes land. Spelled out, the loop is deliberately boring:

1. Record each architectural decision as structured data with its constraints — the intent layer — not a paragraph in a doc.
2. Retrieve the decisions relevant to the change the agent is about to make, whichever model the harness is driving.
3. Check the proposed edit against those decisions deterministically — same change, same verdict, independent of which model ran.
4. Reject violations before the change lands, not at review time.
5. Return the specific decision that was violated, so the agent can retry compliantly instead of guessing.

Because the check is independent of the model, the harness can swap models, add specialists, or upgrade to next quarter’s frontier release, and the governance verdict stays the same. The layers compose precisely because their responsibilities do not overlap: the harness never has to know the rules, and the governance layer never has to know how the code was generated.

A Concrete Pass Through the Stack

Take one decision your team actually made: the billing service owns the billing tables, and every other service reaches billing through its API. No direct database reads. It is written down as an ADR, and it is the kind of boundary that quietly erodes the moment someone finds it convenient to ignore.

Now watch a change move through the stack. A feature request asks the reporting service to show a customer’s recent invoices.

• Model. The model, given the task and the reporting service’s code, writes the most direct thing it can: a query straight against the billing.invoices table. It is correct code. It runs. The model has no idea the boundary exists.
• Harness. The harness assembles the context, lets the model edit the file, runs the tests, and the tests pass — because the direct query works. A harness optimized purely for capability would report success here. The change looks done.
• Governance. The governance layer retrieves the billing-boundary ADR, checks the diff, and finds a direct read of a table owned by another service. It rejects the change before it lands and returns the exact decision that was broken.
• Intent. The decision it checked against was not invented on the spot. It was the recorded ADR — billing owns its tables, others use the API — sitting in the intent layer, ready to be retrieved.
• Retry. Handed the specific violated decision, the agent rewrites the change to call the billing service’s API. That version passes governance. It lands.

Nothing here required a smarter model. It required a layer above the harness that knew the boundary existed and refused to let a locally reasonable change cross it. Without that layer, the direct query merges, the boundary erodes by one, and the next agent that finds the shortcut has precedent to follow.

Architecture Is What Makes Agent Output Trustworthy at Scale

It is tempting to believe the trust problem is a model problem — that a good-enough model would simply stop making these mistakes. It will not, because the mistakes are not failures of intelligence. They are failures of information: the model was never told what your team decided, and the harness had no mechanism to enforce it even if it had been.

What makes agent output trustworthy is not a bigger model. It is a complete stack — a model to generate, a harness to execute, a governance layer to check, and an intent layer that holds what “correct for us” means. The first two layers are arriving fast on their own. The top two are the ones teams have to build deliberately, because the humans who used to carry them cannot keep pace with the machine below. Get all four in place and agent velocity stops being a liability. That is the architecture worth building toward.