Belts: hand one agent’s output to the next automatically
Updated 2026-09-12
Turn a completion event into the next action
A belt is a directed connection between two cards. When the sending agent finishes its turn, SpeakCode transforms its captured output and delivers a payload into the receiving terminal. The common case connects two terminals: one agent finishes, and the next terminal receives captured text, a fixed command, or an Enter keypress.
Choose the sending terminal, destination, and delivery mode before connecting them. The sending terminal determines whose completion starts the handoff; the mode determines what arrives; the destination determines how those bytes will be interpreted. A review prompt belongs in an agent terminal, while a test command belongs at a shell prompt.
A task dependency expresses ordering between tasks. A belt performs a handoff. Drawing a belt does not establish that the work passed tests or met acceptance criteria. It arranges delivery when a turn finishes. The parallel agents overview provides context for arranging multiple agent terminals around this workflow.
Know when a belt fires
New belts fire when the sending agent finishes its turn. With Claude Code completion hooks or Codex notify configured, completion is explicit: the agent reports the turn boundary. You can configure those signals using the agent status hooks guide.
Without hooks, the quiet-output settle heuristic stands in for completion. After changing output holds still, SpeakCode treats the terminal as settled. This fallback is approximate: an agent can pause before its work is finished. Configure hooks before relying on a handoff to start a review or test run.
You do not need to select a different trigger for the recipes below. Draw the connection, choose its delivery mode, and verify the first handoff. Remember that finishing a turn says nothing about whether the implementation is correct or whether a reviewer found a problem.
Choose what the destination receives
The belt inspector offers three delivery modes. Each submits to the target terminal with a carriage return, equivalent to Enter for both an ordinary shell and an interactive agent terminal.
Press Enter
Press Enter sends no text. Use it to submit something you already prepared in the target. For example, type the repository's test command at the target shell prompt without submitting it, then let an agent completion supply Enter.
This mode sends Enter even though there is no text payload. Its meaning depends entirely on the destination's current state. Check what is waiting there before you connect the belt, especially when the target is an interactive agent rather than a shell.
Run command
Run command sends a fixed string plus Enter, independent of the sending agent's output. For example, if your Python repository uses pytest, enter pytest in the inspector's command field and target a running shell at the project directory. Each completion sends that same command.
The label describes delivery of terminal input. If the destination is Claude Code, the fixed string is read as an agent prompt; if it is a shell, it is read as a shell command. An empty command does nothing. Use your project's existing test command rather than assuming that one test runner fits every project.
Deliver output
Deliver output pastes the last 40 non-blank lines of the sending terminal's captured screen and submits them. This is useful when an agent ends with a concise handoff containing file paths, test results, and an unresolved question.
The inspector exposes these three modes. Deliver output uses a screen capture rather than a complete conversation transcript or an automatic repository diff. Put the important details near the end of the agent's response so the receiving agent gets enough context to proceed. If you need a consistent instruction regardless of the visible output, choose Run command instead.
Draw and inspect a belt
- Put the sending and receiving cards where you can see them, and use the select tool. Belt ports are hidden at the far zoom level, so zoom in if they are absent.
- Click the cyan belt port on the sending card's right edge. That card gains a cyan ring, and other visible cards show a dashed Belt to here target.
- Click the intended destination card. The new belt fires on turn completion and uses Deliver output with the last 40 non-blank lines by default.
- Click the settings bead at the belt's midpoint to open the belt inspector. Choose Press Enter, Run command, or Deliver output. For Run command, fill in the command field.
- Check that the target terminal is running and ready at a prompt before letting the sending agent finish. Observe the delivery and the destination's response before relying on repeated handoffs.
To cancel while choosing a destination, click the sending card's red cancel mark or empty canvas. You can delete a connected belt from its inspector. Switching delivery modes updates the existing belt rather than adding another one.
Recipe: Codex implements, Claude Code reviews
Use two running agent terminals that can access the code you intend to review. Configure completion signaling for the Codex terminal, then draw a belt from Codex to Claude Code.
For a repeatable review request, select Run command and enter this prompt in the command field:
Review the current changes without modifying files. Look for correctness bugs, missing tests, and unintended behavior. Report findings with file paths, or state that you found none.This is prompt text you supply. It makes the review instruction independent of whichever lines happen to be visible in Codex's screen. Leave Claude Code ready for input, then ask Codex to implement a bounded change. When its turn finishes, the belt submits the review prompt to Claude Code. You see the prompt arrive in the receiving terminal and Claude Code begin its review.
Alternatively, prepare Claude Code to treat the next incoming message as an implementation brief, then use Deliver output. Ask Codex to end with changed paths, tests performed, and open concerns. Keep that brief short enough to survive the last-lines capture. In either version, read the resulting review before deciding what to change next.
Recipe: Claude Code finishes, the test terminal runs
Start a separate shell terminal in the repository and confirm that the appropriate test command works there. Draw a belt from Claude Code to this terminal and select Run command. For a repository that uses pytest, the command field can contain:
pytestWhen Claude Code finishes its turn, the belt types the command and submits it. Claude Code's captured prose is irrelevant in this mode. You see the command appear at the shell prompt, followed by the test runner's output. Keep the test terminal at an available shell prompt before the handoff; a running terminal is not necessarily ready to accept a new command.
For a manually staged handoff, type the same test command without Enter and choose Press Enter instead. This lets you inspect the staged command before the agent's completion submits it. Read the test output to determine the result; a completed agent turn does not certify that the tests passed.
Recipe: chain three terminals — Codex implements, Claude Code reviews, the test terminal runs
Combine the two handoffs into one chain. Open Codex, Claude Code, and a shell terminal where the project's test command works. Configure completion hooks for both agents, and make sure they can access the changes being implemented and reviewed.
- Draw the first belt from Codex to Claude Code. In its inspector, choose Run command and enter the review prompt from the first recipe.
- Draw the second belt from Claude Code to the shell terminal. Choose Run command and enter
pytest, or replace it with your project's test command. - Give Codex a bounded implementation task. Leave Claude Code at its input prompt and the test terminal at its shell prompt.
- Watch the first hop: Codex finishes, the review prompt appears in Claude Code, and Claude Code begins reviewing the changes.
- Watch the second hop: Claude Code finishes its review, the shell receives the test command, and the test runner begins printing results.
- Read Claude Code's findings alongside the test results. The second belt runs after the review turn completes, including when the review reports problems; it does not interpret the review as an approval.
Both downstream terminals must be at a prompt when their handoff arrives. The belt does not wait for a busy reviewer or a running test process to become ready. Before starting another implementation turn, check that Claude Code and the shell are ready to receive the next delivery.
Check the limits before repeating a workflow
- A stopped target receives nothing. A belt never starts a shell for you. Delivery is dropped when the target is not running; a later completion can deliver again, but the dropped payload is not queued for replay.
- Running does not mean idle. The guard checks whether the target is running. Check the target prompt yourself rather than assuming delivery waits for an agent or test process to become ready.
- The captured screen is bounded context. Include important paths and questions near the end of the sending agent's response, or use a fixed prompt that tells the reviewer what to inspect.
- Empty text normally does nothing. Press Enter deliberately bypasses that guard; an empty Run command does not.
- One agent can feed several terminals. Every enabled outgoing belt fires on completion. Inspect those connections so you know which terminals will receive a handoff.
- A finished turn is not a quality gate. Read the resulting review or test output before taking the next consequential step.
Questions
Does a belt start the destination terminal?
No. Delivery is dropped if the target terminal is not running, and the belt never starts a shell for you. A later completion can trigger a new delivery.
Is a belt the same as a task dependency?
A dependency expresses task ordering. A belt transforms and delivers terminal input when the sending agent finishes its turn.
Does Deliver output send the full agent conversation?
Deliver output sends the last 40 non-blank lines of the captured terminal screen. It is not a full conversation transcript or repository diff.
Can one agent feed several terminals?
Yes. One agent can have several outgoing belts, and every enabled one fires when it finishes its turn. Keep each receiving terminal running and ready at a prompt.