The engine was always general
Forge’s software-delivery archetype is the one we have polished most, but the underlying workflow engine was never limited to it. Custom roles are how you reach the rest of the space — research, marketing, ops, support, or any team shape you can describe — using the exact same machinery that ships reviewed PRs.
Roles do not have to be engineering roles
PM, Architect, Developer, QA and DevOps is a recognisable preset, but it is one shape. A role is a written charter plus a handoff convention, so it can be anyone: a lawyer drafting a contract from your templates; an HR screener working through applications; an analyst assembling a report from sources; an estimator checking a costing; an on-call engineer triaging an incident. Same machinery, different roles.
Two ways to define them
- Pattern A — permissive. A lightweight validator, a default
.agents/<role>handoff location, and freeform output. The fastest way to add a role and see it run. - Pattern B — structured registry. A CRUD registry where each role declares its
DownstreamRole, so the engine chains transitions deterministically. Use this when you want typed, repeatable pipelines.
Either way, the workflow generator can map the roles in a plain-English brief onto your registered roles — and offer to generate a character for any role you don’t have yet.
First-class, not bolted on
A custom role isn’t a lesser citizen. It gets the management-agent verdict on every handoff, commits its work to the git audit trail like any other persona, and runs under the same isolation and secrets guarantees. You’re extending the engine, not working around it.