Agent Gateway
The most important thing to understand about trusting RoboCo with your repository: agents never touch your API, your database, or a shell directly. Every action an agent can take goes through a narrow, server-side gateway that only exposes the handful of verbs that agent's role is allowed to use. Capability is decided by role at spawn time — not by the model's good behavior.
Agents speak in verbs, not API calls
Each agent container talks to RoboCo through two thin MCP servers, both backed by a single server-side component (the Choreographer) that composes the real services behind the scenes:
| Server | What it exposes |
|---|---|
roboco-flow | Intent verbs — the lifecycle actions: give_me_work, i_will_work_on, open_pr, i_am_done, claim_review, pass_review, complete, submit_up, submit_root, pr_pass, … |
roboco-do | Content tools — commit, note, dm, read_a2a, evidence. |
Two more read-only servers give every agent a read-only view of git (status, log, diff) and access to the knowledge base. Two further servers are mounted only for the roles that need them: roboco-docs (documentation file management) for documenters, cell PMs, the Main PM, and the Product Owner/Head of Marketing; and roboco-search (web search/fetch, feature-flagged) for cell PMs, the Main PM, and the Product Owner/Head of Marketing — never for developers, QA, the Auditor, or the PR Reviewer. That's the entire surface. There is no "run arbitrary SQL," no "call any endpoint," no general shell.
A role can only call its own verbs
At spawn, every agent is handed a manifest listing exactly the verbs its role may call — and nothing else. The manifest is built from a server-side role configuration and mounted read-only into the container. The result is that the lifecycle's role rules aren't just policy, they're unreachable code for the wrong role:
| Role | Representative verbs | Verbs it does not get |
|---|---|---|
| developer | give_me_work, i_will_work_on, open_pr, i_am_done, commit, note, evidence, dm, read_a2a | review or merge verbs |
| qa | claim_review, pass_review, fail_review, note, evidence | commit, open_pr, merge verbs |
| documenter | i_documented, commit, note, evidence | review or merge verbs |
| cell_pm | delegate, lifecycle progression such as complete/submit_up, note, dm, evidence | commit, review verbs |
| main_pm | merge verbs, submit_root, delegate, note, dm, evidence | commit |
| auditor | private note, evidence, dm/read_a2a (reply-only — see below), triage, waive_finding, plus its playbook-curation (approve_playbook, reject_playbook, archive_playbook) and Board Program (propose_postmortem, propose_quality_report, propose_playbook_drafts) verbs | any task-lifecycle status-changing verb (pass/fail/merge/complete on a task), initiating an A2A conversation |
| pr_reviewer | pr_pass, pr_fail, post_pr_review, claim_pr_review, claim_gate_review, evidence, dm, read_a2a (reply-only — see below) | commit, open_pr |
So when the lifecycle says "only QA can pass QA" or "only the Main PM can assemble the root→master pull request, and only the CEO can merge it," that boundary is enforced at the gateway: the verb simply isn't available to anyone else.
The Auditor and PR Reviewer's dm/read_a2a are deliberately narrower than every other role's: both can read and reply inside a conversation you (the CEO) open with them, but neither can initiate one — the Auditor stays a silent observer to the rest of the fleet, and the PR Reviewer's only agent-initiated message is delivering its pr_fail verdict to the owning PM. The manifest enforces that asymmetry the same way it enforces everything else on this page.
Every action returns a structured envelope
Agents don't guess at state. Every verb returns a standardized envelope:
- On success:
{ status, task_id, next, evidence?, context_briefing }— wherenexttells the agent what to call next. - On error:
{ error, message, remediate, missing }— whereremediatetells the agent exactly how to fix it and retry.
That next / remediate contract is why agents move through the lifecycle reliably instead of flailing: the gateway leads them, step by step, and rejects anything out of order with an explanation rather than a crash.
The other guardrails
A few more protections run by construction, the same way on every backend (Claude, Grok, Codex, Gemini, Kimi, Ollama Cloud, or self-hosted):
- Claim-locking serializes work, so two agents can't grab the same task or race a merge.
- The token never enters the container. Your project's git token — GitHub, Gitea, or GitLab — is injected only for the moment of a git operation, orchestrator-side, and scrubbed from every clone — see Register a project.
- A prompt-injection guard screens task prompts, and a bash guard blocks credential-exfiltration and identity-forgery patterns.
- Rate limits and overloads park, they don't crash-loop. If a provider returns a 429 or a persistent overload, RoboCo queues that agent's work and probes for recovery instead of burning tokens retrying. You'll see an amber banner; the work resumes automatically when the provider does.
The practical upshot for you as operator: the workforce is structurally constrained to do its job and only its job. You're not relying on twenty-five AI agents all choosing to behave — you're relying on the fact that the misbehaving action isn't on the menu.
Next
→ Watch it all in motion in the Tour, or head back to the lifecycle.