The handoff is the deliverable

An agent system built by an outside hand has two possible endings. In one, the builder leaves and the system keeps improving, because the people who own it can change it without fear. In the other, the builder leaves and the system freezes, because every change is a gamble nobody wants to take. The running system can be identical in both endings. The deliverable is not.

Our position is simple. For anyone who builds an agent system they will not operate forever (a studio, a consultancy, the one engineer who built it before moving teams), the real deliverable is not the running system. It is the client's ability to change it safely after you are gone. Dependence is a defect, not a moat. A client who cannot touch their own system has not bought a system. They have rented one, and the rent is your calendar.

Why agent systems fail the handoff

Ordinary software has a settled handoff culture: a repo, a test suite, a pipeline, a new maintainer who reads the code and gets to work. Agent systems break this in four places.

Prompt spaghetti. Prompts accrete. A production system prompt is often two thousand words of instructions, exceptions, and exceptions to the exceptions, each one a scar from an incident nobody wrote down. The author can read it because the author remembers the incidents. Nobody else can, so nobody else edits it, and the prompt hardens into load-bearing folklore.

Opaque memory. Many systems carry a vector store or scratch memory that nobody can inspect or explain. What is in it? How did it get there? What happens if we clear it? If the honest answers are “unclear”, “gradually”, and “we would rather not find out”, that is not a component. It is a liability with an embedding index.

Behaviour that lives in vibes. The system “seems fine”. There is no eval suite, so correctness is a feeling held by whoever watched the system longest. Feelings do not transfer. When that person leaves, so does the ability to tell a safe change from a regression, and the rational response is to touch nothing. A system nobody dares touch is already legacy, however new it is.

Foreign glue. The orchestration lives in a framework the builder loves and the client's team has never used. Every future change now begins with learning a framework, which means most future changes never begin.

None of these are model problems. They are architecture problems, and all of them are avoidable if you accept one constraint: design the departure first.

Designing for departure, concretely

We design the handoff before we design the agent. In practice that means five artifacts, started on day one, not assembled in the final week.

An eval harness that works as a guardrail. The contract is blunt: if the suite passes, the change ships. A few hundred cases covering the core tasks, the known failure modes, and the expensive edge cases turn prompt editing from an act of courage into an act of engineering. This is the highest-leverage artifact in the handoff. Without it, every other document is decoration.

Prompts and seed documents in the client's language, with a named owner. Write prompts in the vocabulary of the client's domain, not in your house style, and keep every instruction traceable to a requirement someone in the building can state. Then give each document an owner by name: the person entitled to edit it, and expected to. An unowned prompt is an orphaned one.

Memory you can open and read. For every store the system writes to, a one-page answer to four questions: what it holds, how long it holds it, who may write to it, and what breaks if it is emptied. If a store cannot be inspected, replace it with one that can. If it cannot be explained, it does not belong in production.

Boring orchestration in the client's stack. If the client runs Python and Postgres, the orchestration is Python and Postgres: a queue, a state machine, explicit retries. The exotic framework saves the builder two weeks and costs the client every engineer who must learn it later. We pick the tool the next maintainer already knows, even when a cleverer one exists. Especially then.

A runbook for the three most likely failure modes. Not a wiki. Three pages, each ordered the way an engineer at 2 a.m. wants them: symptom, diagnosis, remedy. For agent systems the usual three are a model provider that degrades or changes behaviour, a tool the agent depends on that starts failing, and output quality that drifts without an error being thrown. A team that can handle those three without calling you can handle most weeks without calling you.

The ritual of leaving

Artifacts are necessary and not sufficient. Ownership transfers through practice, so we run the departure as a ritual with three parts.

Teach-back, not walkthrough. The client's engineer explains the system to us, room by room, while we ask the questions an incident would ask. The direction matters. A walkthrough measures the builder's ability to present. A teach-back measures the client's ability to own. Whatever they cannot explain, we have not finished building.

They drive, we watch. A defined stretch, a few weeks is usually enough, in which the client's team makes the changes, runs the evals, ships the deploys, and takes the pages while the builder stays in the room, hands off the keyboard. Confidence comes from doing the work while the safety net still exists, not from reading about it after the net is gone.

Explicit transfer, per component. Ownership is not a mood at the end of an engagement. It is a checklist. For each prompt, each memory store, each pipeline, each dashboard: a named owner has accepted it, edited it at least once, and watched the eval suite pass afterward. When the last line is signed, the engagement ends. Not before.

Keys, not a lease

We build by one metaphor: an agent system is a small building. Rooms with a purpose, doors in the right places, corridors that make the next room obvious. An architect who did the work hands over keys and a set of drawings, and the building outlives the relationship. An architect who hands over a lease has built a different business, and the client should read the fine print.

If the handoff scares us, we built the wrong system. So we design the day we leave before we design anything else, then walk back to day one. Done properly, the departure is the quietest day of the engagement. That is the deliverable.