OpenRig

The Full Product Team

The default rig that ships with OpenRig. Why it's structured the way it is.

The Insight

3 pods, 7 seats. Orchestration (HA pair for continuity), Development (coder + QA + design for focused implementation), Review (adversarial pair for quality). Each pod is a context domain — agents within a pod share memory and communicate freely, while pods communicate through defined edges.

The orchestrator delegates to dev. Dev's output gets reviewed by the review pod. The designer supports implementation; the two reviewers check its output independently. The topology mirrors how a real product team works — specialized groups with clear handoff points.

This is not the only way to structure a rig. It is the starting point. Most teams modify it — dropping the design agent if they are building an API, adding a security pod for sensitive work, splitting the dev pod into frontend and backend. The Product Team topology gives you a working foundation to adapt.

When This Applies

Full-stack product development where you want orchestration, implementation, and review as separate concerns. The default choice when you are not sure what topology to use.

When This Doesn't Apply

Narrow, single-purpose tasks. If you are running one agent to refactor a module, you do not need 7 seats. Start with one agent and grow from there.