Everything a supervised agent team needs
Plan the epic, run the team, keep the checkpoints. PRFactory is the process layer around the AI agents you already use.
◈ Live agent teams
A lead agent spawns a team of child agents in your own harnesses, and the ticket shows the whole team while it works.
- ✓ Lead plus children: the lead decides who to spawn from the phase recipe, and can add agents from a bounded free-room budget
- ✓ Per-agent state: running, waiting, idle and done, each with the profile it was started with
- ✓ Three-axis agent profile: the tool (Codex, Claude Code, Pi, Cursor CLI), the model family and the reasoning effort (low / medium / high / xhigh). A family and an effort, never a dated point release
- ✓ Live output: a one-line tail per agent in the tree, and the full transcript one click away
- ✓ Talk to one agent: send a message to a specific child; delivery is confirmed, not fire-and-forget
- ✓ Survives a reboot: the team is adopted or resumed from persisted state, and the work item is not restarted
▦ Epic planning and decomposition
An approved epic becomes wave-ordered, build-sized slices with proven coverage. One decision round replaces dozens of interruptions.
- ✓ Wave-ordered slices: waves are derived from the dependency edges, so "what can I start now" is a glance, not an analysis
- ✓ AC ownership map: every acceptance criterion owned by exactly one slice, checked in both directions; an unplaced criterion blocks the cut instead of being force-assigned
- ✓ One decision round: open questions are collected, ranked by how many slices they block, and answered once
- ✓ Consequences are shown: answering re-checks every bound slice and lists the documents it invalidates
- ✓ Blocked means blocked: a slice waiting on an open decision is not planned, because a plan written across an open question is a guess
D-7 Should a child agent be allowed to spawn children of its own?
⌁ Bring your own agent
Connect Claude Code, Codex or any MCP client through the built-in MCP server, or let the AgentTeamForge worker run them for you. Both are included in every plan.
- ✓ Works everywhere: Claude Code, Codex and any MCP client
- ✓ Full context: the agent fetches tickets, plans, governance rules and the exact prompt for the next step
- ✓ Moves the workflow: reports progress, attaches artefacts and advances the phase
- ✓ Hybrid or MCP-only: run with the local worker, or MCP-only with no worker at all
- ✓ Scoped access: token-based, scoped to your tenant and repositories
◇ Human checkpoints that hold
Team review, approvals and the audit trail: the part that stops an agent team from being a black box.
- ✓ Multi-reviewer approval: require sign-off from several team members
- ✓ Inline comments: discuss and refine plans before implementation
- ✓ Checklist management: track review progress and requirements
- ✓ Real-time updates: see the team's progress as it happens
Checkpoints in a team run
- Answers approved
- Plan approved
- Test plan: waiting on you; 2 agents parked
- Code review
- Pull request
⌗ Multi-platform
Works with the tools you already use. No vendor lock-in.
- ✓ Git platforms: GitHub, Bitbucket, Azure DevOps
- ✓ Issue tracking: Jira
- ✓ Several repositories per work item: one team can span a primary and secondary repositories
- ✓ Flexible integration: platform-agnostic provider architecture
One work item, several repositories
An agent may be working in a different repository than its siblings; the team panel shows which, and the plan basis is recorded per repository.
⛨ Enterprise security
Your code and credentials stay yours.
- ✓ Multi-tenant isolation: complete separation between organizations
- ✓ Encrypted credentials: all API keys and tokens encrypted at rest
- ✓ Your agents run locally: agents run against a worktree on your machine; PRFactory keeps the workflow artefacts
Isolation, end to end
A tenant sees its own repositories, tickets, teams and transcripts and nothing else. Credentials are encrypted at rest and scoped to the tenant that owns them.
⋔ Your process, as a graph
The seven-phase development flow is one process, not the only one. Define your own — support triage, incident follow-up, whatever your team actually runs — as a workflow graph where each step's outcome picks the path. Graph engineering, without building the runner.
- ✓ A workflow is a JSON document: versioned, exported, handed to someone else and re-imported unchanged. Import is atomic and validated per field, so a bad document creates nothing
- ✓ Per-step agent: every step declares its own backend (Claude Code, Codex, Pi, Cursor CLI), model and reasoning effort — all three required — and the worker claims the step and runs it with that selection
- ✓ Named outcomes route the run: each outcome points at the next step. An output that names no recognised outcome halts the ticket visibly instead of guessing which way to go
- ✓ Checkpoint steps: a step can pause for approve, reject or rerun. Nothing advances past a checkpoint without a person
- ✓ Read-only steps leave no repository trace: they get a working copy to read, and push nothing. No branch exists until the first step that actually writes creates one — progress and artefacts are still recorded on the ticket
- ✓ Escalate into the development flow: an outcome can hand the ticket to the built-in seven phases with everything the run has produced already on it
- ✓ A starter ships: the support-triage process comes with the product and is imported through the same path as your own
One graph, three paths
A triage step classifies an incoming support request as user error, a configuration error or a bug. The first two end read-only, with an answer to send. The bug path drafts a reproducible report and pauses; only a human-approved escalation enters the development flow, and only then does writing begin.
▣ One team, many machines
Install AgentTeamForge on each developer's machine and they become a fleet: visible, scheduled, and safe to hand work between.
- ✓ A fleet you can see: every machine by name, with its online state, last-seen time, the CLI agents it has and the work item it is running right now
- ✓ A ticket stays where it started: the first claim pins the ticket's later phases to that machine, so the worktree, the branch and the previous phase's commits are still there
- ✓ Handover preserves the work: a release pushes the ticket's branch first, and the next machine resumes from it rather than starting again from the default branch
- ✓ Unattended when it has to be: a machine offline past the threshold, or an agent parked on its account's usage limit, produces the same handover with the trigger recorded as the reason
- ✓ Dependencies decide the order: a dependency blocks from the phase that needs it — implementation by default — so a blocked ticket still refines and plans, and becomes claimable when the blocker's pull request is merged
- ✓ Fair share: one person queueing ten tickets does not occupy the whole fleet while a colleague's first ticket waits
- ✓ Owner and machine are different things: a person is accountable for the ticket and answers its checkpoints; a machine executes it. A handover does not change who owns it
Release and adopt
All questions answered, and the implementation phase could just as well run on an idle colleague's machine. Release the ticket with a reason; the branch is pushed before the pin comes off, and the next worker picks the phase up from that branch. Who released it, when and why stays on the ticket.
Put a team of agents on your next epic
Bring the agents you already use. Keep every decision.
Get started free