The Agent Org Chart

Every organisation running agents in production eventually holds the same meeting. An agent produced an answer that was confidently wrong. Somebody acted on it, or nearly did. The room is full of capable people, the logs are open on the screen, and the question on the table is simple: how did this happen and who fixes it.

The technical trace is usually easy. The agent retrieved three documents, two of which were current and one of which described a process that changed last spring. It resolved an ambiguous term the way the majority of the retrieved text resolved it. It called a tool whose description promised slightly more than the tool delivered. It wrote the result into memory, where a second agent picked it up the following week and treated it as established fact.

So the trace is clear. The accountability is not. The platform team owns the retrieval service but not the documents inside it. The data team owns the tables but not the business definition layered on top of them. The domain team owns the definition in principle, but nobody on that team has looked at the version the agent reads. The tool was built by a team that has since been reorganised. The memory entry has no author at all, because a machine wrote it.

What follows is a peculiarly modern kind of paralysis. Everybody in the room can describe the failure. Nobody in the room can point to the person whose job it was to prevent it. The meeting ends with an action item written in the passive voice — the definitions will be reviewed — which is the organisational equivalent of writing a task and assigning it to nobody.

This is not a governance gap in the traditional sense. Most of these companies have governance. They have data catalogues, access controls, approval workflows, and a policy document that says agents must be used responsibly. What they do not have is a map that connects each individual piece of meaning an agent consumes to a specific human being who is answerable for its correctness. They have an org chart for people and no org chart for context.

The instinct at this point is to say that we have solved ownership before. Data ownership has been a discipline for two decades. Every mature data organisation has stewards, domain owners, and a catalogue with an owner field. Surely the answer is to extend that model to agents.

It is the right instinct and it is not sufficient, for a reason worth stating precisely. Traditional data ownership is ownership of an artefact: a table, a dashboard, a pipeline. The artefact has a shape, a schema, and a refresh cadence. When it breaks, it breaks visibly — the job fails, the numbers move, the dashboard shows a gap. Ownership of a thing that fails loudly is a manageable job.

Context does not fail loudly. When the definition of an active customer is stale, no pipeline errors. When a retrieval scope silently excludes the one policy document that mattered, no alert fires. When a tool description over-promises, the agent does not crash; it makes a reasonable attempt and returns something plausible. The failure mode of context is not an outage. It is a confident answer that happens to be wrong, delivered at the speed of a machine and phrased with the fluency of a colleague.

There is a second and more structural difference. A table has one obvious owner because it has one obvious producer. A piece of context typically has several contributors and no producer: the finance team that defined the metric, the domain expert who knows the two exceptions, the platform engineer who chose the chunk size, the prompt author who wrote the instruction that framed the question. Each of them shaped what the agent believes. None of them signed for the whole.

This is the same argument the book makes about governance in Chapter 13: governance was designed for humans, who ask clarifying questions when they are unsure, and it does not transfer cleanly to systems that resolve ambiguity silently and proceed. Chapter 14 takes the next step, arguing that access control — the question of who may read what — has to become action control, the question of what a system may do and under whose authority. An org chart for context is what makes action control assignable rather than aspirational.

One more distinction matters. Ownership of context is not the same as authorship of context. The person who wrote a definition three years ago may have left. The person accountable for it today is whoever must answer when it is wrong. Those are different jobs and conflating them is how ownership quietly evaporates during reorganisations.

An org chart for context is only useful if the rows are specific. Assigning an owner to context in general produces the same nothing as assigning an owner to quality in general. In practice, five categories of asset shape what an agent believes and does, and each needs a name.

First, definitions. The canonical meaning of every term an agent may encounter in a question or produce in an answer: active customer, revenue, churn, incident, region, fiscal quarter. This is the layer Chapter 6 insists cannot be replaced by better retrieval, because retrieval finds text that resembles the question and a definition is a decision, not a resemblance. The owner of a definition is the person who can adjudicate a dispute about it and make the adjudication stick.

Second, retrieval scope. Which corpora an agent may draw from for a given task, how documents are chunked, how freshness is weighted against similarity, and which sources are treated as authoritative when two disagree. These are engineering decisions with semantic consequences, and they are covered mechanically in Chapter 35. The owner is whoever can answer the question: if a stale document outranked a current one, why did the ranking permit that.

