Orchestrating AI Agents: pstack vs. the Claudio Workflow, Two Roads to the Same Discipline

As AI coding agents become the standard for software development, the industry is scrambling to figure out how to manage them. Left to their own devices, LLMs write "slop code," hallucinate APIs, and skip edge cases.

To solve this, heavy orchestration frameworks like pstack have emerged. But do you really need to install a rigid framework of dozens of skills, playbooks, and principles to get good results? In this post, I'll break down the exact mechanics of pstack, then introduce my own opinionated pipeline (the "Claudio Workflow" powered by SCOPE), not as a universal replacement, but as a worked example of why building a lighter, custom orchestration layer can get you the same rigor.

What is pstack? A Deep Dive

Created by Lauren Tan (@poteto), pstack ships officially as a Cursor plugin, but its skills are plain SKILL.md files, the same format Claude Code, Codex, and other coding agents already load. Cursor remains the intended home (it's the one place that can assign a different model to each subagent out of the box), but unofficial community ports like pstack-claude translate the Cursor-specific pieces to Claude Code and Codex equivalents. [6] The framework itself is designed to force agents to write less code, but of much higher quality.

It is structured as a three-layer architecture, backed by 23 workflow skills, 2 specialized subagents, helper programs, and an optional automation pack ("Benny") on top:

1. The Router: A single workflow command (/poteto-mode). [2][3]
2. The Playbooks: 22 specific task recipes (Feature, Bug Fix, Refactor, Perf, etc.). [3][4]
3. The Principles: 21 single-rule leaf skills that ground the agent's behavior. [2]

Key Features & Mechanics of pstack [5][6]

• The /poteto-mode Router: You don't micromanage the agent. [2] You give it a goal, and /poteto-mode analyzes the request, selects one of the 22 playbooks, and copies the playbook's steps verbatim into the agent's to-do list. [3] The agent cannot silently drop steps: when it skips one, the task list keeps the step and records why.
• Pre-Code Investigation Skills: Before writing code, pstack forces the agent to use /how, /why, /teach, and /recall to trace system history and understand existing architecture.
• Design & Review Skills: /architect grounds a design in caller usage first (types and signatures follow from how callers actually use the thing) before it lets implementation start, and scraps the sketch if implementation friction proves it wrong. /arena runs the same task across several models in isolated worktrees, then has a separate judge model pick a base and fold in the strongest ideas from the rest (distinct from /swarm, which splits one task into independent slices for coverage rather than comparing competing answers). /interrogate (or thermo-nuclear-code-quality-review) sends a diff to several models for harsh review, and deliberately keeps a "dismissed" bucket visible so you can override the lead reviewer's filtering.
• Anti-Slop Principles: It enforces 21 micro-principles like the Laziness Protocol (prefer deletion/smallest change) and Subtract Before You Add (remove dead paths before introducing new designs). It even includes an /unslop (or /deslop) command to clean "AI tells" out of diffs before committing.
• Rigorous, Repo-Specific Verification: pstack explicitly rejects "the tests passed" as proof. It demands runtime evidence: if it's a CLI change, it runs the command; if it's a UI change, it walks the DOM. /create-verification-skill goes a step further and generates a project-local verify-<app> skill with exact instructions to launch, drive, and evidence the app, turning "verify it" into a standing repo capability instead of a one-off conversation.
• The Babysit Playbook: A dedicated loop that wraps GitHub CLI (gh pr view, gh pr checks) to automatically fix CI failures, resolve merge conflicts, and drive a PR to completion.
• Subagents: It ships with specialized subagents like poteto-agent (for end-to-end execution) and Comment Sicko (a read-only reviewer). [7]

The "Claudio Workflow": Author's AI Pipeline

Instead of adopting pstack's heavy, 22-playbook system, I built a custom multi-agent pipeline. Let's call it the Claudio Workflow. It achieves the same rigor using two core pillars: the SCOPE framework and a strict large brain, small brains delegation loop: one large-reasoning model always owns management, and one or more smaller, faster models always own execution.

1. The Ground Truth: SCOPE Specs

Traditional PRDs fail with AI. Instead, every feature starts with a SCOPE file, structured around how LLMs actually process information:

• S - Situation (Why): Injects business context so the LLM optimizes for the real problem.
• C - Constraints (No-Gos): Negative prompting. Explicit rules the AI must not break (e.g., PCI compliance, no new abstractions).
• O - Outcome (Acceptance Criteria): BDD-native Given/When/Then statements that translate directly into a TDD test suite.
• P - Patterns (Tech Context): The anti-hallucination layer. Explicitly points the AI to existing components, DB schemas, and data contracts to force code reuse.
• E - Edge Cases: Forces the AI to handle race conditions and fallbacks, preventing it from only writing the "happy path."

2. The Execution Loop

1. Planning & Delegation: I pass the SCOPE file to the large brain, usually Claude Opus 5 (acting as Staff Engineer). It reviews the requirements, creates an implementation plan, and uses the /goal command to maintain autonomy.
2. Execution: The large brain passes the granular work down to a small brain. Which one depends on the job, often Claude Sonnet 5, but also Codex or OpenCode models routed through OpenRouter, which executes the code based strictly on the SCOPE Patterns (P). The manager is always the larger-reasoning model; the executor is always the smaller, faster one, whichever vendor it comes from.
3. The PR Review Loop: The small brain finishes, tests are run, and a PR is opened. An external AI agent leaves review comments.
4. Iterative Refinement: The large brain steps back in, reads the review comments, and iterates on the code up to 7 times until the reviewer is completely satisfied.

How pstack and the Claudio Workflow Overlap

While pstack uses a massive library of commands and scripts, the Claudio Workflow achieves the exact same engineering rigor through prompt architecture and model delegation. Here is how they map to each other:

1. Context & Investigation (/how, /why vs. SCOPE 'S' & 'P')
   • pstack: Uses commands to force the AI to read the repo and understand the why before coding.
   • Claudio: Front-loads this via the Situation (S) and Patterns (P) sections of the SCOPE file. The AI doesn't need to guess or search for context; the institutional knowledge is injected directly into its context window.
2. Anti-Slop & Guardrails (Principles vs. SCOPE 'C')
   • pstack: Relies on 21 principles (like Laziness Protocol) to prevent bloated code.
   • Claudio: Uses the Constraints (C) section of SCOPE. By defining strict "No-Gos" upfront, it acts as a negative prompt that bounds the AI's behavior just as effectively as pstack's principles.
3. Model Routing & Subagents (poteto-agent vs. Large Brain/Small Brain)
   • pstack: Uses /setup-pstack to route complex judgment to models like Opus, and fast mechanical code to models like Sonnet or Grok.
   • Claudio: Natively does this by explicitly using a large-reasoning model (Opus 5) as the planner/reviewer and delegating execution to whichever small brain fits the job: Sonnet 5, Codex, or an OpenCode model via OpenRouter.
4. Verification & CI Management (Babysit vs. The PR Loop)
   • pstack: Uses the Babysit playbook to read GitHub PR checks and loop until CI passes. [6]
   • Claudio: Uses the iterative 7-step PR review loop where the large brain ingests review comments from an external AI agent and refines the code until it meets the standard.
5. Autonomy (/poteto-mode vs. /goal)
   • pstack: Uses verbatim task lists and autonomous loops to keep the agent on track.
   • Claudio: Uses the /goal command to keep Opus focused autonomously on the SCOPE Outcomes (O).
6. Design Exploration (/architect//arena vs. SCOPE 'P')
   • pstack: Runs /architect to sketch a design from caller usage before implementing, and /arena to race several models on the same brief and merge the strongest ideas.
   • Claudio: Skips the design-exploration step entirely: the Patterns (P) section of SCOPE points the large brain at existing components and contracts up front, so there's rarely a live design decision left to arbitrate between models.

Where This Leaves You

pstack is a brilliant, highly-engineered framework for developers who want a plug-and-play system to discipline their AI agents. It provides a massive safety net of playbooks, principles, and verification checks.

That said, the Claudio Workflow described here is my own opinionated setup, not a drop-in standard. If you're already writing rigorous SCOPE files and orchestrating a strict large-brain-to-small-brain pipeline, installing pstack on top will likely add unnecessary bloat. Your SCOPE files already handle the context injection and constraints, and your large brain's PR loop already handles the verification. You don't need 22 playbooks when you have a well-defined spec and a delegation hierarchy that works for you.