Agents & Workflows
Specialized agents with explicit limits
PWR ships a library of agent roles and workflow templates. A role defines what an agent is responsible for, which tools it may use and which actions need approval. A template turns an intent into the right launch. Both are versioned and can be customized per organization.
Platform owners and tech leads who decide what agents are allowed to do and how work gets started.
How it works
Agents & Workflows, step by step
- 01
Pick a role
Create an agent from a role such as Software Engineer, QA or Producer. The role supplies its tool policy and instructions.
- 02
Launch from a template
Templates validate their inputs, check that the project qualifies, and start a conversation, a task, a goal, a coverage run or a sprint execution.
- 03
Grant tools deliberately
Register MCP servers or custom HTTP tools, approve them, and grant them to specific agents. Every call goes through the gateway and is recorded.
- 04
Customize and version
Clone a platform role or template into your organization and edit it. Each edit creates a new version.
- Available
- Implemented and covered by automated tests in the current platform build.
- Beta
- Implemented; verification against the live external service is still pending.
- Upcoming
- Planned or in progress. Not usable yet.
Agent roles
Nine roles ship by default: Producer, QA, Gameplay Engineer, Software Engineer, Game Designer, Technical Artist, DevOps, Security Engineer and Release Manager.
Role library
AvailableEach role defines responsibilities, a tool policy, the kinds of run it may perform, a deliverable shape and its approval gates.
Tool policies
AvailablePlanning and design roles are read-only. Engineering roles get the full sandbox. Release Manager cannot merge or deploy, and no role has a deploy tool.
Agents with model and credential binding
AvailableAn agent binds a role to a model choice, optional planning and review models, limits, and optionally your own provider key.
Versioned customization
AvailableClone a default role into your organization and edit it. Edits are stored as versions and the highest active version applies.
Worker-side deliverable validation
UpcomingStructured output is validated today for plan and review runs. Validation of the other roles' deliverables is not built yet.
Workflow templates
Sixteen templates cover planning, building, testing, sprint work and release preparation.
Template library
AvailableIncludes Build a Feature, Fix a Bug, Refactor a Codebase, Build an API, Generate Unit Tests, Improve Test Coverage, Plan a Sprint, Execute a Sprint and Prepare a Release.
Templates are available to launch. What each one starts carries the status of the underlying workflow, and several depend on beta integrations.
Validated inputs and launch forms
AvailableEach template declares an input schema. The dashboard builds the form from it and invalid inputs are refused before anything is created.
Availability rules
AvailableA template states whether it can run for a project and why not, for example when it needs a connected repository, a game project or an active sprint.
Credit estimates at launch
BetaA launch can return a low and high credit range for the work it is about to start.
Estimates use starting token profiles and catalog prices that have not been tuned against real usage yet.
Prepare a Release
BetaThe Release Manager role builds a readiness checklist from recorded evidence, with release notes and a rollback plan. It never merges, tags or deploys.
Launch path is covered by automated tests; it reads a connected repository, which has only been verified against a simulated GitHub.
Integrations registry and tool gateway
External tools are registered, approved and granted before an agent can call them.
MCP server registration
AvailableDiscover tools from an MCP server. The server identity is pinned at registration and drift is detected.
Custom HTTP tools
AvailableDefine tools that call your own HTTP endpoints, with credentials stored encrypted and never placed in the tool configuration.
Approval, grants and project restrictions
AvailableTools must be approved, granted to a specific agent, and can be restricted to specific projects before the gateway will route a call.
Invocation audit and intent records
AvailableEvery tool call is recorded. Side-effecting calls record intent first, and an uncertain outcome blocks the task until a person reconciles it.
Outbound request protection
AvailableTool endpoints are checked against private and internal addresses at registration and on every connection, with redirect and size limits.
Per-call human approval
UpcomingTools flagged as requiring approval are currently denied by the gateway. Approving an individual call is not built yet.
Questions
How are role limits enforced?
Through mechanisms, not prose. Tool allowlists, the shell setting, the merge gate and commit-bound approvals are enforced by the platform. Other gates are declared in the role and given to the agent as instructions. There is no per-action policy engine yet.
Can an agent deploy to production?
No. There is no deploy capability in the sandbox or in any role's tool policy. The DevOps and Release Manager roles describe deployment steps for people to carry out.
Can I write my own roles and templates?
You can clone the platform defaults into your organization and edit the copy. Each edit is versioned. Publishing new platform-wide defaults is reserved for platform administrators.
What happens if a tool call might have happened twice?
Side-effecting calls are recorded before they are sent. If the outcome is uncertain, for example after a worker crash, the call is not replayed. It is marked uncertain and blocks the task until a person resolves it.
Put an AI development team on your idea.
Describe what you want to build. PWR plans, builds, tests and reviews it, and you approve each step that matters.