Every firm has somebody responsible for inducting a new hire: what we sell, how we price, which numbers the board looks at, what we no longer do. Almost none has anybody responsible for inducting its AI. So a system capable of reading every document the firm has ever produced drafts the proposal in the wrong voice, quotes last year’s pricing and answers a question about margin with a number finance doesn’t recognise. In many firms I see, AI is running on air: on whatever context somebody pastes in that day, and on nothing the business has agreed is true.
That gap is where the learning loop most firms say they want should sit (their knowledge getting better each time AI uses it and somebody corrects it), and nobody has been given the job of running it.
Isn’t it all in the documents already?
Some of it. Every firm of any age has documents and data (proposals, board papers, contracts, procedures, product guides, plus a CRM and a finance system). Very few have an agreed account of what any of it means. Give a capable model access and ask what revenue was last quarter, and it will find four defensible answers in four systems with no basis for choosing between them. That isn’t a search problem, and a bigger model doesn’t solve it. Somebody has to decide which number the firm uses, write that down, and also remember to say when it stops being true.
Building Ada Health (a diagnostic AI for medicine), we assumed the reasoning engine would be the hard part. It wasn’t easy, but what set the product apart was less glamorous: how we codified medical knowledge so the engine could work with it at all. I remember Martin Hirsch, one of Ada’s co-founders and then its Chief Scientific Officer, describing the job as making medical knowledge “reason-able” (capable of being reasoned upon, rather than only read). It took a team of doctors, a new way of organising medicine (a bespoke ontology) and several years. Palantir has built a large business on the same concept for companies: work out what a business’s data means, write down the rules that connect it, and let software reason over it, all on Palantir’s own platform. The difference now is that, at a basic level, the authoring tool can be a chat window and the language is plain English, which puts the basics within reach of your own team. What it cannot work without is the people who know the answers.
So why doesn’t it happen?
Because the work falls on people who are paid to do something else. Connecting AI to your systems is a technical job with a familiar home (the tech or IT team), a budget line and a manager. Codifying what is true, or the agreed way to do something, often has none of these. Only the finance director can say which revenue treatment is right, only the product lead which features are still sold, and only the salesperson which of the last five pricing approaches is still policy. Asking your finance director or your best salesperson to spend a day a month writing down how the firm defines things is asking them to give up time from the work they are measured on, against an objective nobody set them, for a benefit that lands somewhere else later on. So it doesn’t get done. The connections get built, the right answers never arrive, and the conclusion is the technology was disappointing.
Put bluntly: if some of your senior experts can’t spare a day a month to start with (and once it is working it is nearer a day a week), you mostly have AI subscriptions rather than an AI programme.
Nor does it stay done. Definitions change, policies get superseded, and last year’s pricing has to be marked as last year’s. The job is codifying and then recodifying, which is why it belongs in somebody’s objectives permanently rather than in a project plan.
What does it look like when somebody owns it?
Unglamorous, mostly, and the pattern repeats. Intercom, whose Fin agent answers support queries for more than 12,000 companies, reports resolution rates averaging 76% and rising about 1% a month, and by its own account the method is this loop: train the agent on your own knowledge and policies, then analyse where it falls short and improve the content. In the implementations I have seen, resolution starts nearer 30% and takes the best part of a year to reach that average, through exactly this loop.
We are seeing the same pattern in our own portfolio. At one company, the bid team’s answer libraries, product material and security documentation were brought together into one maintained knowledge base. An RFP response that took several working days now takes under an hour, with most answers needing only light editing and traceable to their source; one of the team describes them as “95% there” on the first draft. At another, a product knowledge base has cut the time spent on each of hundreds of product marketing guides by nearly 90%, and the same knowledge now feeds customer support and marketing live.
At a far larger scale, Uber came at it from the other end. It embedded thirty of its most AI-proficient engineers with teams including finance, legal and HR for two weeks at a time, to build agents for their tasks. Its CTO’s conclusion: “You can’t automate them effectively by looking at process diagrams or documentation. You have to understand how the work actually gets done.” Having learned that, Uber is making it permanent: “We’re now forming a dedicated team to scale this further and go deeper.”
Won’t the models just work it out?
Partly, and increasingly. Each generation of model needs less instruction, and specialist vendors will happily rent you ready-made know-how for common tasks. Follow that through, though. Whatever a model can work out without your firm’s judgement, your competitors’ models can work out too, at the same moment in time. What is uniquely yours is what your people know and your systems record, and the loop is how you make sure it compounds (instead of knowledge leaving with the people when they go).
Where do you start?
1. Start with the knowledge your two or three priority AI uses depend on, not the whole firm. Write it as plain documents you own, each with a named owner and a date by which it gets reviewed (some ways to do this are listed below).
2. Name an owner for each area and put the time in their objectives. A senior expert, not an intern, and permanently rather than as a secondment.
3. Send every correction back to the source. When the AI gets something wrong, fix the document it read as well as the answer. That is the loop at its most basic.
4. Choose tools on four questions. Do we own the knowledge in a form we could take elsewhere? Can we change model without rebuilding? Can every answer be traced to its source? Can we test it before we trust it? (Some places to look are below.)
What we take from this
The decision that matters is who in your firm owns what it knows, and whether that work sits in their objectives with the time to do it. Get that right and the choice of platform becomes a secondary one.
We expect the firms that make that decision to pull away slowly at first and then quickly, because what they write down compounds, and what anyone can rent does not.
I am conscious that this makes the investment sound like an easy decision. It isn’t. Most mid-market businesses run lean, and the people who would do this work are already fully stretched delivering the business as usual. I raise it because AI spend in many businesses has already become significant, the returns are not being recognised, and frustration in leadership teams is growing. The aim here is to show where the failure points tend to sit, so that the decision on whether and how to fix them is an informed one.
One honest warning. In the early months, the loop takes more than it gives. That is normal and needs to be planned for. Start small, and the benefits will arrive sooner.
Where to look
Examples rather than recommendations. What suits your business depends on what you already run on today.
- Somewhere to write it down. Usually what you already have (SharePoint, Google Drive, Notion, Confluence). Plain, dated documents with an owner beat a new platform at the start. For how to write them, two conventions are worth a look: Andrej Karpathy’s LLM wiki pattern, and Google’s Open Knowledge Format (young, and governed by Google alone).
- AI that can read it. The enterprise assistants most firms already license (Microsoft 365 Copilot, ChatGPT Enterprise, Claude, Gemini), connected to those stores with the same permissions your people have.
- Checking it works. Whatever you choose should show which document each answer came from, and let you run a set of questions with known answers before you roll it out and after every change.
- Keeping the option to change model. Workspaces that sit over several model providers, so your knowledge and your workflows are not tied to one of them. The Microsoft stack can enable this and is being built on this principle, but in my experience can be painful to put together. Langdock, for one, offers a more user- and administrator-friendly option, and has grown rapidly as a result.
- People to do it with you. Your own engineers pointed at the business for a fixed period, as Uber did, or the forward-deployed engineers that model providers and AI consultancies now offer.
- The deep end, later. Ontology platforms in the Palantir mould, and a growing set of more open and cheaper alternatives (graph databases such as Neo4j among them), for when the basics are working and you need the data and the rules connected at scale.
