# a5c-ai/babysitter: deterministic orchestration for AI coding harnesses > Babysitter is an MIT-licensed Node.js tool that runs the same enforced workflow across 12 AI coding harnesses, recording every decision in an immutable journal. It is a process engine for agents, not a coding assistant. **a5c-ai/babysitter** — Babysitter enforces obedience on agentic workforces and enables them to manage extremely complex tasks and workflows through deterministic, hallucination-free self-orchestration - Repository: https://github.com/a5c-ai/babysitter - Website: https://a5c.ai - Stars: 1,822 · Forks: 112 - Language: JavaScript - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/a5c-ai-babysitter ## The problem: agents that improvise inside long workflows A coding agent given a long task will drift. It skips a verification step, invents a file that does not exist, or decides on its own that a quality gate is optional. Babysitter's answer is to move the process out of the model's judgement and into code. The README states the intent plainly: define your workflow in code, and Babysitter enforces every step, ensures quality gates pass before progression, requires human approval at breakpoints, and records every decision in an immutable journal. The tagline is "enforce obedience on agentic workforces". The audience is narrow on purpose. This is for teams already running agentic coding sessions who have hit the ceiling of what a single prompt or a loose skill file can hold: multi-stage migrations, release procedures with sign-off, anything where an out-of-order step costs real money. If your work is one question and one answer, the enforcement layer is pure overhead. ## How the orchestration layer sits between you and the harness The architecture splits into two tracks, and the README is explicit that they should not be conflated. The host-side `adapters` CLI runs any supported harness directly from your shell. The in-session per-harness plugin drives full orchestration runs from inside your harness. Most users, the README says, want both. As of v6 the project describes itself as harness-agnostic through its Adapters runtime, so the same process definition runs across the 12 supported AI coding harnesses. That is the load-bearing design decision: the workflow is not written against Claude Code's or Codex's plugin API, it is written once and dispatched through an adapter. The repository layout backs this up. Under `packages/adapters/hooks/` there are separate adapter packages for claude, codex, gemini, copilot, cursor, pi, oh-my-pi, opencode, openclaw, antigravity, hermes and genty, which matches the claim of 12 harnesses. Only one plugin source is maintained: `plugins/babysitter-unified/plugin.json`. Harness-specific bundles are generated during build or release and are not committed. That is a sensible choice for a project with this many targets, but it means reading the repository tree will not show you the shipped plugin for your harness. ## Installing the CLI and running a first harness command Prerequisites come first. The README requires Node.js 20.0.0 or newer, with 22.x LTS recommended, and notes that the host-side `adapters` CLI pins a higher floor of 22.13.0 or newer because it loads the gateway's built-in `node:sqlite`, which is unflagged only from Node 22.13.0. That is a real constraint, not a formality: on an older Node the adapters CLI will not work. The recommended end-user install is the main CLI package: ```bash npm install -g @a5c-ai/babysitter ``` If you would rather drive a harness straight from your shell, install the host-side CLI separately and check the environment before running anything: ```bash npm install -g @a5c-ai/adapters-cli adapters doctor adapters run claude "explain this codebase" ``` The README gives `adapters doctor` as the diagnostic step, so run it before your first real command and treat a failure there as a Node version problem first. The `adapters run` example takes a harness name and a prompt string. For in-session orchestration with Claude Code, the README documents a native marketplace install: ```bash claude plugin marketplace add a5c-ai/babysitter-claude claude plugin install --scope user babysitter@a5c.ai ``` After restarting Claude Code, type `/skills` and confirm that "babysit" appears. For Codex CLI, which the README labels Beta, the install is: ```bash codex plugin marketplace add a5c-ai/babysitter-codex codex plugin add babysitter --marketplace babysitter ``` The README warns that `--marketplace babysitter` is the marketplace name declared in the repository's `.agents/plugins/marketplace.json`, not the repository name. Cursor and Gemini CLI are covered by `babysitter harness:install-plugin cursor` and `babysitter harness:install-plugin gemini-cli`, both marked experimental. ## Where Babysitter stops being the right tool The version number is the first honest signal. The root `package.json` reads 6.0.3, but the published release line shown is v0.0.188 from 2026-06-26, and the two releases before it landed the same day in April. A 0.0.x series with that many cuts is a project still finding its shape, and the README's own labels agree: Codex is Beta, Cursor and Gemini CLI and GitHub Copilot are Experimental. The package split is the second friction point. `@a5c-ai/babysitter`, `@a5c-ai/adapters-cli`, `@a5c-ai/babysitter-sdk`, `@a5c-ai/genty-platform` and per-harness plugins are distinct installs with distinct roles, and the README spends a paragraph warning that harness plugins do not replace the core CLI packages. Choose wrong and you will have a plugin with nothing to drive. There is also a Node floor mismatch to plan around. Your harness may run happily on Node 20, but the host-side adapters CLI needs 22.13.0 or newer. Teams standardizing on an older LTS image will hit this on the first `adapters doctor`. Finally, enforcement is the product. If you want an agent to explore freely and surprise you, Babysitter is designed to prevent exactly that. The README states that agents do exactly what the process permits, nothing more. That is a feature for a release pipeline and a nuisance for open-ended research. ## Compared with plain harness skills and prompt files The closest alternative is what you already have: skills, prompt files and plugin commands inside a single harness. The difference is where the control flow lives. A skill file is instructions the model may follow; a Babysitter process is a program the runtime enforces, with quality gates that must pass before progression and human approval at breakpoints. The README's framing of an immutable journal of every decision has no equivalent in a prompt file, which leaves no record beyond the transcript. The second difference is portability. A skill written for one harness is tied to that harness's plugin format. Babysitter's Adapters runtime is described as running the same processes across all 12 supported harnesses, so the workflow survives a switch from Claude Code to Codex or Gemini CLI. Whether that portability holds in practice depends on each adapter package, and the README does not document behavioural differences between them. ## Maintenance, licence and the cost of keeping up The repository is not archived, and the last push was on 2026-09-05, which is recent. Releases are frequent: v0.0.188 shipped on 2026-06-26, after v0.0.187 and v0.0.186 both on 2026-04-04. A cadence of numbered patches at that rate means upgrade cost is mostly a matter of pinned versions and re-reading the changelog, not of waiting for a stable line. The licence is MIT, stated in `package.json` and in the README badge. MIT permits commercial use and modification, and the practical implication is that you can vendor or fork the adapter packages if a harness you depend on stops being supported. That is not legal advice, and it says nothing about the licence terms of the harnesses Babysitter drives, which are separate products with their own terms. One structural risk worth naming: only `plugins/babysitter-unified/plugin.json` is maintained as plugin source, with harness bundles generated at build time. If a generated bundle for your harness is broken, the fix lives upstream, not in a committed file you can patch locally. ## What a Babysitter run actually gives you The payoff is a workflow that cannot silently reorder itself. Quality gates block progression, breakpoints stop for a human, and the journal records what happened. For a team running a release procedure or a multi-repo migration through an agent, that is the difference between a process you can audit and a transcript you have to read line by line. The cost is setup. You must pick a harness, install the right combination of core CLI and plugin, clear the Node version floor, and write your workflow as code rather than prose. The README does not document rollback behaviour for a failed gate, so plan to test that path yourself before trusting it in production. ## Conclusion Adopt Babysitter if you already pay for a harness like Claude Code or Codex and need a workflow that cannot skip a step, and start by running `npm install -g @a5c-ai/babysitter` followed by `adapters doctor`. Do not adopt it if you want a single-prompt assistant, if you are pinned below Node 22.13.0 for the host CLI, or if you cannot accept a 0.0.x version number. Verify first that your harness appears in the install matrix and that a plugin exists for it, because the README marks several harnesses as experimental and only Claude Code and Codex have dedicated pages. ## FAQ ### What is a5c-ai/babysitter? It is an MIT-licensed Node.js orchestration layer that enforces agentic workflows: it runs every step in order, requires quality gates to pass before progression, pauses for human approval at breakpoints, and writes decisions to an immutable journal. It is harness-agnostic as of v6, running the same processes across 12 supported AI coding harnesses. ### How do I install a5c-ai/babysitter? The README recommends `npm install -g @a5c-ai/babysitter` for the main CLI. For the host-side CLI that runs a harness from your shell, install `@a5c-ai/adapters-cli` and run `adapters doctor`, which requires Node 22.13.0 or newer. ### What Node.js version does a5c-ai/babysitter need? The README lists Node.js 20.0.0 or newer with 22.x LTS recommended, but the host-side `adapters` CLI pins a higher floor of 22.13.0 or newer because it loads the gateway's built-in `node:sqlite`, which is unflagged only from Node 22.13.0. ### Which AI coding harnesses does a5c-ai/babysitter support? The README points to an install matrix covering 12 harnesses, with dedicated pages for Claude Code and Codex. Cursor and Gemini CLI and GitHub Copilot are labelled Experimental, and Codex CLI is labelled Beta. ## Sources - [a5c-ai/babysitter on GitHub](https://github.com/a5c-ai/babysitter) - [License: MIT](https://github.com/a5c-ai/babysitter/blob/main/LICENSE) - [Project website](https://a5c.ai) - [README](https://github.com/a5c-ai/babysitter/blob/main/README.md) - [Releases](https://github.com/a5c-ai/babysitter/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/a5c-ai-babysitter