Request a scoping call Contact
← Research

The architecture outlives the team that built it

Design an AI service so a successor team can operate, evaluate and change it. Retain decision records, quality criteria and reproducible dependencies, then test the handover instead of assuming documentation is sufficient.

Method / Conceptual study
Separate before comparing.
  1. Development groups
  2. Hold-out boundary
  3. Test groups

Keep development and test groups separate before comparing performance. No measured results are shown.

Key-person dependency needs a testable mitigation. A risk-register entry saying “documentation” leaves open which records exist, whether they are current and whether a successor can use them. Identify the services that depend on one person’s knowledge and demonstrate the handover capability they require.

Staff movement between frontier laboratories offers context for the concern. Fortune reported an arrivals-to-departures comparison in August 2026, including a decline in the cited DeepMind ratio from roughly twelve to two over three years. Treat this as a reported laboratory comparison, not an estimate of an enterprise team’s retention or a completed annual workforce measure.

Senior arrivals per departure at one laboratory, three years apart Fig. 01
  • Second quarter, 2023 12 per departure Twelve senior arrivals for every departure.
  • Third quarter, 2026 2 per departure Two, in the same roles.

Reported by Fortune, August 2026

An AI service should remain operable when the people who designed it move on. Set that requirement from the service’s consequences and dependencies. It does not require a forecast of staff departures.

What actually leaves with a person

Code is only part of the retained knowledge. A successor also needs the reasons for decisions, the quality standard, known limitations and the people authorised to resolve them. Those records must be accessible and maintained alongside the service.

What is unavailable once the person who knew it has gone Fig. 02
  1. Loss 01 Why it is like this The alternatives considered and rejected, and the constraint that decided it. Nowhere in the code.
  2. Loss 02 What good looks like The judgement about whether an output is acceptable, held as expertise rather than as a test.
  3. Loss 03 What was tried and failed Retain unsuccessful approaches and the conditions in which they failed.
  4. Loss 04 Which parts are fragile The workaround, the thing nobody touches, the manual step before every release.
  5. Loss 05 Who to ask The relationships across the business that made the system work operationally.

A labelled evaluation set can preserve important judgements about acceptable outputs. Keep the labels, adjudication rules and task scope with it, and identify decisions that still require specialist review. The successor should be able to use this evidence to assess a change rather than reconstruct an undocumented standard.

The evaluation set transfers part of the quality standard between teams. Decision records, operating procedures and business expertise transfer other parts. Test the combination through a handover exercise. No single artefact captures every judgement needed to run the service.

Designing for the departure

Maintain business accountability independently of the delivery team’s membership. Name the owner who can accept the service scope, prioritise changes and decide whether work should pause. Technical ownership remains necessary, but it should connect to a durable business decision role.

The version of this that is a commercial argument

An organisation may retain specialists, buy delivery support or use ongoing independent advice. Each arrangement has cost and knowledge dependencies. Assess what the client retains and what becomes unavailable if a person or supplier leaves.

Ongoing architecture advice can support decisions without moving accountability out of the organisation. The client should retain readable decision records, evaluation assets and the specifications needed by its delivery team. A successor adviser must be able to assess the work without depending on the original adviser’s private knowledge.

An advisory relationship that makes an organisation dependent on the adviser has solved the same problem in the same wrong direction. The test is simple and it is worth applying to us as well as to anyone else: if this supplier stopped returning calls, what would we be unable to do.

What this does not tell you

The figures above describe movement between frontier research laboratories. They are not a measurement of enterprise AI teams, whose retention picture is different and much less well documented, and it would be sloppy to present them as one. What they support is a directional claim — senior capability in this field is mobile — not a rate that applies to your organisation.

Documentation needs maintenance and practical validation. Ask a successor to run the evaluation, reconstruct a derived asset or investigate a retained trace using the agreed records. Written instructions explain the method. The exercise shows where access, expertise or dependencies are still missing.

The risk owner should name the service, the dependent knowledge and the evidence needed for a successful handover. Scope and rehearse the most consequential cases first. Use the results to decide which gaps require records, training, access changes or additional ownership.

Filed under · Method · Operating model · Method · Advisory Inference Institute · 02 Oct 2026 (updated)

Bring us the question

Reading this because it is on your desk right now?

That is the conversation we are best at. Thirty minutes, a written summary, no obligation.