Operating the agents
Proofroom is run day to day by six internal agents. The accountable human interacts with them through five surfaces: the company console, the approvals inbox, Telegram, the trigger endpoints, and the playbooks. This page is the operator's manual.
The six agents and what wakes them
| Agent | Wakes on | What it does |
|---|---|---|
| Ops | Every 30 minutes + daily 07:00 UTC + Run now | Health checks, chain spot checks, anomaly flags, daily digest |
| Product | GitHub issue opened + Run now | Triage, spec, Cursor dispatch (approval), PR merge (approval) |
| Support | Inbound email + Run now | Docs-grounded replies, refunds up to £100, flags suspicious messages |
| Growth | Mondays 09:00 UTC + Run now | Drafts one crosswalk page and one social post into the approval queue |
| Security | Mondays 08:00 UTC + Run now | Posture sweep: RLS, key age, queue hygiene; severity-ranked report |
| Finance | Daily 07:30 UTC + Run now | Stripe reconciliation digest |
Surface 1: the control console (/control)
Your cockpit. Per agent: runtime status, today's runs and spend against caps, last digest time, and the controls:
- Run now: dispatches an immediate run
- Pause / Resume: stops new runs without ceremony
- Kill: requires typing the agent's name; revokes its keys, cancels in-flight runs, and is itself receipted on the agent's public chain
Surface 2: the approvals inbox (/approvals)
The source of truth for every tier-2 action. When an agent hits an action it is not allowed to take alone (publishing a page, dispatching a coding task, merging a PR, a refund over £100, activating a playbook), it suspends and queues a request here with a plain-English summary. You approve or reject with one tap; expired requests (48 hours) default to rejected. Every outcome is receipted on the agent's chain.
Surface 3: Telegram
Bind your phone in Settings (one-time code to the Proofroom bot). You then receive approval requests with Approve and Reject buttons, daily digests, posture reports and anomaly alerts. Telegram mirrors the inbox; the inbox remains authoritative.
Surface 4: the trigger endpoints
- GitHub issues webhook -> Product Agent (set the repo webhook to /api/github/webhook with the shared secret)
- Inbound email -> Support Agent (/api/inbound-email via Resend routing)
- Generic webhook -> evidence events from Zapier, n8n or anything that can POST JSON (/api/webhook with an API key)
- Manual run -> POST /api/agents/[id]/run, or the Run now buttons
Surface 5: the playbooks
Each agent's behaviour is its playbook: versioned, hashed and stored in the product. To change how an agent behaves, open the agent's page, propose a new playbook version, and request activation. Activation is a tier-2 approval and lands on the chain as playbook_activated. You never edit behaviour silently.
What you do NOT do
You do not chat with the agents conversationally, and they do not take instructions from inbound content (emails, issues, webhooks are data, never directives). Instruction comes only from playbooks and your approval decisions. That constraint is the security model, and the agents will flag attempts to bypass it as evidence events.