I’ve written before about how my agent teams coordinate: two primitives and a flat org chart, no spawn trees. That post was about the substrate. This one is about what actually runs on it: the process my features go through, every time, from “I want this” to merged on main.
The process is called RPI: research, plan, implement. The entire thing is five markdown files checked into the repo under .agents/skills: rpi, rpi-fast, feature-supervisor, fast-feature-supervisor, and a compaction-recovery procedure. No orchestration code, no workflow engine, no YAML DAG. A skill in goldengoose is just a folder with a SKILL.md in it, a versioned playbook any agent can be told to follow. That means my engineering process is prose. It’s in source control, and when the process fails I fix it the way you fix a document: I edit it.
The pipeline
When I ask my lead agent for a non-trivial feature and tell it to use rpi, three things happen in order.
A research agent maps the codebase around where the feature will land, covering architecture, data flow, integration boundaries, and risks, and writes a report to a markdown file. The critical detail: it is never told what I actually want to build. The lead deliberately keeps the research prompt architecture-first and spec-light, so the map reflects the codebase as it is, not as someone hoping to build a feature wants it to be. An agent that knows the destination reads the terrain differently, and you can’t un-bias it afterward.
A planning agent gets the opposite treatment: the full feature spec, plus the research report. But before it writes anything, it talks to me: a synthesis of the current state, two or more concrete implementation options grounded in the repo, trade-offs, a recommendation, and whatever decisions it needs from me before locking in. Only after I say go does it produce the implementation plan: state of the current system, state of the ideal system, and phases, each with files-to-read and what-to-do. Notice who it’s talking to. The planner responds to me directly, not through the lead. The one conversation in the whole pipeline where human judgment matters is the one conversation that doesn’t get relayed.
Then a feature supervisor takes the plan into its own branch and worktree and runs the phase loop: spawn one implementer per phase, stand by while it works, review the diff like a senior engineer when it reports done, iterate until the phase is right, commit, remove the implementer, next phase. The lead stays on main doing other work and hears from the supervisor only for real blockers or the final branch handoff.
The fast variant moves review; it doesn’t delete it
rpi is the careful version. rpi-fast exists because sometimes I know what I want, the feature is well-understood, and three agents’ worth of deliberation is ceremony.
The compression is specific. Research and planning collapse into one agent that reads the code and writes the plan immediately: no discussion round, DM the lead and go. The supervisor swaps to fast-feature-supervisor, which skips diff review entirely: it trusts implementer-reported passing checks, commits each phase, and keeps moving.
What it doesn’t do is ship unreviewed code. Review moves from inside the loop to the boundary: after the branch is done, the fast supervisor and its implementers are removed from the team, and a fresh deep-model reviewer inspects the finished branch against the spec and the plan. The reviewer is read-only, so it can’t edit a file or stage a change, but it owns the fix loop: it spawns its own fixer agents on the feature branch, orders findings by severity, reviews the fixes, and repeats until it’s satisfied. Only then does it DM the lead CLEARED, and integration to main proceeds.
That’s the real trade-off between the two skills, and it’s narrower than “fast versus careful.” rpi reviews N times, once per phase, while context is hot. rpi-fast reviews once, at the end, with fresh eyes that never saw the implementation happen. Reviewing at the boundary is cheaper; reviewing in the loop catches drift earlier. I pick per feature.
The detail I like most in the fast supervisor is the rotation rule, because it used to be me. After an implementer finished a phase, I’d eyeball how deep into its context window it was before deciding whether to hand it the next phase or spin up a fresh agent. Under a rough threshold, reuse was strictly better, since it kept everything it learned finishing the last phase; past it, a fresh agent was the safer bet. I made that call by hand often enough that I gave agents the same visibility I had: any agent can check its own context usage, or any teammate’s, in real time. Then I wrote the judgment into the skill: after each phase, check the implementer’s remaining context, and below 65% retire it and spawn a fresh one. Context is the actual consumable resource in agent work, not tokens or time, and the skill treats implementers accordingly, like shift workers who go home before they get sloppy.
Every weird rule is a patch note
Reading these files back, the parts that look strangest are the parts that earn their keep. rpi is at version 1.2.1, and you can read the diffs like patch notes for a management style.
There’s a terminology rule: stage numbers are lead-internal only, and a supervisor must never be told it’s “Stage 3,” because the plan it’s executing has phases, and an agent holding both numbering schemes will eventually conflate the workflow stage it’s in with the plan phase it’s assigning. You don’t write that rule preemptively. You write it after watching the confusion.
There’s a markdown scope rule: research and planning agents may not read any markdown file unless it’s named explicitly, and permission to read one named doc grants nothing about the others. My repos accumulate agent-written reports, old plans, and stale docs, and an agent that wanders into them treats every stale claim as ground truth. The fix isn’t better docs; it’s an allowlist.
And a startling fraction of all five files is instructions to do nothing. Do not poll. Do not ping for status. Do not “check in.” Do not sleep 30 seconds and check status. Do not call the status tool just to see if they’re working. Stand by; the completion message will arrive as a message. Models want to act; it’s what they’re trained to do, and idle waiting is the hardest behavior to get out of them. A human manager who checks in every thirty seconds is annoying. An agent that does it burns its own context window doing so, which loops back into the 65% problem.
Even the handoffs encode a learned rule. The plan gets committed to main before the supervisor’s worktree is created, so the new worktree inherits it automatically. A worktree branched before the plan landed simply doesn’t contain the plan, and a supervisor told to “read the plan” in that worktree finds nothing. The filesystem is the handoff mechanism, as it should be, but only if you sequence the writes.
Recovering from amnesia
The fifth file is a post-compaction procedure, and it deals with the failure mode nobody’s workflow diagrams include: mid-feature, an agent’s context gets compacted and it partially forgets what it was doing. This one also started as me. An implementer deep in a phase would compact, forget parts of the plan, and start drifting; I’d catch it, stop it, tell it to re-read the plan, and let it get back to work. It happened often enough that the catching got automated: supervisors now get notified the moment one of their implementers compacts, and the recovery got written down.
The recovery leans on the one witness that doesn’t forget: git. A compacted supervisor re-reads the plan, then runs git status and git diff and reconstructs where it was from the working tree: which phase, which implementer, whether it was waiting or reviewing. If the tree is dirty because an implementer finished mid-compaction, it stashes the changes to see the world as it existed before the phase, re-reads the relevant code, pops the stash, and resumes the review with its bearings back. A compacted implementer gets simpler treatment: the supervisor re-sends the original assignment and tells it to diff its own work to find out how much of the phase past-them already finished.
That’s the part of the setup I’d defend hardest. Agents fail in ways processes have to absorb; context loss is a when, not an if, and a process that lives in prose can describe its own recovery. Somewhere in there I stopped thinking of these files as prompts. They’re SOPs for employees with excellent skills and unreliable memory, version-controlled next to the code they ship, and edited, like everything else in the repo, whenever production teaches me a new rule.
If you want the files themselves, the rpi and feature-supervisor sources are in the goldengoose skills guide, and the deep delegation guide covers the flat-team mechanics they run on.