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.