Third, tool contracts. Every tool an agent can call, what the description promises, what the tool actually does, what its failure modes look like, and what the agent is permitted to do with the result. A tool description is a piece of context in the strictest sense: it is the model's entire understanding of a capability. An inaccurate description is not a documentation problem, it is a behavioural defect. Chapter 14 treats this as the frontier of control, and Chapter 15 covers the guardrails, approvals, and audit trails that sit around it.

Fourth, memory. What the system is allowed to remember, for how long, at what level of confidence, and who may correct it. Memory is the asset most often left ownerless, because it is written by machines rather than people and therefore never appears in a catalogue. Yet a wrong memory entry is the most expensive artefact in the entire system, because it converts a single error into an organisational belief. The three newer chapters on institutional memory — Chapter 10, Chapter 11, and Chapter 12 — exist precisely because this layer had no owner in most architectures.

Fifth, evaluations. The labelled set of real questions with known-correct answers that tells you whether the four categories above are still working. An eval suite without an owner decays into a test that always passes. The owner is whoever must present the number when somebody asks whether the system is better or worse than it was last quarter, which is the discipline Chapter 29 treats as the professional core of the agentic era rather than a quality-assurance chore.

There is a useful analogy in evidence handling. In forensic work, a piece of evidence carries a chain of custody: a record of every person who held it, when, and what they did with it. The purpose is not bureaucracy. The purpose is that when the evidence is challenged, there is a name attached to every stage, and a gap in the chain is itself a finding.

An agent decision has exactly this structure and almost never has the record. A question arrives. Retrieval assembles a working set. The model reasons over it. An action is taken or a recommendation is issued. A log entry records the outcome. Five stages, five points at which meaning could be distorted, and in most systems a single vague owner for the whole pipeline — usually whichever team happens to run the platform.

Building the chain does not require new technology. It requires deciding, for each stage, whose judgement is authoritative. The user who asked the question owns the intent. The retrieval owner owns what was made available. A model steward owns which model handled the task and under what configuration, a decision with cost and quality consequences that Chapter 19 argues should never be made by default. The action owner owns what the system was permitted to execute. The audit owner owns whether the record is complete enough to reconstruct the decision six months later, which is the practical test Chapter 16 applies to designed trust.

The value of writing this down is not that it prevents errors. It is that it converts an unanswerable question into an answerable one. When the wrong answer appears, the post-mortem no longer asks how did this happen in general. It asks which link in the chain failed, and the answer names a stage, and the stage names a person, and that person already understood that this was their stage. The meeting takes twenty minutes instead of two hours and produces a fix instead of a sentence in the passive voice.

Notice also what the chain reveals when you draw it honestly. Most organisations discover one or two stages with no owner at all — commonly memory and evaluation — and one stage with an owner who did not know they held it, usually retrieval configuration. Both discoveries are worth the exercise on their own.

Assigning a name is easy and meaningless unless the responsibility is defined. An owner field in a catalogue that means somebody once typed a name is worse than an empty field, because it creates the appearance of accountability without the substance.

A context owner has four obligations, and they are small enough to be real. The first is currency: the asset reflects how the business works today, and there is a date on the record that proves somebody checked. The second is adjudication: when two parts of the organisation disagree about the meaning, the owner decides, and the decision is written where systems read it rather than where humans discuss it. The third is blast radius: the owner can say which agents, workflows, and downstream systems consume this asset, because ownership without knowing the consumers is ownership of a document rather than of a behaviour. The fourth is escalation: the owner knows what to do when the asset needs to change in a way that breaks something, and has the standing to trigger that conversation.

None of this requires a new job title. In most organisations the right owner is the person who already gets the phone call when the number looks wrong. The exercise is not hiring; it is making explicit an accountability that currently exists only informally, and that therefore disappears the moment the informal holder changes teams.

It is worth being blunt about the failure mode here, because it is the most common one. Ownership assigned to a team rather than a person is not ownership. A team cannot be asked a question. A team cannot adjudicate a dispute. When the definition of margin is owned by finance, everyone in finance reasonably assumes somebody else in finance is handling it. Chapter 26 describes the agentic data professional partly in these terms: the person who holds a piece of organisational meaning and answers for it is doing the highest-leverage work in the building, and that work is individual by nature.

There is a cost argument for this discipline too, and it is not a small one. Every ambiguity an agent resolves by guessing produces retries, longer contexts, human rework, and occasionally a decision that has to be unwound. Chapter 18 calls these the hidden costs of agentic AI, and Chapter 21 frames the trade-off directly: unclear meaning is paid for in tokens, in latency, and in trust, usually all three. Ownership is the cheapest intervention available, because it requires no infrastructure at all.

