delegation-spec

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:

1. 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)

2. Task -- what needs to be done

   • Accept natural language description
   • Extract: inputs required, outputs expected, quality criteria, failure modes

3. 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  # or before specific step
  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  # requires human judgment

  - stage: "After draft generation"
    check: "Does draft meet quality rubric?"
    action_if_fail: "Provide specific feedback, request revision"
    auto_passable: true  # can use rubric-based auto-check
    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:

1. Every identified failure surface has a corresponding mitigation (context, gate, or checkpoint)
2. No review gate uses vague criteria ("looks good" is not a check)
3. The spec is executable by someone who didn't write it
4. 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.