From idea to handoff package

An agent rarely fails because it is missing one sentence. It fails because the idea exists only in people's heads: the goal is roughly understood, important decisions are buried in a chat, and nobody has written down what would make the result complete. A handoff package turns that uncertainty into a work situation that can be passed on.

The package is deliberately small. It is not meant to cover every eventuality, but to secure the few things that cannot be reconstructed later: why something was decided one way and not another, what is explicitly out of scope, and how success can even be recognised. Four documents and a running log — nothing more is needed at the start.

An idea is not yet an assignment

"Build me a good solution" can be a useful opening for a conversation. It is not enough for execution. What does good mean? Who will use the outcome? Which decision should it make easier? And what is explicitly outside the scope? As long as those questions remain open, an agent must guess or decide silently.

A handoff package does not demand excessive planning. It simply preserves the information that must not get lost later. The idea stays alive, but gains a visible core: a goal, an audience, a sensible scope and an initial measure of success.

The most expensive part of an idea is often the part nobody said out loud. Naming the scope deliberately — and equally what is not part of it — spares you the harder discussion later about whether a result was built "past the brief." A clear boundary is not a loss of ambition; it is the condition for ambition to land in the right place.

Four documents create a reliable beginning

The first document is the start prompt. It describes the task in ordinary language: the desired outcome, the users, the occasion and the frame. It can be short. Its job is orientation, not technical completeness.

Then come three additions. A small architecture map records the parts to be created and how they work together. A rule sheet names boundaries, data sources, permitted changes and cases that require a question. Finally, the acceptance plan states concrete observations: what must work, be visible or be checked at the end? Together, these documents prevent a system from turning a vague intention into a seemingly finished but wrong solution.

The four documents divide the work cleanly: the start prompt says where it is going, the architecture map what it is made of, the rule sheet what must not happen, and the acceptance plan how you recognise the end. When one is missing, the agent fills the gap with a guess — and guesses are exactly the places where projects later drift apart. Four short documents are not paperwork; they are the shortest way to prevent a misunderstanding.

Decisions need a home

Assumptions change during a project. That is normal. It becomes a problem only when the change survives as a side remark in a conversation. The next person or agent then works from an old reality. Each important decision therefore needs a short entry: What was decided? Why? Which alternative was rejected? And what follows from it?

These entries do not need to be long minutes. Three clear sentences are often enough. What matters is that they can be found. A handoff works not because everything is documented, but because the few things that change direction, risk or quality are documented.

A decision log also protects the people who decide. It records that a choice was made deliberately and with a reason — not by accident. If a rejected alternative later turns out to have been better, the log shows the assumptions under which the call was made at the time. That turns course changes into a normal event rather than a blame game.

Acceptance is a conversation about evidence

"Done" is not a state an agent should define alone. Good acceptance translates the goal into observable evidence. Instead of "The interface should be intuitive," write: "A new person can find the three most important steps without explanation and receives a clear question when information is missing." This is not perfect; it is testable.

Plan for the moment when something does not fit as well. Who can decide whether a deviation is acceptable? Which change needs a conversation? Which tests must be repeated? The handoff then becomes more than a neat stack of files. It becomes a shared basis for implementation, review and continued work.

The smallest useful handoff package

A single card holds the package together. It fits on half a page and travels with the initiative — copy it to the start and fill it in before the agent begins.

# HANDOFF PACKAGE

**1. Start prompt**
Goal, users, occasion, desired outcome and scope.

**2. Architecture map**
Parts, interfaces, materials and open assumptions.

**3. Rule sheet**
Allowed, prohibited, sensitive data, questions and decision rights.

**4. Acceptance plan**
Observable criteria, test cases, owners and approval.

**Decision log**
Decision · reason · consequence · date

A handoff package replaces neither thought nor judgement. It simply makes sure both arrive where the work happens. The clearer the goal, boundaries, decisions and evidence, the more freely an agent can work within the frame — and the easier it is to take responsibility for the outcome.

Worksheet: Hand over an idea so it can move forward

Choose a small initiative you genuinely want to implement. Do not aim for perfect documentation. Create a first handoff that can be checked.

Write the start prompt. Describe the goal, users, desired outcome and deliberate scope in no more than eight sentences.

Draw the architecture map. List the parts, existing materials and two open assumptions. Also name what should not be built.

Set rules and questions. Write three boundaries and two situations in which a question must be asked before work continues.

Make acceptance observable. Write three criteria someone can test or see. Add who gives final approval.

All materials to download — the topic overview and the worksheet: