The Standards Every Agent Inherits

The Standards Every Agent Inherits are the persistent instructions and conventions an agent absorbs before it reads a task, and they decide most of what a reviewer will later argue about. Chapter 2 wrote the per-task intent. This chapter writes the part that never changes per ticket and therefore has to live somewhere else.

Key takeaways

• The standing context layer exists whether you author it or not. An unwritten one is inferred from whatever files the agent happens to read, which means your worst module is a style guide.
• DORA's 2025 report found, with a high degree of certainty, that AI's positive influence on both individual effectiveness and code quality is amplified where internal data is accessible to AI tools. These are estimated survey effects with 89% credible intervals, not measured delivery outcomes.
• Faros AI, which sells engineering-productivity analytics, argues the fix is upstream: raise quality at the point of authoring rather than deploying more reviewers, and its conclusion supports that position.
• Intent is not recoverable from the current state of a codebase. Faros AI's phrasing is that the codebase is a point in time, so decisions and their reasons have to be written down separately.
• Every human review comment that generalises should become a rule in the layer. A comment fixes one pull request. A rule fixes the next hundred.

Read this immediately after Chapter 2, since the two together are the authoring half of the book, and before Chapter 6, which cannot decide what a gate checks until this layer exists. The mechanics of assembling and budgeting that context are the subject of the context-assembly argument in a companion volume.

Two engineers on the same team ship two changes to the same service on the same afternoon. One uses the repository's result type for errors. The other throws.

Both were written by the same model. Both passed review, by different reviewers, both of whom were reading for correctness and had no reason to litigate a pattern.

Nobody wrote down which one was right. The codebase contains both patterns, so the agent saw both and chose by proximity. That is the standing context layer working exactly as configured, which is to say not configured at all.

The layer exists whether you wrote it or not

An agent needs context to produce code that fits. If you do not supply it, it derives it, and the derivation is a sample of whatever files ended up in its window.

That has a consequence worth stating bluntly. In the absence of written standards, your least well-maintained module is a style guide with equal authority to your best one. Age confers nothing. Volume confers a lot.

It gets worse with adoption, not better. Each generated change becomes precedent for the next, so an unwritten convention drifts in whichever direction the most recently merged code pointed. This is how a codebase acquires four ways of doing pagination in a quarter.

The layer is therefore not an optional artifact. It is a control you either operate or leave to chance.

One clarification, because teams get stuck on it. Where these instructions physically live is a tool question and it changes every few months, so I would not build an organisational process around a filename. The content is tool-independent and outlives any of them. Write it as documents in the repository, versioned with the code they govern, and let whichever harness you use load them.

Standing context, defined against the per-task specification

Standing context is the set of instructions, standards and stated intent that apply to every task in a repository, are versioned with the code, and are read by an agent before the task description.

Two properties separate it from a specification. It is durable, changing on the timescale of architectural decisions rather than tickets. And it is general, phrased as a rule about a class of situations rather than a requirement for one change.

The practical test for whether something belongs here is a question. Would you write this sentence into more than three tickets. If yes, it is standing context, and putting it in tickets means it will be missing from the fourth.

Spec Kit's documented shape puts the same idea in tooling terms, describing artifacts that give the agent structured context instead of ad-hoc prompts. The organisational version is that structured context has an owner.

The two DORA findings that bear directly on code quality

DORA's State of AI-assisted Software Development 2025, published 24 September 2025 and fielded from 13 June to 21 July 2025 with 4,867 respondents and 78 in-depth interviews, contains seven named AI capabilities. Two of them are about the context an organisation gives its tools.

The first is AI-accessible internal data, which DORA measures as a single factor from four indicators covering whether tools have access to internal company information, whether responses use it as context, how often people put internal information into prompts, and how often they use AI to retrieve it. DORA reports, with a high degree of certainty, that where organisations have AI-accessible internal data, AI's positive influence on individual effectiveness is amplified and AI's positive influence on code quality is amplified.

The second is healthy data ecosystems, measured from three indicators covering the quality of internal data sources, their accessibility, and how far they are siloed. DORA reports that where those are healthy, AI's positive influence on organisational performance is amplified.

Both are estimated standardised effects from a self-reported survey, drawn with 89% credible intervals, and DORA does not present them as measured delivery outcomes. DORA's own gloss is the part I would take to a budget conversation: maximising the individual effectiveness and code quality benefits of AI may require a deeper investment than simply procuring AI licences.

Intent lives in the history, not in the current state

Faros AI, which sells engineering-productivity analytics and whose recommendations consequently point at building visibility, makes one argument in its 2026 report that stands on its own logic. An agent cannot derive intent from the current state of a codebase, because the codebase is a point in time.

That is correct and it is why architectural intent has to be written rather than inferred. The current code shows what exists. It does not show what was tried and abandoned, which constraint forced an awkward boundary, or which pattern is deprecated and awaiting removal.

