Concepts
Agents
Each agent does one job and sees only what that job needs. The agent that wrote the code never verifies it, and none of them reaches your spec, GitHub or production except through the Babbit MCP.
The agents
A project ships with four agents. Each one starts because something happened, never on a schedule.
| Agent | Starts when | Sees your sentence | Does |
|---|---|---|---|
| Product | You describe a change, add a feature, or someone pushes code Babbit didn't make. | Yes | Turns your sentence into a brief and proposed spec lines. Reads drift. Reads a connected repository at onboarding. |
| Code Writing | You approve a spec change. | No | Writes the code and a test for each scenario in an isolated workspace, then hands off. |
| Verify | Code Writing reports done. | No | Captures the app before and after the change, as screenshots and video. |
| QA | Main moves, if you turn it on. | No | Explores the running app like a careful tester and opens a change for each real finding. |
Product
The Product agent is the only agent that reads your words. It expands the sentence into a brief, reads the spec and the code, and proposes exact edits: each one names the goal or scenario it changes and shows the value before and after. It runs nothing and changes no code.
The Product agent also does two other reads:
- Onboarding. When you connect a repository, it investigates the code read-only and drafts the feature tree and an architecture map, citing the source lines behind each claim.
- Drift. When someone pushes to main without a change, it classifies the push and proposes the spec edits that make the spec true again.
When you reject a line or click Request changes, it also asks what rule in agents.md would have saved the round trip, and proposes that rule as a Manage change.
Code Writing
The Code Writing agent starts only from an approved spec. It never sees the sentence that started the change, so how a request was phrased can't steer the code. It works through the approved lines, writes a test for each scenario it adds or edits, keeps the map current, and hands off through the Babbit MCP.
For long code with nothing left to decide, such as tests generated from named scenarios or the same edit across many files, it can hand the writing to a fast one-shot model and review the result.
Verify
Babbit runs the tests itself, at each pull request head, so no agent can pick which tests count. The Verify agent's job is what tests can't show: it opens the running app at the version before the change and the version after, plans which screens each visible scenario touches, and records captures for your review on the Proof tab.
QA
QA is off by default. When you turn it on, it explores the running app each time main moves, once the new snapshot is built, in its own workspace, and opens one change per finding: a sentence a person can act on, the steps that reproduce it, what the spec expected and what the app did, with up to four captures. Each finding is a change you review like any other. To turn it on, see Tune your agents.
Where agents run
Every step that runs your code works in a workspace: an isolated copy of your repositories on a machine Babbit runs for your project. A workspace has its own user, its own throwaway database and one way out to the internet, through Babbit's egress proxy.
- Workspaces start from your project's base snapshot, which is rebuilt when main moves, so a session never starts with an install.
- A workspace holds no Git credential. Code leaves it as a diff that Babbit commits to a
change/branch. - A workspace holds no secret values, only handles. See Give your code secrets and connect services.
- A workspace that waits for you is stopped, and restarts when you answer.
Which model runs each agent
Agents run in a harness, Claude Code or Codex, on the agent account you connected. Babbit picks a model and effort for each kind of work unless you choose them in Models & providers. The rows and Babbit's automatic choices are in Choose models and effort.
Limits on every session
Each agent has a stop rule with two limits: at the first, the session pauses and asks you; at the second, Babbit stops it. Babbit enforces both from outside the workspace, on its own count, never on the agent's word. Sessions are also bounded by time and by inactivity, so a session that hangs without calling a model is still stopped.
The two small models behind the screens
Behind most of what Babbit pre-fills, ranks or rewrites sit two small models, separate from your agents:
- Qwen writes words: a brief, a draft scenario, a summary at a reading level.
- Jev judges between candidates and returns a probability: where a feature goes, which default fits, whether a draft belongs.
Anything a model decided carries a provenance chip: where it came from and how sure Babbit was, with the reason on hover. A screen that used a model says which one answered and how long it took.
Related
- Tune your agents: rules, settings, sessions and skills.
- Babbit MCP tools: every tool, and which agents may call it.