In short: Agents change systems based on what they can read about them. In most organisations that context is incomplete, stale and owned by nobody, and adding more of it tends not to help. A governed context supply turns the CTO's inventories into context agents can read, with named owners, one access layer and freshness driven by the delivery pipeline. Its limit is context capacity.

What does an agent know about your systems on its first day?

In February 2026, researchers at ETH Zurich published the first rigorous test of repository context files, the AGENTS.md files and their equivalents that agent vendors recommend placing in every repository. Across several coding agents and models, the files tended to reduce task success compared with giving no repository context at all, while raising inference cost by more than 20%. Files written by the repository's own developers did slightly better, with a marginal gain that still came at a higher cost. The authors concluded that files written by people should describe only minimal requirements.

The finding runs against the usual advice to give agents more context. Agents follow what they read faithfully, so context that is unnecessary, outdated or wrong becomes a constraint they obey.

Inside an enterprise, an agent changing a service needs to know what depends on it, who owns it, what else is changing around it and which rules apply. The useful question for a CTO is who keeps that context true.

Why is context a supply with a capacity?

Context behaves like any other supply in the production system. People and tools produce it, it ages as systems change, and it has a limit. This piece calls that limit context capacity: the rate of change an organisation can keep accurately described, owned and current for the agents acting on it.

Verification capacity and integration capacity measure the Absorption Gap at stops on the output side. Context capacity measures it on the input side, where the Second Absorption Gap opens. Agents raise the volume of change, and every change alters something the next agent will need to read.

Redis's 2026 survey of IT and AI infrastructure leaders suggests how far most organisations are from that capacity. Among organisations at the earliest stage of maturity, only 2% said their agents could reliably navigate across systems, and across all respondents 69% now rank that failure as more dangerous than a hallucination. Redis sells context infrastructure, so the figures are best read as directional.

What do the CMDB, the portal and the context file get right?

Three answers already compete for this job. The configuration management database holds the relationships between services and infrastructure, with an operating process around it. Vendors now present it as the semantic layer for agents: when ServiceNow announced its acquisition of data.world in May 2025, its data and analytics lead described the CMDB as the embodiment of the company's semantic layer and knowledge graph principle.

The internal developer portal brings services, owners, dependencies and standards into one catalogue that engineers already use. The repository context file sits closest to the code, costs almost nothing and is already widespread.

Each holds part of the answer, and all three share one limit: they are stores. None guarantees on its own that what it holds is current, or that someone answers for it when it is wrong. Completeness also differs from accuracy, and the stores are often weaker than they look. Gartner warned in late 2020 that, through 2024, nearly every organisation using CMDB tooling without confronting its data quality gaps would see visible business disruption, and Port's 2024 survey found 35% of respondents still tracking microservice data in spreadsheets.

How do three inventories become a context supply?

An earlier piece on this site, Three Inventories to Take Control as a CTO, argued that a CTO who controls neither the agenda nor the teams gains control through three inventories: applications, people and roadmap. Agents need the same inventories. What changes is the reader, since the inventories were built for a person steering on a monthly or quarterly rhythm, and agents now consume them on every task.

Applications become systems context. Services, contracts, dependencies and environments tell an agent what it is touching and what breaks if the change goes wrong.

People become ownership and decision rights. Every element has someone who answers for it and someone who can approve a change to it.

The roadmap becomes intent. The roadmap's job is to show the impacts of initiatives running in parallel and to prioritise intent. An agent working on a service should know that two other initiatives are changing it this quarter, and which one takes priority if they collide.

A fourth type matters more to agents than it did to the original inventories: decisions and standards, meaning the architecture decisions, policies and conventions a change must respect. A person absorbs them over months, while an agent needs them at the moment of the change.

In most organisations these inventories have been pushed by the architecture team, or kept up partially where teams have strong technical ownership and a culture of technical excellence. Where they were incomplete, people compensated. Engineers knew which service really depended on which, operations absorbed the surprises in run, and the cost showed up as inefficiency nobody measured.

Agents remove that cushion. They act on what is written, at a volume no team can compensate for, so they magnify whatever the inventories get wrong. Organisations at a higher maturity stage are likely to address this constraint sooner and move on to the next one, while the others meet it first.

What does a governed context supply look like?

The core of the design is separation of concerns. Each context type has its own sources and its own owner, one access layer serves all of them, and freshness comes from the delivery pipeline instead of periodic clean up campaigns.

Figure 1. A governed context supply. Context types with named owners, one access layer, freshness from the pipeline, and a defined seam with business meaning.

Figure 1. A governed context supply. Context types with named owners, one access layer, freshness from the pipeline, and a defined seam with business meaning.

