Babysitter: Deterministic Workflow Enforcement for AI Coding Harnesses
Babysitter enforces obedience on agentic workforces and enables them to manage extremely complex tasks and workflows through deterministic, hallucination-free self-orchestration
At a glance
- What is it?
- Babysitter is an MIT-licensed JavaScript tool that turns agentic coding sessions into step-gated, journaled workflows across 12 harnesses. The idea is sound, the install matrix is wide, and the version history suggests the API is still moving.
- Who is it for?
- Adopt Babysitter if you are already running Claude Code or Codex and you need a written, replayable record of what an agent did and which gate let it continue. Skip it if your work is exploratory prompting or if you cannot accept Node 22.13.0 as a floor for the host-side adapters CLI.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 10 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The failure Babysitter targets: agents that skip the process
Most agentic coding tools accept a prompt and then do whatever the model decides. The README frames Babysitter against that default: it "enforces obedience on agentic workforces," and the operative phrase is enforcement rather than suggestion. The claim is that a workflow defined in code is executed step by step, that quality gates must pass before the run advances, that human approval is required at designated breakpoints, and that every decision lands in an immutable journal. The audience is narrow and identifiable: teams that already run agents inside a coding harness and have hit the point where a plausible-sounding agent output is not the same as a completed process. If your work is conversational exploration, Babysitter solves a problem you do not have. If your work is a multi-step migration, a release checklist, or anything where a skipped step costs money, the enforcement model is the point.
Adapters, the unified plugin source, and how a run is actually wired
The architecture splits into a host side and an in-session side, and the README is explicit that these "should not be conflated." The host side is the adapters runtime, shipped as `@a5c-ai/adapters-cli`, which runs a harness directly from your shell. The in-session side is a per-harness plugin that drives full orchestration runs from inside the harness itself. As of v6 the project describes itself as harness-agnostic through that Adapters runtime, so the same processes are meant to run across the 12 supported harnesses rather than being rewritten per tool. The package layout matters when you are debugging: `@a5c-ai/babysitter` is the end-user CLI, `@a5c-ai/babysitter-sdk` is the library and the implementation behind the core CLI, `@a5c-ai/genty-platform` carries runtime commands such as `genty call`, `resume`, `start-server` and `tui`, and harness plugins like `@a5c-ai/babysitter-codex` or `@a5c-ai/babysitter-cursor` integrate a specific host without replacing the core packages. In the repository, `plugins/babysitter-unified` is described as the only maintained plugin source, with harness-specific bundles generated at build and release time rather than committed. That is a reasonable build choice, but it means the code you read on GitHub for a given harness may not be the code that ships.
Installing it: two tracks, two Node floors, one marketplace name trap
The main CLI installs globally with `npm install -g @a5c-ai/babysitter`. The host-side track is `npm install -g @a5c-ai/adapters-cli`, followed by `adapters doctor` to check the environment and `adapters run claude "explain this codebase"` to execute a harness from the shell. Watch the version floors, because they differ. The project requires Node 20.0.0 or later, with 22.x LTS recommended, but the adapters CLI pins a higher floor of 22.13.0 or later. The stated reason is concrete: it loads the gateway's built-in `node:sqlite`, which is unflagged only from Node 22.13.0. If your build image is on Node 20, the main CLI may install while the host-side CLI does not, and that is a runtime failure rather than an install-time warning. Per-harness installs vary. Claude Code uses a native marketplace: `claude plugin marketplace add a5c-ai/babysitter-claude` then `claude plugin install --scope user babysitter@a5c.ai`, followed by a restart and a `/skills` check for "babysit." Codex CLI is marked Beta and uses `codex plugin marketplace add a5c-ai/babysitter-codex` and `codex plugin add babysitter --marketplace babysitter`. The README flags a genuine trap here: `--marketplace babysitter` is the marketplace name declared in the repo's `.agents/plugins/marketplace.json`, not the repository name. Cursor and Gemini CLI are marked Experimental and install through `babysitter harness:install-plugin cursor` and `babysitter harness:install-plugin gemini-cli`. Claude Cowork has a GUI path through Customize, Browse plugins, Personal, then Add marketplace from GitHub. For Team and Enterprise org-managed installs the README notes that GitHub-synced organization marketplaces require a private or internal repository, so that flow needs a private fork or a manual ZIP upload.
The harness matrix is wide, and the maturity labels are uneven
Twelve harnesses are listed, but the README does not present them as equals. Claude Code and Codex have dedicated documentation pages and are described as the two fully-worked harnesses. Codex is labelled Beta. Cursor and Gemini CLI and GitHub Copilot are labelled Experimental. That distribution is the most useful signal in the document, and it is worth reading as a statement about where the maintainers' testing effort goes. If you are on Claude Code, you are on the path with the most documentation. If you are on one of the experimental harnesses, the integration exists but the README does not claim it has been hardened. The harness-agnostic claim is about the process definition, not about equal support across every host. Nothing in the supplied material states how many people use the project or how widely each harness path is exercised, and the download badge in the README is not evidence of per-harness reliability.
Where the enforcement model gets in the way
Enforcement is a constraint, and constraints cost something. A run that must pass a quality gate before advancing, and that must stop for human approval at breakpoints, cannot be left unattended in the way a plain agent session can. The journal is described as immutable, which is the right property for an audit trail and the wrong property if you need to correct a bad step in place. The design also assumes you can express your process as a workflow in code before the run starts, which puts the modelling cost up front. There is a second, more mundane limitation visible in the release history: v0.0.188 landed in June 2026, and v0.0.187 and v0.0.186 both landed on the same day in April 2026. A version line that is still in the 0.0.x range, with patch releases arriving in pairs, is a project whose interfaces are still settling. The README also refers to "As of v6" for the adapters runtime while the npm releases are numbered 0.0.x, and the two numbering schemes are not reconciled in the material provided. Treat any workflow you write as something that may need edits on upgrade. Beyond that, the README does not document failure behaviour for a gate that cannot be satisfied, and I cannot confirm from the supplied material what happens to a run that stalls at a breakpoint indefinitely.
How this differs from a plain agent session or a CI pipeline
The obvious alternative is the thing Babysitter wraps: an ordinary session in Claude Code or Codex, with the process living in your head or in a prompt. That approach has no install cost, no Node floor, and no plugin to keep in sync with a harness update. What it lacks is the journal and the gate, which is exactly the gap Babysitter is built to close. The second alternative is a conventional CI pipeline, and the difference in approach is sharper than it first looks. CI enforces steps that are deterministic by construction: a shell command either exits zero or it does not. Babysitter is enforcing steps whose output is generated by a language model, so the gate has to judge something fuzzier than an exit code, and the journal has to record a decision rather than a return value. That is why the project's own framing leans on the word deterministic. Whether the enforcement is as deterministic as the CI comparison implies is something the README asserts rather than demonstrates, and the supplied material contains no worked example of a gate failing and a run halting as a result.
Maintenance cost, licence, and what to check before you commit
The licence is MIT, which permits commercial use and modification and requires that the copyright notice and permission notice be preserved. That is a permissive arrangement, and it is the same licence used by most of the tooling this project sits alongside. It says nothing about whether the project will be maintained, and it is not legal advice; if you are redistributing a modified build, have someone qualified read the actual LICENSE file rather than a badge. The maintenance cost that matters here is version churn plus harness churn. Babysitter sits on top of 12 external harnesses, each of which changes on its own schedule, so the integration surface is larger than the project's own code. The README's own instruction to restart Claude Code and check `/skills` for "babysit" is a small reminder that plugin state can go stale in ways a package manager will not catch. Budget for re-running `adapters doctor` after harness upgrades and for re-validating workflow definitions after Babysitter minor bumps. The concrete things to verify first are these: run `adapters doctor` on the Node version you actually deploy, confirm your harness is in the install matrix and note whether it is labelled Beta or Experimental, and check which scope your plugin landed in, since `--scope user` is not the same as an org-managed install and the org path has its own repository visibility requirement.
Editorial conclusion
Adopt Babysitter if you are already running Claude Code or Codex and you need a written, replayable record of what an agent did and which gate let it continue. Skip it if your work is exploratory prompting or if you cannot accept Node 22.13.0 as a floor for the host-side adapters CLI. Before committing, verify three things yourself: that your harness appears in the install matrix, that the plugin installs under the scope you intend (user versus org-managed), and that the workflows you write survive a minor version bump, because the release history shows a project still settling its surface.
Community notes