| name | delegation-spec |
| description | Generate a pre-flight delegation spec for any agent task -- context packages for memory-weak tools, review gates for opacity-prone tools, compounding checkpoints for stateless tools. The "test suite before the agent runs the work." Use when handing off a task to an agent, preparing a workflow for autonomous execution, or writing deployment specs for client agent systems. |
Delegation Spec Generator
Takes a tool + task description and produces a complete pre-flight delegation spec that patches the structural weaknesses of the target tool. Writes the tests before the agent runs the work.
Trigger
Use when the user says "delegation spec", "write a handoff spec", "prepare this for delegation", "pre-flight check", "agent handoff", "make this delegatable", "test before delegation", or is about to hand a task to an agent tool and wants to ensure it won't silently fail.
Phase 1: Gather Inputs
Collect three things:
-
Tool -- which agent or platform will execute the task
- If the tool was recently evaluated via
/eval-agent, pull the scorecard from that session
- If not, do a quick capability assessment (memory, inspectability, compounding -- score 0-1 each)
-
Task -- what needs to be done
- Accept natural language description
- Extract: inputs required, outputs expected, quality criteria, failure modes
-
Delegation mode:
- Fire-and-forget: agent runs autonomously, human reviews final output
- Supervised: human reviews at checkpoints
- Hybrid: autonomous for low-risk steps, supervised for high-risk
Phase 2: Identify Failure Surfaces
For the given tool + task combination, identify where silent failure is most likely:
Memory Failures
- Will the tool need context from previous runs? If yes and Q1 < 0.75: memory failure surface
- Will the tool need to remember decisions made earlier in this run? If multi-step and Q1 < 0.5: intra-run memory failure
Inspectability Failures
- Are there intermediate decisions that could go wrong silently? If yes and Q2 < 0.75: opacity failure surface
- Does the task require judgment calls the human would want to verify? If yes and Q2 < 0.5: judgment opacity failure
Compounding Failures
- Is this a recurring task where quality should improve? If yes and Q3 < 0.75: stagnation failure surface
- Could accumulated context from previous runs degrade this run? If yes and no rot detection: context rot failure
Map each failure surface to a specific step in the task.
Phase 3: Generate Context Package
For each memory failure surface, create a context injection:
context_package:
inject_at: start
contents:
- type: preferences
items:
- "Output format: [specific format]"
- "Tone: [specific tone]"
- "Constraints: [specific constraints]"
- type: facts
items:
- "Client name: X"
- "Previous output stored at: [path]"
- "Last run date: [date]"
- type: history
items:
- "Summary of last 3 runs: [compressed summary]"
- "Known failure patterns: [list]"
- type: templates
items:
- "Output template: [path or inline]"
- "Quality rubric: [path or inline]"
Phase 4: Generate Review Gates
For each inspectability failure surface, create a checkpoint:
review_gates:
- stage: "After research / data gathering"
check: "Are sources relevant and sufficient?"
action_if_fail: "Add missing sources, re-run stage"
auto_passable: false
- stage: "After draft generation"
check: "Does draft meet quality rubric?"
action_if_fail: "Provide specific feedback, request revision"
auto_passable: true
auto_check: "Score against rubric, pass if >= 7/10"
- stage: "Before final delivery"
check: "Matches expected format, tone, accuracy?"
action_if_fail: "Block delivery, escalate to human"
auto_passable: false
For each gate, specify:
- What to check (specific, not vague)
- Pass/fail criteria
- Whether it can be auto-evaluated or needs human eyes
- What to do on failure
Phase 5: Generate Compounding Checkpoints
For recurring tasks with compounding failure surfaces:
compounding:
after_each_run:
- capture: "What worked well"
store_in: "[memory location]"
- capture: "What needed correction"
store_in: "[memory location]"
- capture: "New patterns discovered"
store_in: "[memory location]"
every_n_runs: 5
- compare: "Run N output quality vs Run N-5"
metric: "[specific metric]"
alert_if: "quality decreased or plateaued"
rot_detection:
- signal: "Context package size exceeds [threshold]"
action: "Prune low-value entries, archive old history"
- signal: "Same corrections repeated 3+ times"
action: "Escalate -- tool is not learning"
Phase 6: Assemble Delegation Spec
Output the complete spec:
Delegation Spec
===============
Tool: [name]
Task: [one-line description]
Mode: [fire-and-forget / supervised / hybrid]
Risk: [LOW / MEDIUM / HIGH / CRITICAL]
Failure Surfaces Identified: [N]
Review Gates: [N]
Context Injections: [N]
---
PRE-FLIGHT
----------
[ ] Context package prepared and verified
[ ] Tool has access to required APIs/data
[ ] Review gate owners identified and available
[ ] Output destination confirmed
[ ] Rollback plan documented (if destructive task)
EXECUTION
---------
Step 1: [description]
Context: [what to inject]
Gate: [none / checkpoint name]
Max duration: [time limit]
Step 2: [description]
...
POST-FLIGHT
-----------
[ ] Output matches expected format
[ ] Quality rubric score: [X/10]
[ ] Learnings captured to [location]
[ ] Context package updated for next run
[ ] Run logged for compounding tracking
Verification
The spec is complete if:
- Every identified failure surface has a corresponding mitigation (context, gate, or checkpoint)
- No review gate uses vague criteria ("looks good" is not a check)
- The spec is executable by someone who didn't write it
- Rollback/failure paths are defined for each high-risk step
Source Attribution
Technique derived from Nate's Newsletter (2026-04-04): "I Tested Cowork, Lindy, Sauna, and Opal Against 3 Questions" -- the concept of "writing the tests before the agent runs the work" as a pre-flight delegation protocol, compensating for memory, inspectability, and compounding gaps.
