The agent team
Fourteen specialists.
One set of rules each.
One agent with a large context window is not an organisation. Capybari separates the work the way a functioning engineering team does: someone plans, someone builds, someone reviews and can say no, someone ships it. Each role has a written contract, and you can edit every one of them.
The org chart
Who is on the team
Two coordinators who plan and sequence, three governance roles who can reject work, and nine workers who build it.
Coordinator
Coordinator
Governance
Governance
Governance
Worker
Worker
Worker
Worker
Worker
Worker
Worker
Worker
Worker
The categories are not decoration. A Governance role can send work back; a Worker role cannot approve its own. Any role at all can be flagged as requiring human review.
One run, six phases
How a specialist works a task
Every specialist follows the same execution cycle, whichever role it holds. You can watch it happen: run streaming shows the commands and the output as they arrive.
Observe
Read the task, the request behind it, the contract for the role, and the state of the repository it has been given.
Analyse
Work out what the change actually requires, which conventions already exist, and what could go wrong if it is done carelessly.
Plan
Decide the smallest safe change and the order to make it in — before touching a file, not while explaining a mess afterwards.
Execute
Do the work on its own branch in its own worktree. Where the right answer is genuinely unclear, stop and ask a human instead of guessing.
Validate
Check the work against what the request asked for. Run what there is to run. Confirm nothing outside the task's remit has moved.
Report
Write the structured report: summary, files modified, risks, assumptions, recommendations and blockers. Then hand the branch to the gates.
The handover
Every task ends the same way
Six headings, in the same order, on every run by every role. Consistency is the entire point — a report you have to decode is a report you stop reading.
- Summary — what changed and why, in language you can forward to someone who was not watching.
- Files Modified — the surface area of the change, so you know where to look before you open the diff.
- Risks — what this could break. Written by the agent that did the work, while it still remembers.
- Assumptions — the calls it made that you might have made differently. This is usually the most valuable heading.
- Recommendations — the follow-up work it noticed and deliberately did not do.
- Blockers — why it could not finish, if it could not finish. Silence is never the answer.
## Summary
Added the 3-D Secure step to the card checkout flow for cards
issued in the EEA. Existing non-EEA payments are untouched.
## Files Modified
- app/payments/checkout.py
- app/payments/sca.py (new)
- templates/checkout/step2.html
- tests/payments/test_sca.py (new)
## Risks
- The challenge redirect adds a third-party hop to the flow.
A slow issuer will look like a slow checkout.
- Webhook retries are idempotent by payment reference only.
## Assumptions
- Cards are treated as EEA by issuer country, not by the
billing address. Confirm this matches your acquirer.
## Recommendations
- Add an alert on challenge-abandonment rate before launch.
## Blockers
- None.
The mechanics
What makes it a team and not a chorus
Four things separate a set of specialists from one agent wearing different hats: written contracts, a rule for absent roles, a common report, and permission to stop.
Role contracts
Every role is a document you can read
A role is not a prompt buried in our source. It is a Markdown contract describing what the role owns, how it should work, what it must never do, and when it has to hand back. Open it. Argue with it. Change it.
- Editable — write your conventions into the Code Reviewer's contract and they are enforced on every task, not on the ones you remember to mention.
- Scoped — a contract says where the role stops. That boundary is why one specialist does not quietly redesign your architecture on a copy change.
- Legible — if you want to know why an agent did something, the answer is in a document rather than in a support ticket.
## Responsibilities
- Verify the change is the smallest one that satisfies the task
- Reject unrelated modifications
- Confirm tests cover the new behaviour
## Limits
- Never implement the fix yourself — return it to the author
Capability substitution
When the role you need isn't on the team
Small teams do not staff all fourteen roles, and they should not have to. Work planned for an absent role is reassigned to a role that can cover the capability — and the substitution is written down.
- Capability, not job title — the plan asks for a capability. A role that holds it takes temporary responsibility for the task.
- Recorded, never silent — you can see that the full stack developer covered the database work, which matters when you read the diff later.
- It stops rather than stretches — if no available role can genuinely cover the capability, the work halts and asks you instead of improvising.
Structured reports
The handover is the product
Specialists do not talk to each other in free text. Work moves between them as a branch plus a report with the same six headings every time, which is what lets a reviewer start reading rather than start interpreting.
- The same shape every time — one format across fourteen roles means you learn to read it once.
- Assumptions in writing — the judgement calls are stated, so disagreeing with one is a conversation rather than an archaeology exercise.
- Blockers are first-class — a task that cannot finish says why. Nothing is more expensive than plausible silence.
Added the 3-D Secure challenge step to the card payment path.
### Files Modified
- app/payments/challenge.py — new challenge handler
- app/payments/gateway.py — route into challenge
- tests/payments/test_challenge.py — 11 cases
### Risks
- Wallet payments untested against the live sandbox
### Recommendations
- Run T-06 before deploying to production
Escalation
It is allowed to stop and ask you
The most useful thing an agent can do with genuine ambiguity is refuse to resolve it alone. A specialist can pause mid-run, put a question to you, and wait — the task holds until you answer.
- A question, not a guess — an agent that invents a business rule at 2am has produced work that looks finished and is not.
- Review gates are the other stop — any role flagged as requiring review halts dependent work until a human approves, at every autonomy level.
- Escalation reaches you — questions and gates arrive at a person even on Autonomous. Autonomy changes the routine, not the exceptions.
Your side of it
How you tune the team
Staff each project separately
A project has its own team. The marketing site and the billing service can be run by different sets of specialists.
Rewrite a contract
Tighten a standard, loosen one, or add the rule your codebase has always had and never written down.
Decide who stops the line
Flag any role as requiring human review. It then holds dependent work until a person approves it.
Choose the model and effort
Override both per project, or for a single request that deserves more thought than the rest of the queue.
Set the autonomy level
Manual, Supervised or Autonomous. How much of the routine runs without you; never how the gates behave.
Watch a run live
Streaming shows the commands a specialist runs and the output it gets back, while it is still running them.
Vocabulary
The words we use, and what they mean
We use the same terms in the product, the docs and here. If one of them means something specific, it is defined below rather than left to context.
Coordinator role
depends_on graph.Governance role
Worker agent
Capability vs role
Temporary responsibility
Review gate
requires_review. Dependent work waits for a human approval, at every autonomy level, with no override for urgency.Escalation
Run
Questions
About the agents themselves
Why fourteen roles instead of one very capable agent?
Because review is only meaningful when the reviewer is not the author. Separating the roles is what allows a Code Reviewer to reject, a Security Engineer to object and a QA Engineer to check the work against the request rather than against the code.
It also means each contract can be narrow, and a narrow contract is easier to read, edit and trust.
Can an agent approve its own work?
No. Worker roles build; Governance roles review. Where you have flagged a role as requiring human review, no agent approval is sufficient at all — dependent work waits for you.
What does an agent see of my codebase?
The repositories connected to the project it is working on, checked out into the worktree for its own task. Not another task's working directory, and not another project's repositories.
Is my code used to train models?
No. Your repositories are cloned to run your work and nothing more. We do not train on your code, your prompts or your reports. The security page sets out where your data lives and who can reach it.
What happens if an agent gets it wrong?
The work is on its own branch, in its own worktree, and has not touched your base branch. Reject it and the branch goes away. If it reached production, the health check catches it, your rollback command runs, and an investigation opens.
Can I add a role of my own?
Custom roles are available on the Pro plan, written as contracts in the same Markdown format as the fourteen that ship with the product. See pricing.
How do I know which specialist did what?
Every task carries its owner, its branch and its completion report, and any capability substitution is recorded against it. The board shows the attribution without you having to reconstruct it from commits.
Want to read a contract before you sign up? Ask us for one.
Meet the team on your own codebase
Connect a repository and file one request. The Project Manager plans it, you read the plan, and nothing else moves until you say so.
No card required · Contracts are editable from day one · Manual autonomy by default