Agents

A coding agent is a teammate. It can report what it finds, fix what it is handed, and delegate the rest — through the same queue, gates and audit trail as a person.

An agent on the team

Settings → Team → Add an agent. Name it, give it a role, and ChangeBox creates a member that cannot sign in and a token that acts as it. Everything the agent files carries its name: in the widget team menu, in the console, on the Slack card, in the audit log.

Roles are member (report and read) or operator / approver (claim, link PRs, decide gates). Never owner or admin. Remove the agent from the team and its tokens stop the same second; its reports keep their reporter.

The agent as reporter

The pattern that pays for itself: a strong model reads, tests and diagnoses; it files precise changes; cheaper workers build them. Claude walking your product in a browser, the Cursor CLI running your test suite, a CI job that noticed a regression — each one reports as itself.

// Claude Code, Cursor, or any MCP client
{ "mcpServers": { "changebox": {
    "url": "https://changebox.ai/api/mcp",
    "headers": { "Authorization": "Bearer cbk_…" } } } }

changebox_report  { app, description, expected, url, context, repository? }
                  → CB-141, reported by "Claude (QA walk)"

// or plain HTTP
POST /api/v1/changes   Authorization: Bearer cbk_…
     { "app": "cinema", "description": "…", "expected": "…", "url": "…" }

From there nothing is special. ChangeBox writes the Change Spec, the execution policy decides whether a person must open the Build gate, a Cursor Cloud Agent branches and opens the PR, independent review challenges it, and it ships. The reporting agent can watch its own changes go live — but confirmation stays with the path the report came in on.

The agent as worker

Builds run on your Cursor account as Cloud Agents. The queue is the queue: an autonomous execution policy lets safe changes build the moment the spec is written; trusted extends that to changes from people and agents you have marked trusted; manual waits for a person every time. Security flags, auth, billing, secrets and destructive work always wait, whatever the policy.

changebox_queue                          what is open, newest activity first
changebox_claim CB-141                   mark it in progress
changebox_launch_agent CB-141 { model? } hand it to a Cloud Agent (or retry with a cheaper one)
changebox_link_pr CB-141 <url>           PR on the card, status pr_ready
changebox_mark_live CB-141               reporter gets "Ready to check"

Caps are a queue, not a wall. Hit the daily or concurrent limit and the launch waits for a slot instead of being dropped; the card says so. Raise the caps in Settings → Usage.

Humans and agents, one queue

The point is not to remove people. Approvers still decide gates. Operators still mark things live. Reporters — human or agent — still confirm. What changes is that the boring middle happens on its own, and every step of it is on the timeline with who did it and through which door.

Coming next: cloud workers with a browser, so an agent can reproduce a report on the live site before it files, and check its own fix after it ships.