A real delegation handoff, spec tight enough to execute cold

What a handoff package is

A handoff package is the artifact one agent gives another (or one operator gives a build agent) when work has to transfer cleanly across a boundary. It is the difference between "tell the next person what to do" and "send the next person everything they need to execute correctly without interpreting your intent."

Most consulting deliverables are not handoff packages. They are documents that describe what should happen and then leave the doing as someone else's problem. The methodology requires a stricter shape: every handoff is a SPEC plus enough scaffolding that an agent can act on it without iterating back to the originator.

This receipt walks one real handoff package: the dispatch delegation that captured the v2.6 Question Box SPEC.

The situation

On 2026-06-06 the operator needed a SPEC captured for v2.6 of the content engine: a Question Box surface on /log where visitors could submit questions, get triaged, and have answers posted as new blog content. The SPEC needed eighteen sections, eleven specific invariants, careful cross-references to parent SPECs, and strict scope discipline (SPEC capture only, no code generation, no implementation).

The operator did not want to write the SPEC by hand. The operator also did not want to verbally guide an agent through eighteen sections in real time. The right move was to build a delegation that captures everything the agent needs to write the SPEC correctly on its own.

That delegation is the handoff package this receipt documents.

What a handoff package contains

The delegation that got built had these load-bearing parts. They generalize past this specific case.

A current-time anchor. The delegation starts with an instruction to run the time tool so the agent knows the actual current moment, not a guess based on training data. Without this, dated work drifts.

An invocation of the relevant skill. The delegation tells the agent to use the specmesh-spec-capture skill so the SPEC structure follows the established discipline. This is delegation by reference: the skill carries the SPEC capture form; the delegation invokes it.

A precise task statement. Not "write a SPEC." The exact file path, the section structure, the commit message, the branch target. One sentence at the top so the agent knows what success looks like.

Read-first order. Eight specific files the agent should read before writing, in priority order, with one-line justifications for each. This prevents the agent from inferring context that it could verify directly.

The output structure spelled out section-by-section. All eighteen SPEC sections enumerated, each with the kind of content it should contain. The agent does not have to derive the structure from the skill's general form; the delegation specifies what this particular SPEC needs.

Verification commands the agent runs after writing. Concrete bash commands the agent should execute to confirm the SPEC meets gate criteria (size band, section count, I-code count, no code committed outside the SPEC).

Exact commit and push commands. Including the author identity forcing flags to satisfy the deploy platform's identity check, the precise commit message, the branch to push to.

Halt criteria. Conditions under which the agent must stop and surface to the operator rather than proceeding. These are explicit and listed so the agent does not exercise judgment about whether to continue.

Out-of-scope items. What the agent must NOT do, listed explicitly. Most failures come from agents doing more than asked. The delegation forbids implementation, forbids modification of other files, forbids deleting the SPEC file, forbids merging branches.

A final report template. What the agent should surface back when done. Time, sections covered, file size, hash, push status, anything surprising. Without this, the return signal is variable and harder to act on.

What this handoff produced

The agent that ran this delegation completed the work in under five minutes. The SPEC landed at the specified file path with all eighteen sections, all eleven new invariants grep-able in the content, pre-commit hook clean, pushed to the correct branch with the correct author identity. The final report came back structured, including one observation the operator wanted to know about (a cross-reference question that needed ratification).

That is a successful handoff. The agent did the work. The operator did not have to iterate. The result was auditable end-to-end via the commit hash and the SPEC file.

What the failure mode looks like without this discipline

Handoffs that are not packages produce one of two failure modes.

First, the receiving agent under-executes. It reads the request literally, does the smallest thing, asks back when it should have proceeded. The operator spends as much time guiding as it would have saved.

Second, the receiving agent over-executes. It infers context, extends scope, modifies adjacent files, makes architectural decisions the operator did not ratify. The operator spends more time reverting than the work was worth.

Both failure modes vanish when the handoff is a package. Scope is bounded explicitly. Halt criteria are listed. Out-of-scope is explicit. The agent operates inside the lines the operator drew, returns the artifact, and stops. This is gated autonomy at the delegation level: Tier 2 work, approve-then-execute, fully scoped by the operator before the agent acts.

The methodology lesson

A delegation is not a request. A delegation is a contract.

When the contract is complete, the agent can fulfill it without judgment calls. When the contract is incomplete, the agent must exercise judgment, which is where failure modes live. The operator's job in delegating is to make the contract complete enough that the receiving agent does not have to fill in the gaps.

The SPEC capture delegation referenced here is one example of a complete contract. The pattern reuses across every kind of agent work. The dispatch delegation for the security remediation looked structurally identical: read-first list, exact task, halt criteria, verification commands, commit and push template. The autoship pipeline delegations have the same shape. The teaching-system delegations for the consulting engagement (in development) will have the same shape.

The handoff package is the unit of agent-to-agent work. The methodology is the discipline of writing handoff packages that hold.

Verifiable artifacts

• The SPEC this delegation produced: SPEC-content-engine-v2.6-demand-driven-intake.md in the repo at commit 703f01e
• The verification commands the delegation specified, and their actual results in the agent's final report
• The structural shape that this delegation shares with other dispatched delegations across the repo

The delegation text itself is operator-internal. The output, the structure, and the discipline are public.