Every large enterprise is now building some version of an AI brain. Very few of them can answer three plain questions about the one they are building. Does it actually work? Can it be trusted in a decision that matters? And is it locked to a single vendor’s stack?
By an AI brain I mean the institutional memory that holds the organisation’s proprietary knowledge, finds and assembles the right context for a question, and reasons over it. These are not difficult questions to pose. The fact that they are hard to answer is the symptom, and the cause is structural. Name the cause precisely, because the fix is an architecture decision rather than a product purchase.
A knowledge base is not a brain.
The popular framing of the moment describes a “company brain” as a stack of layers: capture, retrieval, source of truth, permissions, feedback, evaluation. It is a useful scaffold and I will build on it rather than knock it down. The model is rarely the thing that fails. What teams do with it is.
Most teams build the first two layers, load the documents and search them, and stop. Retrieval over a pile of documents demonstrates well, ships quickly, and attracts a budget. The layers that decide whether the brain stays a brain under load, resists a poisoned input, survives an audit, and proves it changed a decision are the ones that get deferred. Those deferred layers are exactly the ones a bank, an asset manager, or any regulated institution cannot defer.
A confident wrong answer with no provenance is not a smaller version of a good answer. It is a different and more dangerous thing, because it is trusted.
So the interesting question is not “which vector database” or “which model.” It is “what must an enterprise brain be able to do, and how would I know if mine does it.” That is a capability question, and capability questions have a discipline of their own.
Separate what it must do from how you build it.
The decomposition discipline here is borrowed, not invented. The business-capability-modelling tradition has spent two decades naming what an organisation must be able to do as a set of outcome-named, non-overlapping capabilities, each with a contract, independent of the technology that realises them. Apply that discipline to the enterprise brain and the architecture splits cleanly into two artefacts that most “AI brain” write-ups collapse into one.
The first is a logical reference architecture. It names what an enterprise brain must be able to do, as a set of capabilities with contracts, and it names no product, platform, or vendor. Capture proprietary knowledge. Resolve which source is true when two conflict. Hold a contradictory write for a human. Bound an agent’s authority. Detect a silent quality drift before a user does. Each is a capability with inputs, outputs, and invariants that any realisation has to honour. The logical layer is the invariant, the part that stays the same no matter whose technology runs underneath.
The second is a worked solution example. It takes that same capability map and maps every capability to a real, named component on one concrete stack, with an honest status against each: built, partial, or planned. The solution example is the realisation. It proves the logical layer is not a paper abstraction, because every capability has a component, and it doubles as a maturity picture rather than a wish list.
Keeping the two apart is the move that makes everything else possible. The logical layer is what you adopt and measure against. The solution example is one substitutable proof that the logical layer is realisable. A second organisation realises the same logical layer on entirely different technology, and the logical layer does not change.
The two layers the market forgets.
The two layers a “company brain” guide is most likely to skip are the two a regulated institution asks about first. They decide whether a brain is auditable, they are absent from the popular six-layer framing, and they belong as first-class.
The first is a contradiction-safe write. When a new fact conflicts with something the brain already holds as true, the write is held for a human, regardless of how confident the model is. Nothing overwrites trusted memory on a model’s say-so. This is four-eyes and maker-checker, the control a bank already runs on payments and limits, rendered into the memory layer itself and made non-bypassable. A brain without it learns a planted or hallucinated falsehood and then asserts it with provenance, which makes the falsehood more trusted, not less.
The second is provenance in the record. Every fact carries where it came from, and every override carries which conflict a human resolved and why, stamped into the record itself rather than a side log that can drift or be lost. The audit lives in the artefact, survives migration, and is traceable in version history. The distinction matters because a side log is reconstructed after the fact and trusted on faith, while provenance in the record is the fact’s own passport.
Neither of these is exotic. Maker-checker is older than software, and data provenance has a W3C standard (PROV). What is new is the consumer that finally depends on them. An agent acting on the brain’s output is the actor that makes these two capabilities load-bearing rather than nice to have. They are the difference between a brain and an auditable brain, and the gap between those two is the whole regulated-institution conversation.
Portability you can prove by construction.
“Vendor-neutral” is the easiest claim in enterprise software to make and the hardest to believe, because it is almost always asserted and almost never demonstrated. A capability-based logical layer lets you demonstrate it.
The test is precise. Portability is shown the moment a second realisation is expressible on a different stack without editing a single word of the logical layer, and a third makes the point conclusively. So I expressed the same capability map three ways: on the stack I built, on a Google-shaped cloud, and on an Azure-and-Snowflake-shaped cloud. The logical layer needed zero edits to express any of them. A capability like “retrieve relevant context” is honoured by a hybrid retriever on one stack and by a managed search service on another, and the contract does not care which. That is portability by construction. An organisation maps its existing technology onto the capabilities; it does not rebuild to a vendor’s blueprint.
A brain you can grade honestly.
An architecture that cannot be measured is an opinion. The reason most “AI brain” efforts cannot tell you whether they work is that nobody wrote down what “work” means before they built.
So the architecture is paired with an evaluation framework, and the two are a permanent pair. The evaluation says what to measure. The architecture says what to build. A cross-walk between them proves every capability answers a real requirement and every requirement has a capability, which is also the instrument that catches drift when either side changes. The evaluation extends the popular brain rubric from the layers that prove it is a brain to the groups that decide whether it is resilient, secure, compliant, valuable, and runnable at scale. Each dimension is anchored to a recognised standard: site-reliability practice for availability, the cloud well-architected frameworks for recovery, the AI risk-management and management-system standards for governance, the emerging adversarial-AI catalogues for security.
The payoff is honest grading. Every capability is scored built, partial, or planned against the evaluation, so a team sees exactly where it stands and watches maturity rise only on genuine progress. No vanity green. Publishing the layer where the brain is weakest is part of the discipline.
The engine underneath.
Under the capabilities sits an architectural stance, and it is where the durable advantage lives. The reasoning engine is two tiers. A general frontier model orchestrates, kept deliberately swappable so it can be replaced whenever a better one appears, and a hybrid router decides each request. Beneath it sits an inventory of small specialist models, grown patiently on the organisation’s own proprietary data.
That inventory is the moat. The orchestrating model is a commodity that everyone can rent. The specialist inventory is the part a competitor cannot readily buy or replicate, because it is grown from knowledge only this organisation holds, and it is designed to compound with every interaction the brain has. The architecture makes that stance visible and buildable rather than leaving it as a slide.
This is the operating-layer argument made concrete. I argued in Becoming an AI-Native Bank that the value AI creates in an enterprise sits in the operating layer the model works inside, the policies, decision rules, and records rendered legible enough for an agent to act on. The enterprise brain is the part of that operating layer that remembers and reasons, and this reference architecture is how you build that part so it holds.
I built one, and I measure it.
None of this is theory I am asking you to take on trust. I built an enterprise brain at single-author scale, as the reference instance for the architecture. It runs hybrid retrieval over vector, keyword, and graph stores, and every write passes through a non-bypassable, human-gated contradiction check before it lands. Provenance and the override reason are stamped into each record, and an evaluation harness grades the whole thing. I score it honestly, including publishing the dimension where it is weakest, which is access control, because at single-author scale there is only one author to permission.
The reference architecture, the worked solution example, the portability proof, and the evaluation framework are published as a single openly licensed repository, CC BY 4.0, at github.com/antikas/enterprise-brain-reference-architecture, so you can adopt it, measure against it, and realise it on whatever technology you already run. It names no organisation’s confidential information and no internal system. It is the logical layer, the proof it is realisable, and the test, in a form you can use.
Closing.
The reason most enterprise AI brains cannot answer the three opening questions is that the questions were never made into requirements, and the requirements were never separated from the tools. Name what the brain must be able to do, as capabilities with contracts. Promote the two layers a regulator asks about first to first-class. Prove portability by construction instead of asserting it. Pair the architecture with an evaluation that grades it without mercy. The disciplines this needs are largely the ones enterprise architecture already knows. What is new is the consumer that finally depends on them, and the fact that an honest answer to “does your brain work” is now something you can build toward and measure rather than hope for.