Home · Writing · AI operating models · essay
Organisational memory is an authority problem
Giving AI agents more context is easy. Giving them the right context, with provenance and ownership, is the harder design problem.
When I first started using AI agents across multiple FundRobin workstreams, I thought the main context problem would be retrieval: how do we make enough information available so an agent does not have to rediscover the company every time it starts a task?
Retrieval was only half the problem.
The harder question became: when two pieces of information disagree, which one is allowed to be true?
That is an authority problem.
More context can make an agent worse
AI systems are often discussed as if context is monotonically useful. Give the model more documents, a larger context window or a bigger retrieval index and it should make better decisions.
In a real organisation, information has ownership and time attached to it.
A product plan may describe an intended architecture. The repository may show what was actually implemented. A meeting note may contain a decision that was later reversed. A strategy document may be correct at company level while being out of date for one subsystem. A generated summary can sound definitive while quietly merging several different points in time.
If all of those artifacts are placed into one undifferentiated knowledge store, retrieval can become easier while truth becomes harder to establish.
The agent has more context but less epistemic clarity.
This is especially dangerous with capable agents because they are good at synthesis. They can smooth contradictions into a plausible narrative instead of stopping to ask which source should win.
The source of truth should stay close to its owner
FundRobin now spans several distinct workstreams: the core platform, public website, content and growth systems, lead generation and shared company operations. Each has implementation knowledge that changes at a different pace.
Before we had a federated knowledge layer, the friction was very practical. I would be working in the Platform repository and need to copy context from the Homepage so the agent understood how a capability was being described publicly. Then a Content Factory workflow might need the same context again so an article or campaign did not repeat an outdated marketing claim. The information existed, but the joins between those systems lived in my head or in copy-pasted chat context.
That becomes a consistency problem as well as a productivity problem. If the Homepage says one thing, the product does another and the content system has remembered a third version, an agent can create perfectly coherent work around an incoherent company truth.
My first instinct could have been to centralise everything into a company wiki or a giant AI knowledge base. We moved in the opposite direction.
Code-adjacent truth stays with the repository that owns it.
The shared company knowledge layer is used for curated synthesis, cross-repository context and references back to those sources. Retrieval can be federated, but authority is not flattened.
That creates a useful distinction:
- local source: where the current implementation or domain-specific truth is owned;
- shared synthesis: what the company needs to understand across boundaries;
- provenance: how the synthesis points back to the evidence that produced it;
- drift: the possibility that the source has changed since the synthesis was written.
The design is less convenient than copying everything into one place. It is also much easier to reason about when the organisation changes.
A company brain should not become a second company
I am wary of the phrase “company brain” because it can imply a magical central intelligence that knows the organisation better than the organisation knows itself.
The useful version is much more mundane.
It should help an agent answer questions such as:
- Which repository owns this capability?
- What decision has already been made about this pattern?
- Is there an existing workflow I should reuse?
- What is the current source for this claim?
- Has a previous implementation been superseded?
- Which context is durable and which was only a temporary plan?
That reduces re-derivation. It lets a new agent start with more of the accumulated organisational learning instead of reconstructing the architecture from scratch.
But the brain should not silently become a competing source of truth.
A central summary that says “the system works this way” is useful only if we can trace the statement back to the system that owns the fact and notice when that underlying source changes.
Provenance matters more as autonomy increases
For a human reader, stale context is inconvenient. For an agent with tools, stale context can turn into action.
Suppose an agent retrieves an old note saying a particular database table is canonical. It then writes a migration against that assumption. Or it reads an outdated deployment plan and acts as though the release has already happened. Or it treats a proposed workflow as a live capability.
The model may be faithfully using the context it was given. Hallucination is not required for the system to be wrong.
For that reason, provenance belongs in the agentic architecture rather than being treated as an optional research feature.
I want the system to retain enough information to distinguish:
designed → implemented in source → staging verified → merged → production verified
Those states are materially different. Collapsing them into “done” is how organisational memory becomes fiction.
The same logic applies outside software. A proposal, policy, market assumption or customer insight has a source, date and level of authority. If an agent is expected to make decisions with that information, those attributes matter.
Supersede is often better than delete
Another lesson from knowledge design is that history can be useful without remaining authoritative.
Deleting an old decision removes evidence of how the organisation got here. Keeping it without qualification risks letting an agent treat it as current.
A better pattern is often to supersede.
The old artifact remains discoverable, but its relationship to the current decision is explicit. This gives both humans and agents a trail: what we believed, what changed, and which source now governs the decision.
That matters because organisational knowledge is not a static encyclopedia. It is a record of changing judgement.
For AI systems, that change history can be especially valuable. If a workflow repeatedly makes the same mistake, the answer may not be another prompt instruction. The underlying organisational knowledge may contain a contradiction that needs to be resolved at source.
Retrieval should begin with a question about authority
A common agent pattern is “search first.” I agree with it, but I would add a second clause:
search first, then establish authority.
Before an agent acts on retrieved information, it should be able to ask:
- Who owns this fact?
- How current is it?
- Is this source descriptive, prescriptive or historical?
- Does a more authoritative source disagree?
- Is the agent allowed to infer the missing piece, or should it stop and ask?
These questions are a form of epistemic governance.
They also improve human work. A senior leader does not need every raw document; they need a reliable path from the summary to the evidence. An engineer does not need the company strategy copied into every repository; they need the decisions that materially constrain their subsystem. An agent should work the same way.
Organisational memory is part of the operating model
The most interesting consequence is that knowledge architecture and operating-model design start to merge.
If an organisation wants agents to execute meaningful work, it needs to decide:
- where durable knowledge lives;
- which source owns which kind of truth;
- how shared context is synthesised;
- how provenance is retained;
- how outdated knowledge is marked;
- what an agent may infer;
- when uncertainty must escalate to a human.
Those are not RAG tuning questions. They are questions about how the organisation represents itself.
My own view changed through building this system. I started by thinking we needed to give agents a better memory. I ended up caring much more about authority, provenance and drift.
The goal is not an AI that remembers everything.
It is an AI that knows where truth is owned, can show why it believes something, and is willing to stop when the organisation itself has not resolved the ambiguity.