The Factory Team
In OpenRig 0.6.6, factory replaced the product-team topology; the old product-team pages redirect here.
The factory team that ships with OpenRig for sustained product work. Why it's structured the way it is.
The Insight
3 pods, 7 agents. Orchestration (a lead that runs the work and an advisor that helps shape it), Development (a builder, QA and a designer for focused implementation), Review (two independent reviewers on different models). Each pod is a context domain — agents within a pod share memory and communicate freely, while pods communicate through defined edges.
The lead hands work to development. 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 factory team gives you a working foundation to adapt.
When This Applies
Full-stack product development where you want orchestration, implementation, and review as separate concerns. Start it with rig up factory, or ask OpenRig's operator, which recommends a team for your goal. It uses the most concurrent capacity of the built-in teams; for one bounded change, the two-agent starter team is the smaller starting point.
When This Doesn't Apply
Narrow, single-purpose tasks. If you are running one agent to refactor a module, you do not need 7 agents. Start with one agent and grow from there.