Why roles beat one large agent
Human teams separate planning, implementation, testing and review for good reasons. Each needs a different focus, and separation creates checks. The planner does not grade its own plan. The author does not approve their own change.
The same holds for agents. A role fixes three things: what the agent is responsible for, which tools it may use, and what its output must look like. A planner that cannot write files cannot wander into implementation. A reviewer with read-only tools cannot quietly fix what it was asked to judge.
Roles also make cost manageable. Planning and review benefit from stronger models and more context. Routine implementation and chat often do not. Matching the model to the role is cheaper than running everything on the most expensive option.
Handoffs are where teams succeed or fail
A handoff between agents should be a structured artifact, not a conversation. A plan is a list of tasks with acceptance criteria and dependencies. An implementation is a branch, a diff and a validation result. A review is a verdict with findings on a specific commit.
Structured handoffs can be validated. A malformed plan is rejected before it becomes work. A review that cannot be parsed does not count as approval. This is what stops errors from compounding as work moves down the line.
- Plan: tasks, acceptance criteria, dependencies, risks, open questions
- Implementation: branch, diff, validation output, summary
- Review: structured verdict and findings bound to a commit
- Release readiness: checklist with evidence per item
Where people stay in the loop
A team of agents still needs a manager, and that is a person. The points that matter are few: approving a plan before it becomes tasks, approving which tickets agents may take, approving each pull request, and deciding to release.
These gates should be structural. An approval that an agent could skip is not a gate. Approvals should attach to specific artifacts, such as a commit, and expire when the artifact changes.
Budgets are the other control. An agent team can spend quickly. Per-run cost caps, a budget per goal or sprint and an organization limit keep a mistake bounded.
How PWR organizes an agent team
PWR ships nine roles: Producer, QA, Gameplay Engineer, Software Engineer, Game Designer, Technical Artist, DevOps, Security Engineer and Release Manager. Each has a tool policy, a deliverable shape and declared approval gates. Producer and Game Designer are read-only. Release Manager cannot merge or deploy. No role has a deployment tool.
Workflow templates start the right role for an intent. A goal chains them: the Producer plans, you approve, engineers implement task by task, a reviewer checks each pull request and you approve each merge. PWR Sprint puts the same flow on a board with sprint budgets.
PWR Auto routes each run to a third-party model based on its purpose, your policy and expected cost. PWR does not train its own foundation model. The limits are stated plainly. Tool policies, the merge gate and commit-bound approvals are enforced by the platform. Other role gates are instructions to the agent, since there is no per-action policy engine yet. The full workflow is verified against a simulated GitHub and is in beta until it has been run against live GitHub.