docs: Babysitter: The Repo That Makes AI Agents Prove They’re Done
Versioned workflows, quality gates, and deterministic loops turn AI coding from a conversation into a controlled system.
- Babysitter’s central bet is that AI work should be versioned and verified like software, not judged by an agent’s self-reported confidence.
- The repository is the operating surface, because workflows, gates, and instructions live in Git and inherit Git’s audit trail.
- Quality convergence turns completion into a process with checkpoints, retries, and resume points instead of a one-shot prompt.
- The docs repo matters because it dogfoods the same agent-native control model it explains.
Done Means Done
Babysitter starts from a blunt premise: a model saying it is finished is not the same as work being finished. The system is built to distrust confidence and trust only gates, checkpoints, and replayable state. That shift is the whole story.
That matters because most AI coding still behaves like a conversation. You ask, it answers, and you decide whether to believe it. Babysitter pushes the problem into a different frame: define the workflow, run it, inspect it, repeat it until the output is good enough to pass.
Babysitter is an orchestration framework for Claude Code that enables deterministic, event-sourced workflow management with quality gates, human approval checkpoints, and automatic iteration until quality targets are met.
Why a Repo Becomes the Control Plane
The docs repository is not just describing Babysitter. It is part of the operating model. In the repo, configuration, workflow logic, and documentation all live in the same Git lifecycle as code, which means agent behavior can be reviewed, versioned, and rolled forward like anything else.
.a5c/
config.yml
.github/
workflows/
a5c.yml
docs/
architecture.md
specs.md
start_here.md
articles/That structure is the tell. A5C does not hide the control layer inside a chat UI. It exposes it in files, events, and workflows. The repo becomes the place where instruction, routing, and execution policy are maintained together.
The practical win is simple: if an agent rule changes, it changes through a commit. That makes the system inspectable by default.
The Loop That Makes It Deterministic
Babysitter’s technical shape is a loop, not a prompt. A task enters a defined workflow, quality gates evaluate the output, execution can repeat, and the journal preserves state so the run can be resumed instead of restarted.
The important word is not automation. It is convergence. Babysitter is trying to make agent work behave more like managed software, where a run advances through explicit states and completion is something you can prove, not merely claim.
The Docs Repo Is Dogfooding the Platform
This is where the project gets self-referential in a useful way. The documentation repo behaves like a live example of the product philosophy: agents, workflows, and specs are treated as first-class artifacts, not as comments on top of the system.
That makes the docs valuable beyond explanation. They show the same agent-native posture the platform wants to impose on the codebase itself. The result is less like a handbook and more like a working model of how the system is supposed to be governed.
It also explains the naming. Babysitter is not claiming the human is absent. It is claiming the human is supervising a process that can stop, resume, and ask for approval at meaningful boundaries.
What Babysitter Is Not
Babysitter is not a prompt library. It is not a chat wrapper. It is not just a methodology document with better branding. Those categories are too shallow for what it is trying to do.
| Pattern | Control surface | Source of truth | Completion model | Replayability |
|---|---|---|---|---|
| Chat-first agent | Conversation window | Prompt history | Model says it is done | Low |
| AGENTS-style instructions | Repo text file | Local instructions | Agent follows guidance | Low to medium |
| Method frameworks | Process docs | Playbook or playbook plus tools | Human interprets progress | Medium |
| Babysitter | Git repository plus workflow files | Versioned workflow state | Verified by gates and iteration | High |
The sharper boundary is this: Babysitter sits between workflow engine, policy layer, and agent runtime. It is not merely telling an agent what to do. It is managing how work moves, when it pauses, and what counts as finished.
The Competitive Shape of the Category
The cleanest comparison is not feature parity. It is control philosophy. Chat-first tools optimize for interactive use. Repo instruction standards optimize for shared conventions. Method frameworks optimize for repeatable process. Babysitter optimizes for deterministic execution and auditability.
| Category | Best at | Weak spot | Where Babysitter differs |
|---|---|---|---|
| Chat-first agents | Fast ideation and ad hoc help | State loss and overconfident completion | Babysitter makes state durable and gated |
| Repo instruction files | Shared guidance in the repo | No execution engine | Babysitter executes and re-checks the workflow |
| Method frameworks | Team process and sequencing | Manual interpretation | Babysitter encodes the loop in the system |
| Generic CI | Testing and automation | Not designed for agent reasoning loops | Babysitter treats agent work as a recoverable process |
That is why the project feels like a category bet. It is not asking whether agents should exist. It is asking where the work should live. Its answer is the repository, with every meaningful step written down, replayable, and open to inspection.
