Agents
Coding agents ship changes faster than anyone can eyeball. This example gives a swarm of them a safety net: every agent tests its own work against your baselines, the clean changes push straight through, and anything that regresses lands in your review queue — not on main.
Below, four agents — Claude Code, Cursor, Codex, and Gemini CLI — build a VitePress docs site on the same branch at once. Three edits pass. One quietly drops the hero's colour below AA contrast; Dungbeetle catches it and parks it for review. Nothing here is staged — the edits were made by a real model and the preview is a real render of the site after each one.
You own the account. Agents get scoped tokens.
The rule that makes this safe: a human always owns the account and the data. An agent never sees your password. It gets a scoped, revocable token (a dbat_…) bound to one repository — you approve it in the browser and can revoke it any time from the dashboard. Promoting a new baseline is a human decision.
Prerequisites
- Node.js 22 or newer (
node --version). - A repository with Dungbeetle baselines. If you don't have one yet, follow the VitePress example first — it takes about five minutes.
- A Dungbeetle account on the cloud server (the free tier is enough).
1. Capture baselines you trust
Baselines are the contract the swarm is held to, so a human sets them first:
npm i -g dungbeetle
dungbeetle init # scaffold dungbeetle.config.json, add your capture targets
dungbeetle update # capture those targets and save them as baselines
dungbeetle test # sanity check — everything passes2. Connect an agent
From the agent's shell, start the device-authorization flow. It prints a one-time code and waits while you approve it in the browser:
dungbeetle loginVisit https://dungbeetle.dev/ui/connect and enter code: BEETLE-7Q4X
Waiting for approval… ✓ approved
Saved a scoped token for acme/docs (runs:write, baselines:read, reviews:write).The token is stored under $XDG_CONFIG_HOME/dungbeetle/credentials.json (mode 0600). It's scoped to a single repository and can't change your account or promote baselines on its own. See Agent authentication for the full scope list and the device-flow details.
3. The agent's loop
Now the agent works exactly like you would — it just runs against a token you granted:
dungbeetle test # compare its changes against your baselines
dungbeetle push # upload the run; passes are green, diffs wait for review- Passes push straight through — the branch stays green.
- Diffs are uploaded but not promoted. They land in the review UI with a semantic diff and a before/after screenshot, attributed to the agent that produced them.
In the demo, Cursor's "make the brand lighter" edit is a real regression:
4. You review
The regression waits in your queue. You approve (which promotes the new baseline) or request changes (which sends the agent back to fix it). In the demo you request changes; Cursor reverts the colour and its next test passes — and only then does the branch go green again.
This is the whole point: the swarm moves fast, and the one decision that changes what "correct" means — promoting a baseline — stays with you.
5. Wire it into your agent tool
Your agent doesn't need to shell out to the CLI — Dungbeetle ships an MCP server so the agent can capture, test, push, and read runs as tools, on the same scoped token. Setup guides per tool:
See the MCP overview for the tool list and the agent loop, and Agent authentication for how tokens and scopes work.
Next steps
- Give each agent its own token so runs are attributed per agent, and revoke any one of them instantly from the dashboard.
- Read more on the trust model in Security.
- Push runs to the cloud server to review diffs in a browser without committing baselines to your repo.