Building the Company Brain Without Rebuilding Your Data Stack

An executive asked us last month: "How do we build a central company brain when half our knowledge lives in spreadsheets, a quarter lives in an old ERP, and the rest lives in Karen's head?" He was braced for the answer he had been given by two other consultancies: an eighteen-month data platform project, seven figures, value at the end if everyone behaves.

That answer is wrong, and it is wrong in a way that costs mid-market companies years. You do not need a data warehouse rebuild to get value from AI. You need two things that are far cheaper and far less glamorous: a thin retrieval layer over the systems you already have, and a habit of capturing how work actually gets done. This post covers both, plus the data investments that genuinely matter, what to do when the process itself is the problem, and how to pick which use cases to tackle first.

Is Our Fragmented Data a Blocker for AI?

Not necessarily. Fragmented data is common in mid-market businesses: the CRM may disagree with the accounting system, the operations tracker may be a spreadsheet with a name like FINAL_v7, and job files may live in a folder structure only two people understand. That mess needs governance, but it does not automatically require a full data-platform rebuild before useful AI work can begin.

The old playbook said: consolidate first, get value later. Migrate everything into one platform, build the golden schema, then point analytics at it. Those projects can stall before delivering value, especially when the business changes shape faster than the migration can track it.

Agents changed the economics of this problem. A modern agent does not need your data in one place; it needs permission to read the places your data already is. Anthropic's own usage data from 1.2 million anonymised Cowork sessions shows business-process operations, reporting, checklists and spreadsheet reconciliation, make up 33.4% of all agent sessions (source). Reconciliation is, by definition, work across fragmented systems. The largest single category of real-world agent work is agents coping with exactly the mess you are worried about.

How Do You Unify Data Without a Massive Overhaul?

You build a thin retrieval layer instead of migrating anything. The process we run with clients has three steps, and none of them involves moving data.

Step one: inventory where decisions actually get made. Not where data officially lives, where decisions get made. Sit with the five people who run your operations and ask what they open when they need to answer a real question: which client is overdue, which job is unprofitable, which candidate got the offer. You will end up with a short list, usually five to eight systems, and a much shorter list of three that carry most of the weight.

Step two: connect the top three systems read-only. Read-only matters. It keeps the risk profile low enough that your accountant and your IT provider will both sleep, and it forces the first wave of value to be retrieval and synthesis rather than write-access automation you have not earned trust for yet. Most modern SaaS tools expose an API; connectors and MCP-style integrations cover most of the rest.

Step three: let agents retrieve across systems rather than migrating between them. When the managing director asks "what is our exposure to our top five clients", the agent reads the CRM, reads the ledger, reads the project tracker, and assembles the answer. Nobody built a warehouse. Nobody wrote an ETL pipeline. The fragmentation is still there; it just stopped mattering to the person asking the question.

The scope of that layer widened materially in June. Computer Use in Gemini 3.5 Flash gives agents the ability to see, click, type, and extract structured data across desktop and browser interfaces, which puts API-less legacy software in reach: the old ERP, the government portal, the industry platform that has never heard of a webhook. Google is positioning it for financial document prep and onboarding workflows, which tells you where the demand is. Treat that capability with respect (sandboxing, evals, approval gates before it touches anything real), but stop treating your legacy stack as a reason to wait.

How Do You Capture Tacit Knowledge Into a Company Brain?

Accept first that the company brain is mostly not in your databases. When executives say "company brain" they usually picture a knowledge graph. What they actually need captured is tacit knowledge: how your best estimator prices a tricky job, what your operations lead checks before releasing an invoice, why you never schedule that supplier for Fridays. None of that is in a system. It is in people, and it walks out of the building at 5pm and permanently when they resign.

The traditional fix was documentation sprints, and they fail for a predictable reason: writing documentation is a separate job from doing the work, so it always loses the priority fight. The fix that works is making capture a byproduct of doing the work.

Here is the mechanism. When someone uses an agent for a real task, they have to explain the process to it: the steps, the exceptions, the judgement calls. That explanation, saved as a written skill or SOP the agent loads next time, is documentation. The person who explains a process to an agent once has documented it forever, and unlike a wiki page, this documentation gets exercised daily, so rot is caught within days rather than discovered two years later. Anthropic's Claude Science beta is built on this exact pattern at the research end: 60 plus curated skills and connectors that encode how work in a domain should be done, with a reviewer agent checking outputs. That skill-and-connector architecture is the direction of travel for internal company knowledge too.

