Who owns the context? Building a company brain when every agent and model reads it differently

Every organisation that puts agents to work arrives at the same wish within a few weeks: a company brain. One place where everything the business knows lives, so that any agent working on any task can draw on it.

The wish is reasonable. The first implementation is usually a pile of documents behind a retrieval layer, and it works well enough for a single person asking questions. Then the second agent arrives, then a second team, then a second model provider, and the pile starts to misbehave in ways that are hard to name.

This post is about naming them. The short version is that a company brain is not a store of knowledge. It is a graph of context, and in a multiplayer setting the questions that matter are about the edges: who owns each piece, who may read it, which model is reading it, and what happens when an agent writes something back.

A pile is not a brain

The default approach is to index everything and retrieve what looks relevant. It is quick to build and it answers questions. It also throws away most of what an organisation actually knows about its own knowledge.

Consider what is attached to a single document in a real business. Someone owns it. A function stewards it. It supersedes an earlier version. It applies in one region and not another. It was cited in a decision last quarter. It is visible to one team and confidential to the rest. Two of its paragraphs are policy and the third is a draft someone forgot to remove.

None of that survives flattening into chunks. Retrieval returns the text, and the text looks the same whether it is binding, superseded, confidential, or wrong.

A company brain worth the name keeps those relationships. Documents, policies, procedures, people, systems, and decisions are nodes. Ownership, authority, access, supersession, and provenance are edges. The graph is not a nicer data structure for its own sake. It is the only place the governance of the knowledge can live.

Four things that break in multiplayer

With one person and one agent, the pile mostly holds. The person knows what they are allowed to see, and they are the only consumer of the answer. The problems begin when several people, several agents, and sometimes several models share the same brain.

Different models read the same context differently

Organisations are increasingly choosing their model provider per task, per cost, or per data-residency requirement. A single brain is read by more than one model, and models do not read alike.

One model treats an exception clause as binding. Another treats it as advisory and proceeds. A third gives more weight to a recent informal note than to the formal policy it contradicts. All three are reading the same graph. All three produce defensible output. Only one of them matches what the organisation meant.

In a single-player setting this is a quality issue. In a multiplayer setting it is a consistency issue, because two teammates working on related tasks get different answers from the same brain and neither knows why. Model choice becomes a governance decision. The organisation needs to say which model may read which context for which kind of work, and the record needs to show which model read what.

Agents write back, and the brain drifts

Agents do not only read. They summarise, they conclude, they file. A triage agent notes that a supplier is slow. A finance agent records that an exception was approved. Those notes land in the brain, and the next agent reads them as fact.

Over time the brain fills with inferences. Some are correct. Some were correct once. Some were an agent’s guess that was never reviewed. Without provenance on every write, there is no way to tell a human decision from an agent’s inference, and no way to roll back a conclusion that turned out to be wrong without losing everything built on it.

The fix is not to forbid writes. It is to make every write carry who made it, on whose behalf, from what evidence, and whether a person looked at it. A brain that knows the difference between a decision and a guess can be trusted to hold both.

Scope has to travel with the context

An agent reads a confidential forecast while working on behalf of a finance lead who is permitted to see it. The agent carries what it learned into its next task, for a different person who is not.

Nothing in a flat retrieval layer stops this, because the leak does not happen at retrieval time. It happens in the agent’s working memory, between tasks. Access scope has to be attached to the context itself and enforced at the moment the context is used, not just when it is fetched. An agent borrowing context for one piece of work should return it when the work ends, and the next piece of work should start with only what its own scope allows.

This is the part of the company brain that most resembles identity and access management, and the part most often skipped because it is unglamorous.

Nobody can audit an answer

A reviewer asks why an agent recommended terminating a contract. The answer, in a flat system, is that the model was confident. That is not an answer an auditor, a regulator, or a careful operator can accept.

The useful answer is a trace: this run read these four documents at these versions, under this scope, with this model, and produced this recommendation, which this person approved. That trace is only possible if the brain records the slice of context each run consumed. In a graph, that slice is a set of nodes and edges. In a pile, it is a list of chunks that no longer map to anything a human recognises.

Who owns the context

The question in the title has a layered answer, and the layers matter.

The organisation owns the brain. It is an asset, like the systems of record it draws from. It needs an owner with authority to decide what goes in, what is authoritative, and what is retired. A brain nobody owns becomes a pile with better marketing.

Functions steward their slice. Finance decides what the authoritative expense policy is. Legal decides which contract templates are current. Support decides which runbooks apply. Stewardship means a named person is accountable for the correctness of a slice, and that agents treat that slice as authoritative over anything informal that contradicts it.

People hold scope. Each person can see what their role permits. When an agent acts on their behalf, it inherits that scope for that work and nothing more.

Agents borrow, never own. An agent holds context under scope for the duration of a task. It may write back, with provenance. It may not carry context between tasks for different principals, and it may not promote its own inferences to authoritative status. The last point is the one that keeps a brain honest as the number of agents grows.

This layering is what makes a company brain governable rather than merely large. It is also what lets several models read the same graph without the organisation losing control of what the graph means.

Design principles that follow

A few practical consequences fall out of the above. They are not a product specification, but they are a reasonable test of whether a company brain will hold up in multiplayer.

• Every node has an owner and an authority level. Authoritative, informal, superseded, or draft. Agents should be able to see the level and weigh accordingly, and the level should be set by a steward, not inferred by a model.
• Every edge carries scope. Who may traverse it, under what role, for what kind of work. Scope is enforced when context is used, not only when it is retrieved.
• Every write carries provenance. Actor, principal, evidence, review status. Agent inferences are visible as inferences.
• Every run records its slice. The nodes, versions, model, and scope that produced an output, so the output can be traced and, if necessary, retracted.
• Model policy is explicit. Which models may read which classes of context for which work. This is a governance setting that a compliance lead can read, not a configuration detail buried in a pipeline.

None of these require a particular technology. They require deciding that knowledge is governed, and building the brain so that the governance has somewhere to live.

Where we are exploring

At SoftworkerAI we are exploring what a company brain looks like when it is built for many people, many agents, and more than one model from the start: a knowledge layer where ownership, scope, and provenance are first-class, where the organisation chooses which model reads which context, and where every run leaves a trace that a person who was not in the room can follow.

We do not think we have the full answer. The questions in this post are the ones we keep returning to, and if your team is working through the same ones, we would like to compare notes.

The takeaway

A company brain is a context graph with ownership on the nodes and scope on the edges. Multiplayer breaks the simpler version in four places: different models read the same context differently, agents write back and the brain drifts, scope fails to travel with context between tasks, and nobody can audit an answer. The fix in each case is the same: treat the knowledge as governed, decide who owns each layer, and record what each run read. Who owns the context is not a philosophical question. It is the first design decision.