Watch Pi subagents in action.
A real pi-subagentura workflow in tmux. The full 97:56 session is condensed to 8:06, with quiet stretches accelerated up to 100× and English translations over the original terminal.
The recorded workflow
The complete 97:56 session plays as one chronological record, with quiet stretches accelerated up to 100×. The original terminal stays visible; English translations make the Russian status messages readable.
Open the translated transcript
Yes. I reviewed the current head of PR #166.
I started two interactive subagents on Luna/max: an implementation worker in the separate worktree/branch feat/jev-routing-provider-neutral, and an architecture reviewer in feat/decision-plan-review. They communicate through pi-intercom; after the first commit I will continue with the upper layer and link the branches through gh stack.
Understood. I will wait for the subagent notification, then verify the commit and create the stacked PRs.
The second agent has written the tests; it only found missing node_modules in the new worktree. I’m waiting for the final commit before verifying both layers.
The generic decision core is implemented and in final checks; I’m waiting for its SHA before verification and stacked PRs.
The runtime agent exited after implementation but before commit. Its worktree, commit 72ca933, src/decision/* files, tests, and package allowlist survived; a new Luna/max agent continues verification and the provider-neutral branch is clean.
Which agent exactly? The decision-runtime-core agent exited after implementation but before commit. Why was the tmux pane closed?
The process exited 0 before completion while npm test was running; no stack trace or signal is recorded, and the worktree survived.
The agent confirmed bounded diagnostics with backward compatibility and no decision-routing changes. The second agent continues hardening the generic core; both work independently.
The bounded exit metadata design is good; I requested tests for signals, malformed data, parallel starts, and legacy support.
The decision stack was created. Both PRs passed the full suite and required checks; diagnostics remains a separate fix PR.
The second agent completed and committed 59f7091. PRs #168 and #169 are clean with green CI.
I started a Luna/max agent to add the OpenRouter Decisions API adapter, shared codec, tests, and top PR in stack #170.
The OpenRouter agent confirmed the shared codec approach and explicit configuration. Work continues in the top stacked branch.
I’m waiting for the commit SHA, then I’ll verify it and add the branch as the top PR in stack #170.
The mutation pilot passed on the OpenRouter branch; the only survivor is an unrelated existing baseline. PR #172 is clean with green CI and mutation results.
Try a session of your own.
This recording was added on . It shows a recorded workflow; use the current guides for setup and controls in the published extension.
Start with installation, then open specialists in tmux or Zellij. Try a parallel code review to practice inspecting and following up on separate agents.
To compare other ways of delegating in Pi, read the Pi subagent extension comparison. The parent and child replays provide another view of the session flow.