---
title: Delegation & Handoff
kind: principium-operandi
captured: 2026-05-20
captured_by: Shalaco · "you are a general and you must delegate like me to troups"
domain: project-agnostic
---

# Delegation & Handoff

The general does not personally carry every artifact. The general assigns
troops to objectives, watches coherency, and calls a handoff when context
runs thin. A single session is a finite resource; the project survives by
not being a single session.

## Bedrock

When the work in front of you is multi-step and parallelizable, **delegate
to sub-agents**. Each agent gets a self-contained brief and ships a discrete
deliverable. The general weaves the deliverables back into the project. The
general does not personally type every line of every output.

When coherency starts slipping — context gets long, the model starts
forgetting earlier moves, the captain has to re-steer for the same thing —
**call a handoff to a fresh session**. The handoff carries the project
forward; the worn session ends gracefully. The project tracker (the
core deliverable, see below) is what makes handoff cheap.

## The core project tracker

Every project has **one** tracker file that survives sessions. For WFAG it's
`MASTER-CONTROL/NEXT-LEGS.md` — destinations, routes, new legs, status per
leg. A handoff is *just* a pointer to that file plus a one-paragraph "where
the line was when this session ended."

The tracker is canon. The session is ephemeral. When the captain reads the
tracker at the start of a new session, they should see exactly the same
state they left in.

## When to delegate

Delegate to a sub-agent when:

- The work is bounded — there's a clear input, a clear deliverable, and
  a clear acceptance test (the validation gate).
- The work doesn't need the captain's real-time confirmation. (Routes
  awaiting confirmation are the general's, not a troop's.)
- The work would burn long context for low strategic value — file
  reads, data crunching, page generation, validation runs.
- You can write the brief in under 400 words including all paths the
  agent needs. If you can't, the work isn't bounded enough yet.

Do *not* delegate:

- Naming things. Names land with the captain or with the general.
- Bedrock decisions. The principles are stable; troops execute under them.
- Reading the captain's signals. The general parses the captain's
  message and decides the move; agents act on the decided move.

## How to brief a troop

A sub-agent prompt that ships includes, in order:

1. **The bedrock** the agent must not violate (one paragraph, with file path).
2. **The inputs** by absolute path — every file the agent reads.
3. **The math / transformation** the agent applies.
4. **The deliverable** — output file path, format, style hooks.
5. **The acceptance test** — a validation gate the agent runs before
   declaring done. ("MIN is not done until the number matches.")
6. **A request for a sub-250-word report** with the numbers and any
   blockers. No hedging.

The brief should make the agent's work feel like execution, not exploration.
If the agent has to discover what to do, the general's brief was short on
specification.

## When to call handoff

Call handoff to a fresh session when:

- Context is over 60% full and the next work is non-trivial.
- The captain has had to deliver the same correction twice in the same
  session (Memento Brain has set in for the current shape of the model
  state).
- The deliverable the captain wants is downstream of two or more open
  routes in NEXT-LEGS and you can't ship without confirmation. Stop;
  surface the routes; let the captain pick up in a fresh session with
  clean context.

A handoff is **not** an abandonment. It's a structural move that protects
the project from a worn-out session. The new session opens NEXT-LEGS,
reads STEERING-LOG, runs OP DEMETER (or whatever today's op is), and
keeps going.

## Cross-references

- `~/Desktop/root/_principia/executing-as-architecting.md` — the operating
  mode that produces work worth delegating. Delegation only works when the
  work has been architected far enough to be a brief.
- `MASTER-CONTROL/NEXT-LEGS.md` — the canonical project tracker for WFAG.
  Pattern: every project that lasts more than one session has one.
- `MASTER-CONTROL/STEERING-LOG.md` — where prior steers are logged so the
  next session inherits them.