The practical rollout: pick your ten most senior operators, give each of them one afternoon, and have each one walk an agent through the two processes only they know how to do properly. Twenty captured processes in a fortnight, at a cost of ten afternoons. This is also where staff capability compounds, because people who work with agents daily capture knowledge as a side effect; we cover that progression in our post on moving from AI-literate to AI-first.

What Data Investments Actually Make AI Effective?

Three investments matter, and none of them is a platform. They are boring, cheap relative to a replatform, and they determine whether your retrieval layer produces answers or confident nonsense.

• Access and permissions cleanup. An agent inherits the access of the person running it. If your shared drive is a decade of "everyone can see everything", the retrieval layer becomes a leak with a chat interface. Tighten permissions before you connect anything; it is the least optional item on this list.
• Naming and ownership. Every key system needs a named owner, and your core entities (clients, jobs, products) need consistent identifiers across systems. An agent can cope with mess, but it cannot reliably guess whether "Acme Pty Ltd" in the CRM is "ACME GROUP" in the ledger. A shared client ID, even one maintained in a plain reference sheet, removes a whole class of silent errors.
• One source of truth per entity. Not one platform for everything; one nominated system per entity type. Client contact details live in the CRM, full stop. Financials live in the accounting system, full stop. When systems disagree, everyone (humans and agents alike) knows which one wins.

What can wait: the grand unified schema, the master data management programme, the enterprise data catalogue. These are fine projects for a 5,000-person company with a data team. At mid-market scale they consume the entire budget and all of the organisational patience before a single workflow improves. Fund them later out of the returns, if you still want them. You mostly will not.

When Processes Are the Problem, Where Do You Start?

Start at the decision points, because automating a broken process ships broken outcomes faster. If your quoting process produces inconsistent margins because three people apply three different markup rules, an agent trained on that process will produce inconsistent margins at ten times the volume. Speed amplifies whatever is already there.

The good news is you do not need a six-month process re-engineering effort. Walk one process end to end and mark every point where a human makes a judgement call. At each one, ask two questions: is there an agreed rule, and does everyone actually follow it? Where the answer is no, fix that decision point first: agree the markup rule, define what "approved" means, name who signs off. Then automate. A process with clean decision points and scruffy handoffs automates beautifully; a process with clean handoffs and vague decisions automates into a mess.

This ordering also gives you a useful test for readiness. If you cannot write the rule down, the process is not ready for an agent. If you can, the agent becomes the mechanism that enforces the rule consistently for the first time, which is often worth more than the labour saved.

How Do We Prioritise AI Use Cases?

Score every candidate on two axes: the value of the task, and the readiness of the data and process behind it. Value is hours consumed multiplied by the cost of getting it wrong. Readiness is what this whole post has been about: is the data reachable read-only, are the decision points defined, does someone own the process.

That gives you four quadrants, and the strategy writes itself:

1. 1High value, high readiness: start here. Reporting, reconciliation, proposal drafting, client onboarding checklists. These are exactly the business-process workflows dominating real-world agent usage, and wins here are visible within weeks.
2. 2High value, low readiness: fix, then automate. This quadrant holds your biggest prizes, and the wins from quadrant one fund the cleanup: the permissions work, the decision-point fixes, the entity naming.
3. 3Low value, high readiness: delegate to enthusiasts. Let keen staff automate these themselves as practice. Cheap capability building, no committee required.
4. 4Low value, low readiness: ignore. Revisit next quarter. Most of these die of natural causes.

The discipline that makes the matrix honest is measuring results on your own tasks rather than trusting vendor demos; we have written a full method for that in how to evaluate AI agents. A use case is not "done" when the agent produces output. It is done when the output survives review at a defined quality bar.

Where to Start This Quarter

Run the inventory this week: five operators, one hour, a list of where decisions actually get made. Connect the top three systems read-only, capture two tacit processes from your most senior person, and put one high-value high-readiness workflow through an agent end to end. That is a quarter of work for a fraction of what the replatform pitch costs, and it leaves you with a working company brain instead of a project plan for one.

If you want an outside pair of eyes on it, our Deep Dive does exactly this: we map your systems, score your use cases on the value-times-readiness matrix, and hand you a prioritised rollout plan grounded in what your data can support today. No warehouse required.