So the layer needs a section that reads like a decision record rather than a style guide. Three things per decision are enough. What we chose, what we rejected, and the condition that would make us revisit.

Without that, an agent will helpfully modernise the awkward boundary that exists for a reason. It will do it well, with tests, and the review will take a day.

Every human review comment becomes a rule

The highest-leverage habit in this chapter costs nothing and almost nobody does it. Faros AI recommends that when a human reviewer identifies something that should change, the finding feeds back into the agent's harness as a generalised rule preventing the same issue in future pull requests.

Adopt that as a standing expectation on reviewers, with one qualification. Not every comment generalises, and forcing it produces a bloated instruction file nobody trusts.

The filter I would apply is whether you have made the comment before. First time, it is a comment. Second time, it is a rule. Third time, it should have been a lint rule or a test rather than prose, which is Chapter 4's territory.

There is a measurable payoff to watch. Faros AI reports review comments per pull request up 25% and comment length up 22.7%, while noting its figures do not distinguish human from agent comments. Human comment volume falling while agent comment volume holds is the shape of this working.

Four layers, one owner each

The table below is the compact form, and the owner column is the part that decides whether any of it stays true.

Two things about that table are deliberate. Every row has a single named owner rather than a team, because an unowned instruction file is a folklore file within two quarters. And every row has a review trigger, because the failure mode is not wrongness but staleness.

The conventions row is the one to start with, and it is also the one with the shortest route to being true. Change it in the same pull request that changes the pattern, treat a contradiction between the document and the code as a bug, and the layer stops drifting. Everything else in the table can wait a quarter.

A worked example, composited and labelled

The details here are composited from ordinary production shapes rather than one system, and the shape is exact.

A payments team keeps getting the same three review comments on generated code. Money is handled as a float somewhere. New endpoints skip the idempotency key. Retries are added around calls that are not safe to retry.

Each comment is polite, correct and takes a senior engineer fifteen minutes to write with an explanation. Across a quarter that is a meaningful share of the most expensive review capacity the team has, spent on three sentences.

The fix is not more review. Three rules go into the standing context: monetary amounts use the integer minor-unit type, every state-changing endpoint requires an idempotency key before it can be merged, and retries are only permitted around operations annotated as idempotent. Two of the three also become checks, because prose is weaker than a failing build.

The comments stop. What replaces them is a different and better argument about whether a particular operation really is idempotent, which is work only a person can do.

The objection: instructions get ignored, by people and by models

This objection is the honest one, and I have watched it be true. A long instruction file gets partially followed, and a rule buried on page four of a document has roughly the authority of a suggestion.

Three responses, in order of how much they help. Keep the layer short enough to be read in full, which in practice means ruthless deletion of anything decorative and a hard limit you actually enforce. Promote any rule that can be mechanically checked out of prose and into a lint rule, a type, or a test, because a check does not need to be remembered. Reserve the prose for the things no check can express, which is mostly intent and the reasons behind awkward decisions.

Then measure whether it is working rather than believing it. Faros AI suggests watching work restarts, defined as a task returning to in-progress after moving on, as a signal about the quality of the context agents are operating with. Rising restarts alongside rising adoption point at the authoring stage rather than at the people.

The last part of the answer is the one that matters commercially. Faros AI states that the instinct to tighten review is the wrong response, and that the goal should be fewer mistakes arriving at review rather than more humans deployed to catch them. I agree with that, and this chapter is where the agreement gets spent. Chapter 6 explains why review triage is still necessary while this fix is landing.

Chapter summary

Every agent inherits a standing context before it reads a ticket, and that layer exists whether or not anybody authored it, because an unwritten convention is inferred from whatever files happened to be in the window, which gives your worst-maintained module the same authority as your best. Standing context is durable and general, distinguishable from a specification by one test: if you would write the sentence into more than three tickets, it belongs here. DORA's report of 24 September 2025, from 4,867 respondents, found with a high degree of certainty that AI's positive influence on individual effectiveness and on code quality is amplified where internal data is accessible to AI tools, and that its influence on organisational performance is amplified where the data ecosystem is healthy, both as estimated survey effects with 89% credible intervals rather than measured delivery outcomes. Architectural intent has to be written because the current state of a codebase cannot express what was rejected or which constraint forced an awkward boundary, so each decision needs what was chosen, what was rejected and the condition that would reverse it. Human review comments should be promoted into rules on their second occurrence and into checks on their third, since prose is the weakest available enforcement. The layer has four parts, conventions, architectural intent, secure coding standards in the sense of NIST SP 800-218 practice PW.7, and test requirements, each with one named owner and an explicit review trigger, because staleness rather than wrongness is the failure mode. And the honest objection, that instructions get ignored, is answered by keeping the prose short, promoting anything checkable out of prose, and watching work restarts as the signal.

Prose can be ignored and a failing build cannot. Chapter 4 is Tests as the Contract With the Agent, which is where the parts of this layer that can be executed stop being advice.