Builder

Builder is the agent that works our own codebase — one session per change, usually started from a ticket. Over MCP an assistant can watch it, drive it, and run it, within the same rules the console applies.

Who. Pixelbase staff only; Builder does not exist for any other company. Its three permissions are never granted by hand — everyone here already holds builder:read and builder:write, and builder:engineer follows the engineer marker — so on the consent screen they are simply yours to pass on, one tier at a time. An API client can hold none of them: Builder acts as a person.

Grant	Unlocks
builder:read	list_build_sessions, a session and its transcript through get_api_resource, builder/usage.
builder:write	create_build_session, message_build_session, interrupt_build_session, retry_build_session_start, archive_build_session, set_build_session_auto_mode.
builder:engineer	list_build_deployments, reopen_build_session, delete_build_session; every session rather than your own; turning auto mode on.

What the record rules still decide. A grant opens the tool; the session decides the call. Only the person who started a session may message, stop or restart it (an engineer may on the Self Healer's). Starting one on a ticket takes being its assignee or a manager of its project, on the one project Builder works, and a session with no ticket is an engineer's to start. A refusal names the rule.

Reading status. A session carries progress — the phrase the console shows, agentBusy, and awaitingReply when the next move is a person's — its pullRequests with their state and checks health, and the branch's deployment: Vercel's state, the preview URL and logs, and elapsedMs counting up while it builds. Every read refreshes those on the console's own throttle, so polling a session every few seconds costs no more than the rail does.

Working a session end to end.

1. create_build_session with the brief and a ticketId. It returns at once; the agent starts behind it.
2. Read build-sessions/<id>/messages (last page) until the agent has presented a plan (isPlan) or asked questions.
3. message_build_session to approve, answer or redirect. The reply lands in the transcript a moment later.
4. Watch build-sessions/<id>: status moves to DRAFT when the pull request opens, pullRequests[].health says how its checks are doing, and deployment says whether the preview is up.
5. archive_build_session to put an attempt away; it closes the pull request and keeps the branch, and an engineer can reopen it.

create_build_session and message_build_session spend real Anthropic budget attributed to the session's owner; a 409 says their window or their active-session cap is spent.