gstack is Garry Tan’s production setup for shipping software with Claude Code and 23 opinionated tools organized into six role-based agents: CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA. It hit #3 on GitHub Trending with 97K stars and represents a real-world orchestration pattern for coordinating multiple specialized agents in a single workflow.
Tan claims an 810× productivity increase (11,417 vs 14 logical lines per day, 2026 vs 2013). The repository’s README.md and docs/ON_THE_LOC_CONTROVERSY.md document the productivity methodology and role structure. The orchestration implementation itself is not published. The repository contains role definitions, tool organization, and MCP protocol integration points, but no orchestration engine code, state management implementation, or deployment configuration.
What the Repository Documents
Examination of README.md reveals:
- 23 tools grouped into 6 role categories (listed in README)
- Role definitions for CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA
- MCP protocol support mentioned for Claude Code integration
- Productivity methodology with detailed LOC controversy documentation in
docs/ON_THE_LOC_CONTROVERSY.md
The repository does not contain:
- Orchestration engine source code
- State persistence implementation
- Tool manifests or configuration files
- Logging or observability infrastructure
- Deployment scripts or infrastructure-as-code
The architecture described below is based on the documented role structure and stated MCP integration, not on inspecting orchestration code.
Architecture: Role-Based Delegation
The README describes six distinct roles, each with a subset of tools:
- CEO: Product strategy, feature prioritization, user research
- Designer: UI/UX decisions, design system enforcement, accessibility checks
- Eng Manager: Architecture decisions, code review, dependency management
- Release Manager: CI/CD, deployment, rollback procedures
- Doc Engineer: Technical writing, API documentation, changelog generation
- QA: Test coverage, regression detection, performance profiling
The documented role boundaries indicate explicit tool separation. The CEO agent does not write code. The QA agent does not make architectural decisions. The Designer agent does not ship releases.
This differs from skill composition patterns where a single agent has access to all 23 tools. Instead, gstack routes tasks to specialized agents based on role.
Undocumented Orchestration Layer
The repository does not publish the orchestration implementation. The handoff mechanism between roles, state persistence, and tool boundary enforcement are not documented in the available files.
Standard patterns for role-based orchestration include explicit handoffs (one role produces artifacts consumed by the next), shared context stores (all roles read and write to a common state layer), or user-directed delegation (the operator selects which role to invoke). Which pattern gstack uses is not documented.
The README mentions MCP protocol support. MCP provides a standard interface for agents to read and write persistent state across sessions, but the repository does not contain MCP server configuration, state schema definitions, or integration code.
Tool Boundaries and State Management
The role structure implies tool whitelisting. The CEO agent cannot call deployment tools. The QA agent cannot call release tools. The Designer agent cannot call CI/CD tools.
How these boundaries are enforced is not documented. Possible approaches include MCP server configuration (each role connects to a different server with a different tool manifest) or prompt engineering (each role’s system prompt forbids certain actions). The repository does not contain evidence of either approach.
Similarly, state persistence mechanisms are not documented. The role structure implies persistent artifacts (project roadmap for CEO, architecture decisions for Eng Manager, design system for Designer), but the storage implementation, schema, and access patterns are not published.
Deployment and Integration
The README indicates gstack runs locally with Claude Code. The integration mechanism, deployment shape, and multi-user collaboration patterns are not documented.
For team use or CI/CD integration, the setup would require adaptation to run MCP servers as cloud services with centralized state storage, but the repository does not provide deployment configuration or infrastructure-as-code.
Trade-Offs
| Dimension | gstack Approach | Trade-Off |
|---|---|---|
| Role boundaries | Explicit separation per role | Prevents role confusion but requires coordination between roles |
| State persistence | MCP protocol integration (documented) | Survives restarts but implementation not published |
| Orchestration | Not documented | Cannot evaluate determinism, latency, or failure handling |
| Tool count | 23 tools across 6 roles | High specialization but coordination complexity |
| Deployment | Local-first with Claude Code | Low latency but team collaboration not documented |
Technical Verdict
Use it if:
- You are a solo builder or small team (2-3 people) shipping multiple services part-time
- You need specialized agents for product, design, engineering, QA, and release with explicit role boundaries
- You can integrate with Claude Code and MCP protocol
- You are comfortable adapting undocumented orchestration patterns to your workflow
- You want to prevent agent overreach by separating tools across roles
Avoid it if:
- You need fully autonomous, end-to-end workflows without human checkpoints between roles
- You require deterministic, auditable orchestration with published state machines or workflow definitions
- You need the orchestration implementation source code for customization or debugging
- You require documented observability, logging, or tracing infrastructure for multi-agent workflows
- Your team has dedicated product, design, and QA staff (human roles may be more efficient than agent roles with manual coordination)
The repository documents the role structure and productivity methodology but not the orchestration implementation. The value is the architectural pattern: role-based delegation with explicit tool boundaries and MCP integration. The pattern is reusable, but operators must implement their own orchestration layer, state management, and observability infrastructure.