We kept rebuilding the same stack by hand on every transformation. A brain, agents, a delivery loop, a record of what happened. So we are productising it: the software that runs the factory we install during an AI Transformation Sprint.
An AI Operating System is defined as the software that runs a company's product knowledge and its agents together, in four parts: a brain holding a live, owner-approved view of the product knowledge; agents built from core skills plus per-company settings; a delivery loop that moves work from shape to design to code with humans holding the approval steps; and observability over everything entering the brain and everything the agents did with it. We are shipping ours in Q4 2026, first to companies that have already run a Transformation Sprint with us, then more broadly.
This is not a pivot into tooling. It is the result of installing the same thing by hand, over and over, and getting tired of it.
The blog went quiet between June and September. We were running transformations the whole time, inside real engineering organisations, with real deadlines. This product is what came out of that work. Every part of it exists because we hit the same wall on site and patched it by hand, again.
Across 90+ tech due diligences and 60+ products shipped since 2013, the pattern is boringly consistent. Five things break every time.
A transformation that depends on the consultant who installed it is not a transformation. It is a dependency with a nicer name.
| Part | What it does | Where humans sit |
|---|---|---|
| 1. The brain | A live view of the product knowledge, fed by merged PRs, company docs, support answers, meetings and threads, tickets and decisions. Ask it questions, get answers with citations. | Every item is draft until a named domain owner approves, updates or rejects it |
| 2. The agents | Core skills plus per-company settings. It separates what an agent should do, its instructions, from what it may touch, its permissions. | A team lead asks an agent to change its own behaviour; the agent opens a pull request describing the change in plain language, and an owner approves it |
| 3. The delivery loop | Shape with a product agent, then design, then human approval, then code with a coding agent, then human PR review, then the knowledge base updates itself. | Humans hold both approval steps. That is the design. |
| 4. Observability | One feed of everything entering the brain, with source, agent, owner and status. Every output traces back to its request and its sources. | The metric that matters is cost per accepted change, and it is visible to the team |
Two details are worth dwelling on, because they are where most agent deployments we review have gone wrong.
The first is the split between instructions and permissions. Most setups conflate them, which means tightening what an agent is allowed to touch also means rewriting what it is supposed to do. Separating them is what makes it safe to let a team lead change agent behaviour without a security review every time.
The second is that agent reconfiguration happens through a pull request in plain language. No YAML editing. The team lead describes the change they want, the agent writes the diff and explains it, an owner approves. The config history becomes a readable record of why the agents behave the way they do.
No YAML editing. If changing an agent requires knowing our file format, we have built a product for ourselves, not for the team.
The brain itself is the part most teams underestimate. We wrote up the progression in The Five Levels of the Company Brain, and the short version is that the jump from a searchable pile of documents to an owned, approved, citable knowledge layer is the jump that makes agents trustworthy. The delivery loop is the version of the Agent Pod model that survives contact with a real engineering organisation, and the observability layer is the one we argued for in how we ensure quality.
These are not features. They are constraints we are accepting now so that we cannot quietly drop them later.
If the knowledge and the agent configuration do not live in your repository, you are renting your own operating model.
The precedent is worth stating plainly, because it is the same move. We built TechSignal as a tool for our own due diligence work. We were doing the same engineering analysis by hand on every mandate, so we automated it for ourselves first, used it on live deals, and only then turned it into a product. It is public now and it runs inside the work we do for investors.
Same pattern here. 25 years in tech, 2 exits, 5+ AI-native products and teams built, and the tools we trust most are the ones we built because our own work demanded them. We are not designing this from a market analysis. We are shipping the thing we already use.
Q4 2026. Existing Sprint clients first, because their factory is already installed and their knowledge is already structured, then more broadly. Pricing follows the Sprint rather than standing on its own, and is published on the factory page, which is also where you register interest.
If you have not started, the entry points are unchanged. An AI Factory Assessment at EUR 4-6K tells you where you actually stand, which is usually a level below where the team believes it is, as the four levels of AI maturity keep demonstrating. An AI Transformation Sprint from EUR 26K installs the factory. The AI Operating System is what keeps it running after we leave.
Q4 2026. It goes first to companies that have already run an AI Transformation Sprint with us, because their factory is already installed and their knowledge is already structured. Broader availability follows. Register interest on the factory page.
Yes. The client owns everything. The knowledge and the agent configuration live in your own repository, not ours. If you stop working with us, the brain and the agent configuration stay with you, readable without our software. This is a constraint on the architecture, not a contractual promise bolted on afterwards.
It is model-agnostic and runs on your own API keys. New models land every few weeks, so we treat the model as a swappable component rather than an architectural commitment. Running on your keys also means model spend sits on your account, where you can measure it against output. The metric we care about is cost per accepted change.
No. We can host it, or you can run it on your own infrastructure if your security posture requires that. The knowledge and the agent configuration live in your repository either way, so the hosting decision does not change who owns what.
Three things. Ownership: every item is draft until a named domain owner approves, updates or rejects it, so the brain has a maintenance path instead of a decay curve. Agents: the same knowledge drives the agents that shape and build the product, and the delivery loop writes back to it when something ships. Observability: one feed of everything that entered, with source, agent, owner and status, and every output traceable to its request and its sources. A wiki tells you what someone wrote. This tells you what is true, who vouched for it, and what was built on it.
Pricing follows the Sprint rather than standing alone, and the figures are published on the factory page. The way in is an AI Factory Assessment at EUR 4-6K or an AI Transformation Sprint from EUR 26K.
Above The Clouds runs AI Transformation Sprints and Product Studio builds. Both leave the same thing behind, and from Q4 2026 there is software that keeps it running once we are gone. Get in touch to discuss your company or portfolio.