Context types with named owners. In a common split, the teams that run each service own its systems context, engineering management owns ownership data, product and portfolio own intent, and architecture owns decisions and standards. The exact assignment matters less than the rule behind it: each element has one owner, accountable for its accuracy.

One access layer. Agents and people reach context through a single layer that serves the slice a task needs, controls who and what may read it, and records what was served. Keeping the slice minimal follows the ETH Zurich result, and keeping a record means that when an agent errs, someone can see what it was given.

Freshness from the pipeline. The delivery pipeline already sees every change, so every merge and release updates the context it touches: a new dependency, a changed contract, a retired endpoint. Context then keeps pace with the agents that read it.

Context checks in the Verification System. A change that leaves a service without an owner, breaks a reference or pushes context past its staleness threshold fails in the same way as a failing test. Context is then verified like code, inside the Verification System.

In what order should you build it?

Ownership tends to come first, since nothing stays current without someone who answers for it, and every later block assumes an owner exists. Systems context comes next, because contracts and dependencies carry most of the risk an agent can create. Intent follows, usually by connecting the existing roadmap to the systems each initiative touches.

Decisions and standards come fourth, once there is a structure to attach them to, and freshness from the pipeline and the access layer close the sequence. An organisation with strong catalogue discipline may reasonably start with the access layer. What tends to fail is the reverse order, where an access layer built over stale, unowned context serves wrong answers faster.

Where does the CTO stop and the CDO start?

Engineering context belongs to the CTO: systems, contracts, decisions, environments and intent. Business meaning, such as what counts as a customer, an order or an active contract, belongs to the business domains and often to the CDO. Agents cross that line constantly, and the seam is where many of their errors hide.

The CTO's job at the seam is the interface: shared identifiers and contracts that let an agent move from a service to the business concept it implements without guessing. Building the business meaning itself is a separate programme with separate owners.

How do you measure context capacity?

Three probes cover most of what a CTO needs, offered here as a starting set:

  • coverage, the share of services and initiatives with a named owner and current context;

  • lag, the time between a change shipping and the context it affects being updated, set against the volume of change shipped;

  • cost, the human interventions caused by missing or wrong context.

Lag is the closest measure of context capacity itself. When change volume rises and lag rises with it, supply has outrun capacity. The cost probe belongs in the denominator of validated business value per unit of human intervention, and it requires tagging interventions by cause.

What happens one stop ahead?

Design one stop ahead. Once context is governed, the constraint is likely to move to authority: which agent may act on what, who approves it, and how the decision is recorded. That is the control side of Context & Control in the AI Engineering Production System, and the subject of a later piece in this series.

What should a CTO decide?

Name an owner for every context type, and write accuracy into the role. Fund the access layer as shared capacity, alongside environments and test data, sized to the change volume the agent programme will create.

Make the delivery pipeline the source of freshness, so context changes with every merge and release. Put the roadmap where agents can read it, with impacts and priorities explicit.

The question for your context

Agents will act on whatever your organisation has written down about its systems. The organisations that absorb agent volume are likely to be the ones that treat that record as a supply, with owners and a capacity.

If change volume doubled tomorrow, how much of your systems could you keep described, owned and current, and who would answer when it was not?

Read further

FAQ

What is context capacity?

Context capacity is the rate of change an organisation can keep accurately described, owned and current for the agents acting on its systems. It is measured mainly through the lag between a change shipping and its context being updated, set against the volume of change. It measures the Absorption Gap on the input side, alongside verification capacity and integration capacity on the output side.

Is a CMDB or a developer portal enough for agents?

Both are useful sources, and they hold much of the systems and ownership context agents need. On their own they are stores. A governed context supply adds named owners accountable for accuracy, freshness driven by the delivery pipeline, and one access layer that serves agents the slice each task needs.

Should every repository have an AGENTS.md file?

A file can help if it stays short. Research published in 2026 found that generated context files did not improve task success and raised inference cost by more than 20%, while files written by developers gave only a marginal gain at a higher cost. The authors recommend limiting such files to minimal requirements, which makes them one small part of a wider context supply.

Who should own context: the platform team or the product teams?

Ownership usually follows the context type. Teams that run a service own its systems context, while a platform or architecture team owns the access layer and the standards. The rule that matters is one owner per element, accountable for its accuracy.

Is a context supply a data governance programme?

It overlaps at the seam, and it is mostly engineering work. The CTO owns engineering context such as systems, contracts, decisions and intent, while business meaning belongs to the domains and often to the CDO. The CTO's part of the seam is the interface: shared identifiers and contracts between the two.

Sources