The diagnostic is simpler than most governance exercises, and it can be run in a single afternoon with a spreadsheet and a willingness to be uncomfortable.

Take one production workflow that matters. List every piece of context the agent consumes to complete it: each definition, each retrieval corpus, each tool, each memory store, each instruction block in the prompt. Aim for between fifteen and forty rows. Fewer than fifteen means the list is not honest yet. Beside each row, write the name of a person — not a team, not a platform, a person — who would answer if that row were wrong tomorrow.

Then count three numbers. The number of rows with no name is your orphan count. The number of rows whose name appears more than five times is your concentration risk. The number of rows where the named person does not know they are named is your gap between the chart on paper and the chart in reality, and that third number is usually the largest.

In every version of this exercise we have watched, the same pattern appears. Definitions have owners on paper and are unreviewed in practice. Retrieval configuration has no owner because it was set once during a proof of concept by someone who has moved on. Tool descriptions are owned by whoever wrote the tool, which means they are owned by nobody after the second reorganisation. Memory has no owner. Evaluations have no owner, or an owner who inherited the suite without the labelled data that made it meaningful.

The orphan count is the number that predicts trouble. Orphaned context is not merely undocumented; it is unfalsifiable. Nobody can say whether it is right, because saying so is nobody's job, and so it stays in the system indefinitely, retrieved with the same authority as the assets somebody does check. The distinction between owned and orphaned context is not a maturity nicety. It is the difference between a system that can be corrected and a system that can only be replaced.

The objection to naming individuals is always the same, and it is fair. People leave. Teams split. A chart of names is stale within a quarter, and an ownership model that decays is arguably worse than none.

The answer is to treat ownership transfer as a first-class event rather than an accident. Three practices make the chart durable. Ownership has an expiry: every row carries a review date, and an expired row is surfaced as an operational item rather than quietly assumed to be fine. Ownership transfers explicitly: when somebody changes roles, their context rows appear on a checklist and are reassigned by name before the handover closes, exactly as laptops and system access are. And ownership is visible where the work happens: the owner's name sits in the semantic layer, the tool registry, and the eval configuration, not in a governance document that nobody opens.

There is a portability dimension too. If your ownership map lives inside one vendor's console, you have made your accountability structure a function of your platform choice. Chapter 22 and Chapter 23 make the general case for open formats and open interfaces; the specific case here is that the register of who answers for what is among the most valuable documents your organisation will produce in this decade, and it should be exportable as plain structured text. Chapter 25 frames the posture well: platform independent, platform aware.

The same logic extends to multi-agent designs, where ownership gaps are amplified rather than merely present. When one agent hands work to another, the receiving agent inherits whatever context the sender chose to pass, and any ambiguity in that handoff becomes an error with no author. Chapter 34 treats the seams between agents as the primary design surface, and an ownership map is what makes each seam attributable. Chapter 36 adds the uncomfortable corollary: when context is compacted to fit a budget, something is discarded, and the decision about what may be discarded is itself an ownable judgement rather than an implementation detail.

It is tempting to file this under governance, which in most organisations means filing it under later. That would be a mistake, and the reason is competitive rather than procedural.

Every company can rent the same models. Every company can buy similar orchestration. What no company can buy is a register of what its terms mean, who decided, when it was last checked, and what breaks if it changes. That register is built only by an organisation doing the unglamorous work of naming people against meaning and keeping the names current. It compounds, because each resolved ambiguity stays resolved. It transfers poorly to competitors, because it encodes how this specific business actually works. And it makes every future model upgrade cheaper, because the expensive part of an upgrade is re-establishing trust in the context layer, not swapping the endpoint.

The four C's give this its shape. Context is the asset. Control is the discipline that makes the asset trustworthy, which is where ownership lives. Cost is what you pay when ownership is absent and agents guess. Choice is what you preserve by keeping the register in a form you can carry. Chapter 4 sets out the framework, and Chapter 30 shows the architecture the four together imply. If you want to begin building the layer itself rather than reading about it, Chapter 31 is the practical starting point, and Chapter 32 is the assessment that tells you where you actually stand.

Start smaller than you think you should. One workflow, one honest list, one column of names, one review date. The first afternoon will produce a number of orphans that is mildly embarrassing. That number is the most useful metric your agentic programme has, because unlike accuracy, it is entirely within your control, and unlike model choice, no vendor can improve it for you.