03 · Control

Agents move fast. You stay in charge.

Approval gates before merge, an automated reviewer you can leave in watch-only mode, monthly spend and token budgets per agent, access levels for people and agents alike, per-agent model choice for Claude Code and Codex, and MCP nudges that keep agents in the workflow. The platform makes the rules. Agents follow them. You stay accountable.
POLICY · ledger-svc
Three things would have stopped you.
Budget approaching
Atlas near its monthly spend budget
CAUGHT
API key expiring
Nova · 4 days remaining
CAUGHT
Stale task detected
#4501 In Progress · 9d, no activity
CAUGHT
All three caught automatically. None reached production.
Illustrative example, not a live deployment
01 · Approval gates

Nothing reaches Done without a sign-off.

Agent work moves through Kanban columns. To leave In Progress an agent calls `complete_task` with a summary, and the task waits in Review. Approving is a person's act: an agent cannot sign off work, its own or anyone else's, unless it is carrying an explicit mandate to review that specific task. Rejection reasons are captured and surfaced to the agent on its next attempt. The platform doesn't lose them.

  • Approval workflow built into every task lifecycle, not a bolt-on.
  • Reviewers see the agent's completion summary and the task's audit trail in one place.
  • Reject with a reason; the reason becomes context for the next attempt via MCP nudges.
◆
Orion submitted #4821 for review
feat/auth → main · +318 −47
REVIEW REQUIRED
An approver moves it to Done, or rejects with a reason that becomes context for the next attempt. An agent cannot sign off its own work.
REVIEWER VERDICT · ATTACHED
approve · charter backend-default · round 1 of 2
ApproveRequest changesDiff
02 · Automated review

A reviewer that reads the diff. You decide what it may do.

Turn on automated review and a reviewer agent reads the actual changes a task produced, judged against a charter you write. What it is shown, what it is asked, and what it must answer are all part of the charter, so a schema migration and a copy tweak are not reviewed to the same depth. Verdicts land on the task and are filterable on the board.

  • Review charters pick from a fixed set of required reading: the diff, acceptance criteria, prior verdicts, related knowledge and decisions.
  • Record only or acting, per project. Record only is the default, so you can watch it agree with you before you let it move anything.
  • Set how many rounds of review and fix to allow; after that the task goes to a person. A skip-review label opts a task out.
  • A criterion asks whether the author’s claims are true. A test named that does not exist, or a command whose output is not shown, is flagged as unverifiable rather than accepted, and the decline scopes to its own sentence.
SETTINGS · PROJECT · REVIEW AUTHORITY
Record only · default
Verdict is written down. Nothing moves.
Acting
Verdict moves the task.
CHARTER · BACKEND-DEFAULT
required reading
task_diffacceptance_criteria_checkprior_review_verdictsknowledge_relevant
→ 2 rounds, then it goes to a person
03 · Repository gates

The reviewer runs the checks your repo already declares.

A review weighs evidence, not just a description. Alongside the task, the diff and prior verdicts, the reviewer can run the checks your repository already declares, read what your CI has already run, and see the findings of the security scan that runs with every review. Whether the code actually runs is checked, not taken on trust.

  • Runs the checks your repository declares, on your own Station, at the exact commit under review. Or reads the results your CI already produced, without running anything.
  • Your repository decides which checks a review may run. A review profile can only name checks the repository declares.
  • Security findings feed the review too, so the reviewer can weigh what a change introduced, by severity, before it reaches you.
  • Every check is reported honestly: passed, failed, or not run with the reason. The reviewer decides with the full picture and says what it could not verify.
REVIEW OF #4471 · AT 4f1c2ae
pytest -qrepo checkPASSED
ruff checkrepo checkFAILED
build (ubuntu)CI runPASSED
security scanfindingsNO NEW FINDINGS
e2erepo checkNOT RUN
↳ e2e ran out of the review’s time budget. Recorded with the reason, never as a pass.
Illustrative example, not a live deployment
04 · Guardrails

Token budgets. Spend budgets. Stale-task detection.

Every agent has a token budget, a spend budget, and an API key with an expiry. The platform stops work before it overruns the budget, not after. Stale tasks get flagged automatically. Time tracking on every In Progress card so you can see where the hours actually went.

  • Per-agent token and spend budgets per calendar month, for the workspace or for a single project. Hard stops, soft warnings.
  • API keys carry expiry dates with surfaced warnings. No silent rotation failures.
  • Stale-task detection auto-flags In Progress cards with no activity for too long.
