Org Brain. The layer that lets AI see your business.
Org Brain is the context layer we build: your ERP, CRM, accounting, email, documents and phone, joined into one permissioned layer that resolves who is asking before it reads anything. Ask it something and it answers from your own business, with the source behind every answer. It is built so that it cannot show a person anything they could not already see in the source system.
Org Brain is our reference architecture and component set for a permissioned context layer. We build it inside your environment, you own what is deployed, and we keep the right to reuse the pattern.
- IdentityResolved before a single record is read, never as a filter afterwards.
- PermissionsChecked at the moment of the question, against your systems' own controls.
- EntitiesOne customer, one job, one asset — across systems that each name it differently.
- FreshnessRead live where it must be current. Materialised only where it is genuinely durable.
- ProvenanceEvery answer names the records it used and when they were true.
The marked row is the one most tools skip. Resolving identity after retrieval instead of before it is how a correct answer reaches the wrong person.
Not another dashboard. The layer underneath every dashboard, answer and alert.
Org Brain does not replace the systems you run. It connects them, and it resolves two things before anything else happens: who is asking, and what they are allowed to see.
The reasoning model on top is a swappable part — today one frontier model, next quarter whichever one is cheaper or better at the task. The durable asset sits underneath it: the connectors into your systems, the permission engine, the entity graph that ties one customer or one job together across every place it is recorded, the precedent index of what you have quoted and decided before, and the shape of your own organisation's context.
That is what makes Org Brain a foundation you own, not a subscription you rent.
Three columns, left to right.
- ERP
- CRM
- Accounting
- Email & calendar
- Documents
- Telephony
- Identityresolves who is asking, first
- Permissionsreads as that person, never around them
- Entity resolutionone customer, one job, one asset
- Precedent & policyyour standards, quotes, decisions
- Freshness controllive where it must be current
- Governed assistant
- Persona agents
- Alerts
- Reporting
On the left are the systems you already run — ERP, CRM, accounting, email and calendar, documents, telephony. None of them are replaced. In the middle is the context layer itself: identity resolves first, then permission, then entity resolution ties records together across systems, precedent and policy give it your standards, and freshness control decides what must be read live versus what is safe to hold as derived structure. On the right is everything that gets to use it — a governed assistant, persona agents, alerts and reporting — each one working from the same governed layer instead of keeping its own copy of the truth.
Capability, stated concretely.
- 01Fingertip reportingAsk a plain-language question across every connected system and get an answer back with its source and a timestamp, not a dashboard you still have to interpret.
- 02Entity resolutionOne customer, one job, one asset — resolved across systems that each call it something different, so nothing is double-counted and nothing is missed.
- 03Precedent recallWhat you quoted, approved, refused and priced before, and why, surfaced the moment it is relevant again instead of relying on someone remembering.
- 04Alerts before problems landDelivery slipping, invoices overdue, service due, margin thinner than it should be — raised while there is still time to act on it.
- 05ForecastingDemand and capacity, cash, maintenance, delivery risk. Probabilistic and stated honestly, improving as your data deepens rather than promising a certainty it does not have.
- 06A complete audit recordWho asked what, what was returned, and what was acted on — kept as a matter of course, not reconstructed after something has already gone wrong.
An answer, and the receipts behind it.
Most tools that answer questions about your business hand you a paragraph and ask you to trust it. An answer you cannot check is not an answer, it is a rumour with better formatting.
So every response separates what is true from what is merely advised, names every record it read and how fresh each one was, flags it when two systems disagree, and states what it was not allowed to read.
The last one is the part nobody shows you, and it is the part that decides whether you can put this in front of your whole team.
“Which jobs are at risk of slipping this month, and what is it worth?”
- 1ERPjob 4471 · scheduleread live · 40s ago
- 2ContractsCT-2291 · clause 14indexed · 6d ago
- 3FinanceAR ageingread live · 2m ago
Three records matched this question but sit outside this person's access (subcontractor rates, two payroll records). They were never read, and the answer does not depend on them.
It also speaks first.
Once the layer is joined, the useful work stops being questions you thought to ask. Delivery risk, cash risk, thin margin and lapsing compliance are all visible from the same joined context, and each signal arrives with the records it came from.
Ten things every answer has to carry.
This is a contract, not a feature list. An answer that cannot satisfy all ten is not shown as an answer. It is shown as a gap, with the reason it could not be completed.
Most of the value is in the unglamorous half: saying when the data was read, saying when two systems disagree, and refusing to blur the line between what is true and what is merely advised.
You can hold a vendor to this. Ask them to write their version down.
- 5.1Who is askingIdentity resolved before a single record is read, never after the fact as a filter on the result.
- 5.2What they may seePermissions applied at question time, against your systems' own controls, with the count of readable records stated.
- 5.3What was actually readEvery record that contributed, named, so the reasoning can be checked rather than trusted.
- 5.4How fresh each source wasRead live, or read from a materialised copy and how old that copy is. Never silently mixed.
- 5.5The factWhat is true according to those records, with nothing inferred and nothing rounded into a better story.
- 5.6The likely driverThe probable cause, labelled as probable. A correlation presented as a cause is how a good answer becomes an expensive mistake.
- 5.7The recommendation, marked as oneAdvice is separated from fact and labelled, so nobody acts on a suggestion believing it was a measurement.
- 5.8Any conflict between sourcesWhen two systems disagree, both figures are shown and the one used is named. Quietly picking a winner is the failure we design against.
- 5.9What was withheldRecords that matched but sat outside the asker's access, stated plainly, so the answer's limits are visible.
- 5.10A record that it happenedWho asked, what was returned, what was acted on. Written at the point of read, not reconstructed afterwards.
Identity and permission resolve before anything is read.
Org Brain is built so that every request resolves who is asking and what they are allowed to see before a single record is touched. It is not designed to read as a service account with broad access and filter the result afterwards. It reads as the authenticated person, through your systems' own permission controls, wherever those systems support it.
- 01Per-request identity resolutionEvery call carries the caller's identity and is checked against your systems' own access controls before any record is touched. Not against a cached role, on every single request.
- 02No standing service-account accessOrg Brain is designed to hold no broad credential that reads on everyone's behalf. It reads with the requesting person's own delegated access, nothing wider. Where a system cannot read as the person, we say so and scope that system out rather than fall back to a service account.
- 03No new access pathIt is not a shadow system with its own permission model to audit separately. The design contract is simple: if a person cannot see a record in the source system, Org Brain does not show it to them either.
- 04Logged at the point of readEvery access is recorded against the identity that triggered it, so the audit trail is a record of what happened, not a reconstruction built later from memory.
Why we read live instead of copying your data into an index.
Many tools copy your data into a separate store so they can search it. That copy is convenient, and it comes with a cost most vendors do not mention: it expands your audit scope and attack surface, and permissions resolved at index time are already wrong by the time someone asks a question. A materialised index is not wrong to use — it is the right tool for content that is large, slow-changing and safe to be a little stale.
As current as the last sync run — minutes to a day behind, depending on the schedule.
Current as of the request, because it reads the source system directly.
Resolved at index time, so already wrong the moment someone's access changes.
Resolved on every request, against the access a person actually holds right now.
A second copy of your data, held somewhere else, that now needs its own access controls, retention policy and breach plan.
No second copy. The audit surface stays the systems you already govern.
Fast search over large, slow-changing bodies of text — closed jobs, finalised policy, historic documents.
Anything that must be current or permission-sensitive — today's stock, this customer's balance, who is allowed to see it.
Org Brain uses both, on purpose. It reads live from the source for anything that must be current or permission-sensitive, and it only materialises content that is genuinely durable and derived — a precedent index of finalised quotes, for instance, not this week's inbox.
A few honest limits, stated up front.
Org Brain is not a data warehouse replacement. If you need long-range analytics across years of history, keep your warehouse — Org Brain reads and reasons over current and recent state, it does not replace bulk analytical storage.
It is not a rip-and-replace of your ERP, CRM or accounting system. Those stay exactly where they are and remain the system of record. Org Brain sits alongside them and asks them questions on your behalf.
It is not magic laid over bad data. If your customer records are duplicated three different ways, or your job costing has not reconciled in two years, a layer that sees all of it faster will surface that mess faster. It will not fix it.
Where your data is genuinely broken, we say so — and that becomes the first project, not something we paper over with a clever prompt.
Three to five months for a connected foundation.
Delivered in fixed-scope phases, so value starts early and each phase funds the next. It is not an overnight project and we will never tell you it is.
From the first connector to a working context layer across your core systems.
Each phase is scoped and quoted before it starts, not billed by the hour.
Value starts early enough that each phase's return funds the one after it.
Give your business a layer that can answer for itself.
Start with a fit call. We will tell you honestly whether a connected foundation is the right first move, or whether a narrower step should come first.