Specify the information contract at every agent handoff — what exact output does the next step need from the current one?

Why This Is a Rule

In software engineering, API contracts define exactly what data one module sends to another — format, content, constraints. Without contracts, modules make assumptions about each other's outputs, and assumption mismatches produce bugs. The same failure occurs in cognitive workflows: when one step's output is vaguely connected to the next step's input, the handoff loses information, produces mismatches, or requires the next step to re-derive what the previous step already computed.

An information contract specifies: "Step A produces [specific output]. Step B requires [specific input]. The contract between them is: A delivers [format] containing [content] that B can consume without additional processing." For a morning workflow: "Priority review produces a ranked list of top 3 tasks. Deep work planning requires a ranked list of tasks to schedule. Contract: priority review delivers 3 tasks with estimated durations; deep work planning consumes them without re-prioritizing."

Without the contract, the handoff is implicit: priority review might produce a vague sense of what's important (not a list), which deep work planning can't consume without additional prioritization effort. The contract makes the dependency explicit and auditable — you can check whether step A actually delivered what step B needs.

When This Fires

• When designing any sequential multi-step workflow (Map agent dependencies and arrange in topological order — no agent executes before its required inputs are available)
• When a downstream step frequently needs to redo work because the upstream step's output was incomplete
• When handoffs between steps feel fuzzy or require "figuring out" what to do with the previous step's output
• Complements Add verification checkpoints at every coupling point where one process consumes another's output unreviewed — break cascade chains (coupling point verification) with the specification of what to verify

Common Failure Mode

Vague handoffs: "After brainstorming, move to outlining." What does brainstorming deliver to outlining? A list of ideas? Clustered themes? A thesis statement? The vagueness means the outlining step starts by sorting through unstructured brainstorming output — re-doing work that brainstorming should have delivered. Contract: "Brainstorming delivers 5-7 key points clustered into 3 themes. Outlining consumes the themed clusters as section headers."

The Protocol

(1) For each sequential handoff in a workflow, define the contract: What the upstream step produces: specific, named output in a defined format. What the downstream step requires: specific, named input with content requirements. Match verification: can the upstream output be consumed by the downstream step without additional processing? (2) If there's a gap (upstream produces something the downstream can't directly use) → either adjust the upstream to produce the right format or add a transformation step between them. (3) Document contracts alongside the workflow sequence (Map agent dependencies and arrange in topological order — no agent executes before its required inputs are available). (4) During execution, verify at each handoff: did the previous step produce the contracted output? If not → the handoff is failing, and downstream steps will underperform.