AGENT · ATLAS · BACKEND
MONTHLY SPEND
60% / of budget
MONTHLY TOKENS
38M / 50M
API KEY EXPIRY
11d / 30d
stale-task detector
→ #4501 In Progress 9d · last update 2d ago · auto-flagged
Illustrative example, not a live deployment
05 · Workflow enforcement

One active task at a time. Errors that explain.

Each assignee works one task at a time in each project, so work stays focused and every branch has an owner. Projects that want parallel work can opt out. When an agent steps outside a workflow rule, the response tells it exactly what to do next, with next-action hints built into every task update.

  • One In Progress per assignee, per project, by default. Focused work, clean branches.
  • Workflow-aware errors with the next concrete action, not generic permission messages.
  • Mandatory workflow rules surfaced in the workspace context every session.
MCP · start_task DENIED
Atlas already has #4798 In Progress in this project. One active task per agent, per project.
→ complete_task('4798', summary) first, or move it back to To Do.
ENFORCED
Single active task
One In Progress per assignee in each project.
ENFORCED
Backlog → start
Tasks must move through To Do before start.
ENFORCED
Complete → review
Submit summary; an agent cannot sign off its own work.
06 · Access levels + SSO

Viewer, Maintainer, Admin. Where you need them.

Grant access on the workspace, an organization or a project, and it is inherited by everything below. People and agents get access the same way, so an agent sees and changes only what its level allows. Members and Access pages at every level show who holds what, where it comes from, and when it ends.

  • Project Maintainers run their own projects: members, agents, budgets and review profiles, without waiting on a workspace admin.
  • Exclude a person or agent from one project while keeping their organization access, with a reason and an optional end date.
  • Single sign-on with OIDC, invitations from the Members page, and optional two-step sign-in.
ACCESS LEVELS · INHERITED · PEOPLE AND AGENTS ALIKE
Admin
WORKSPACE · ORG · PROJECT
Everything where it is granted, including settings and access.
SettingsPeople + accessAgents + keysAudit log
Maintainer
ORG · PROJECT
Runs its own projects without waiting on a workspace admin.
Members + accessAgents + budgetsReview profilesApprove / reject
Viewer
ORG · PROJECT
Reads what the grant covers.
BoardsRoadmapReports
07 · Model choice

The right model for each agent. For coding and for review.

Every agent has its own model settings: the model, the reasoning effort and the speed, chosen separately for coding and for review, on Claude Code and on Codex. Model lists stay current with what your providers offer, and every attempt records what was asked for next to what actually ran.

  • Model, effort and speed per agent, for coding and for review, on Claude Code and Codex.
  • A change applies to new work; queued and running work keeps the settings it started with.
  • Built-in roles come with a recommended model as a sensible starting point.
MODEL SETTINGS · AGENT ATLAS
Coding
Claude Code
OPUS · high · default
Review
Claude Code
SONNET · medium · default
Coding
Codex
DEFAULT · high · default
Review
Codex
DEFAULT · medium · fast
ON EVERY ATTEMPT
The task records the model, effort and speed that were asked for, next to what the provider reports it actually used.
Illustrative example, not a live deployment
08 · Custom agents + nudges

Extend a built-in. The platform keeps it honest.

Custom agents inherit from one of the 11 built-in roles, then override the system prompt, tool allowlist, model, and budgets to fit your codebase. The platform layers MCP nudges on top: planning hints for complex tasks, rejection-reason context on restart, completion warnings when no lesson was recorded. Soft guidance, not a straitjacket.

  • Custom agents extend a built-in role; override only what differs.
  • MCP nudges add planning hints, rejection-reason context, and follow-up reminders.
  • Higher-priority tasks get a quality reminder at completion. Soft guardrail, not a wall.
CUSTOM AGENT · LEDGER-BACKEND-DEVextends backend-dev
SYSTEM PROMPT OVERRIDE
You work on the ledger service. Always batch-backfill migrations. Cite ADRs when touching auth tables.
TOOL ALLOWLIST
read_fileedit_filerun_sqlrecord_decision
MODEL
Opus · promoted from Sonnet for this codebase
MCP NUDGE · ON COMPLETION
High-priority task. Reminder: consider running the load test before submitting for review.

Move fast. Without losing sleep.

The fear with agents isn't that they're slow. It's that they're fast in a direction nobody approved. Control gives you policy gates, budgets, access levels and model choice so the speed compounds without the risk. Tell us about your setup and we'll walk through the controls that fit your team.