Designing the organisation your AI works inside

One agent was never the hard part

The craft has moved quickly, and each step has been about controlling something new. The instruction. Then what the model can see. Then the environment it acts in, its tools, its permissions, and how far the damage travels when it is wrong. Then the loop that decides when it retries and when it considers itself finished.

All of that is well understood now. The difficulty starts one layer above it, the first time twenty of them have to work as an organisation rather than a crowd. Who specialises in what. Who hands to whom. What each is trusted to assert, and what happens to the other nineteen when one of them is wrong. That is closer to organisational design than to software architecture, which is why it gets skipped by teams who only recognise the second one.

Each part of the structure is owned, scoped and evaluated the way every agent we build is, with a named person accountable for what it asserts. This page is about what happens between them.

Signs you are already running one

Most organisations arrive at this point without deciding to. The symptoms are recognisable:

• Two or three models already touch the same workflow, and nobody has decided which one is authoritative when they disagree.
• A pilot that works beautifully when one person runs it comes apart when it has to run unattended across a whole process.
• Every new use case starts from scratch, so the fifth one costs about what the first one did.
• You can see what the system concluded, but not what it was working from, or how much of it was actually checked.
• The people who would have to rely on the output are still verifying all of it by hand, which means the time it was meant to save has not arrived.

Each of these is a structural problem wearing a technical disguise, and each is solved by design rather than by a better model.

The organisation is yours. The machinery underneath is ours.

Every structure we design is shaped by the business it sits in: your systems of record, your regulatory position, and the way decisions actually get made rather than the way the process document says they do. A structure that fits your operation would not fit the company down the road, and one built to fit both would fit neither.

What does not change from one operation to the next is the machinery underneath: the layer that runs the structure, enforces what each part may reach, carries evidence between them, measures whether they are still working, and records what happened. We arrive with that already built. Where something excellent already exists, we use it; our layer holds the parts together and has no interest in replacing the ones that already work.

So the design effort goes into your operation, and none of your budget goes into rebuilding plumbing. It is also why the first working capability arrives in weeks instead of after a platform-building phase you paid for.

Standing teams and task forces

Two shapes cover most of what an operation needs, and choosing between them is the first real design decision.

Standing teamsFor work that recurs

The weekly review, the intake process, the monitoring function. A stable structure of long-lived parts, each owning its piece, in a shape that changes rarely and stays legible to the people who own the process. It looks like an org chart, and this one executes.

Task forcesFor work you cannot scope in advance

A question arrives, the relevant specialists are brought in, and when one of them turns up something that opens a new line, whoever is needed to chase it joins. The lines run in parallel and stay separate until there is a reason to bring them together. When the work is done, the group stands down.

Most operations want both, and the interesting question is the boundary between them: which parts of the organisation are permanent, and which are raised as needed. Our layer runs both shapes and moves work between them, so that boundary stays a decision about your business.

One separation holds inside either shape: the part that reviews work is never the part that produced it. A planning role sized to the judgement the decision needs, an execution role built for throughput and cost, and a review role answerable to neither of them, each staffed by whichever model fits its job rather than the same one wearing three hats. Self-review catches the errors a part already knows how to see, and misses exactly the ones it does not, which are the ones a genuinely separate reviewer exists to find.

Evidence travels with the work

Every hand-off carries more than data. A finding moves with a grade attached, and the layer carries that grade across every step of the structure:

• Measured. Taken from the work itself, against a definition you agreed.
• Verified. Checked against a controlled source, with the revision it was checked against.
• Stated. Found in an uncontrolled document or told to us, and true only as far as its author was right.
• Inferred. Reasoned from the above, and no stronger than what it rests on.

What reaches you is an answer you can read for how much weight it will bear: provenance intact, weak points visible, and a plain statement of what could not be established. When an auditor asks what a conclusion rested on, the trace is already there with its grades attached, because the recording happens as the work does and never has to be reconstructed afterwards.

The same rule holds when the pressure arrives from your side of the table. A senior person disagreeing with a finding is useful information, and it is not evidence, so it does not move a grade. Push back on a measured result and what comes back is the measurement, what would have to be true for it to change, and a concession limited to the part that was genuinely inferred. A tool that quietly downgrades its own conclusion because a senior voice pushed against it is worse than no tool, because it hands your own opinion back to you wearing a machine's authority. Where you are right, your correction enters as evidence and carries a grade like anything else.

Built with the people who do the work now

The specialists we encode are your specialists. We build alongside the people doing the work by hand today, because their judgement is what the structure has to carry, and because an expert who watches their own reasoning go into it arrives at ownership rather than suspicion. What that feels like for a team, and what it takes to get there, is adoption and organisational change.

Underneath sits the unglamorous half of the job: reaching into historians, document stores, maintenance systems and the rest, with their revision states and their thirty years of accumulated exceptions. The routes into those systems are part of the machinery we arrive with, which is why the interesting work starts in week two.

Where nothing may leave the building, the same structure runs inside your boundary, with open-weight models on your own infrastructure and no route out to the internet. The design does not change shape to accommodate that, because it was built by people who expected to be asked.

We stay while it runs

An organisation that is designed and then left alone drifts, and these drift quietly. We stay involved while the capability operates: watching the evaluations, retiring parts that have stopped earning their place, adding specialists as the work demands them, and keeping the structure honest as your operation changes around it. That continuing arrangement is managed AI and technology.

Adding a specialist to a running organisation is a deployment, not a project. That is the part that compounds: the second capability lands faster than the first, and the tenth faster still.