{
  "id": "page:docs-user-guide-features-adapters",
  "_kind": "Page",
  "_file": "wiki/docs/user-guide/features/adapters.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "sourcePath": "docs/user-guide/features/adapters.md",
    "sourceKind": "repo-docs",
    "title": "Adapters: Run Babysitter on Any Harness",
    "displayName": "Adapters: Run Babysitter on Any Harness",
    "slug": "docs/user-guide/features/adapters",
    "articlePath": "wiki/docs/user-guide/features/adapters.md",
    "article": "\n[Docs](../index.md) › [Features](./index.md) › Adapters\n\n# Adapters: Run Babysitter on Any Harness\n\n**Version:** 6.0.0 (v6) · **Last Updated:** 2026-06-22 · **Category:** Feature Guide\n\n---\n\n## In Plain English\n\n**Adapters let your Babysitter processes run on any supported AI coding harness - not just Claude Code.**\n\nBefore v6, Babysitter orchestration was wired specifically to Claude Code's session and hook model. With **Adapters**, the orchestration runtime is harness-agnostic: the same process, the same journal, the same quality gates and breakpoints run on Claude Code, Codex, Cursor, Gemini, GitHub Copilot, and a growing list of others. You pick the harness; Babysitter adapts to it.\n\nThere are two ways you will touch Adapters:\n\n- **The Adapters runtime** - the harness-agnostic core that every Babysitter run now sits on. You don't install this separately; it ships with the SDK.\n- **The [Adapters CLI](../reference/adapters-cli.md)** (`adapters`) - a host-side binary that lets you run and manage harnesses directly from your shell.\n\n> **Headline change for v6:** Babysitter is no longer \"an orchestration framework for Claude Code.\" It is an orchestration framework for *any supported harness*, and Adapters is the subsystem that makes that true.\n\n> **Adapters is a FAMILY, not one thing.** What this page calls \"Adapters\" is really 20 distinct package types under `packages/adapters/` — triggers (CI), extensions (plugin compile), hooks (mandatory-stop lifecycle), proxy (140+ providers), tasks (durable breakpoints), codecs (per-harness drivers), and more. When you hear \"adapters,\" ask *which* adapter. The full enumeration is in the [Adapter Types reference](../reference/adapter-types.md).\n\n---\n\n## On this page\n\n- [Why Adapters Exist](#why-adapters-exist)\n- [The Adapters Runtime (Technical Depth)](#the-adapters-runtime-technical-depth)\n- [How Adapters Replace the Legacy Model](#how-adapters-replace-the-legacy-model)\n- [Getting Started with Adapters](#getting-started-with-adapters)\n- [Related Documentation](#related-documentation)\n\n---\n\n## Why Adapters Exist\n\nThe original Babysitter design assumed one [harness](../reference/glossary.md) (Claude Code) and one continuation mechanism (Claude's `Stop` hook). Every new harness meant hand-rolling the orchestration loop against that harness's specific lifecycle - bespoke code, duplicated logic, and drift between integrations.\n\nAdapters invert that. A harness is integrated by describing it - its capabilities, its hook model, its command surface - as data in a catalog, and the runtime adapts. Adding or updating a harness becomes an **adapter/data change**, not a fork of the orchestration engine.\n\nThis is the core v6 story: **harness-agnosticism through adapters**.\n\n---\n\n## The Adapters Runtime (Technical Depth)\n\nThe Adapters runtime is composed of several cooperating packages under `packages/adapters/*`:\n\n| Subsystem | Responsibility |\n|-----------|----------------|\n| **Core** | The harness-agnostic run/session/options model that every adapter implements against |\n| **SDK** | The programmatic surface processes use to run agents through adapters |\n| **Gateway** | The browser/mobile gateway service (`adapters gateway serve`) for remote control of runs |\n| **Observability** | Session, cost, and trace capture across harnesses |\n| **Codecs** | Encoding/decoding of harness-specific message and tool formats into the common model |\n| **Transport** | Provider transports (Anthropic, OpenAI chat/responses, Google) and the proxy used by `adapters launch` |\n| **Harness mock** | A mock harness (`--use-mock-harness`) for testing processes without spending tokens |\n\n### How Adapters Relate to the Rest of v6\n\nAdapters is the runtime layer the other v6 subsystems plug into:\n\n- **[Hooks Adapter](hooks.md)** - a canonical session store plus a merge engine that normalizes each harness's distinct hook/continuation model (Claude `Stop`, Gemini/antigravity `AfterAgent`, openclaw daemon `agent_end`, opencode `session.idle`, Hermes ACP, and the thin `/skill:*` alias harnesses) into one consistent contract. Adapters do not generalize the Claude `Stop`-hook model onto harnesses that don't have it.\n- **Breakpoints Adapter** - serverless-durable human-in-the-loop approval with pluggable backends (GitHub Issues, server) and \"proven\" cryptographic signing. See [Breakpoints](breakpoints.md).\n- **Transport Adapter and Triggers** - normalize provider transports and inbound webhooks (GitHub/GitLab/Bitbucket) so a run can be launched from CI. See [GitHub Actions Setup](../../github-actions-setup-babysitter.md).\n- **Atlas** - the catalog that the runtime reads to discover harness capabilities and adapters.\n\n### v6 Architecture\n\n```mermaid\ngraph TD\n    subgraph User[\"You\"]\n        CLI[\"adapters CLI (host-side)\"]\n        INS[\"/babysitter:* (in-session)\"]\n    end\n\n    subgraph Runtime[\"Adapters Runtime (harness-agnostic core)\"]\n        CORE[\"Core: run / session / options model\"]\n        SDK[\"SDK\"]\n        HOOKS[\"Hooks Adapter (canonical session store + merge engine)\"]\n        BP[\"Breakpoints Adapter\"]\n        TRANS[\"Transport Adapter + Triggers\"]\n        OBS[\"Observability\"]\n    end\n\n    ATLAS[\"Atlas (capability + adapter catalog)\"]\n\n    subgraph Harnesses[\"Supported Harnesses\"]\n        H1[\"Claude Code\"]\n        H2[\"Codex\"]\n        H3[\"Cursor / Gemini / Copilot / ...\"]\n    end\n\n    CLI --> CORE\n    INS --> SDK\n    SDK --> CORE\n    CORE --> HOOKS\n    CORE --> BP\n    CORE --> TRANS\n    CORE --> OBS\n    CORE --> ATLAS\n    ATLAS --> Harnesses\n    HOOKS --> Harnesses\n```\n\n---\n\n## How Adapters Replace the Legacy Model\n\n| Prod (pre-v6) mental model | v6 reality with Adapters |\n|----------------------------|--------------------------|\n| \"Orchestration framework for Claude Code\" | Orchestration framework for any supported harness |\n| Loop driven by Claude's `Stop` hook | Per-harness continuation models normalized by the Hooks Adapter |\n| New harness = bespoke SDK integration code | New harness = an adapter/data entry in Atlas |\n| `Agent-Mux` packages (`-mux`) | Renamed to **Adapters** (`-adapter`) |\n\nIf you are reading older docs that describe hand-rolling the SDK loop into a harness, treat that as a contributor-level integration note - the user-facing path is now the Adapters runtime plus the per-harness pages.\n\n---\n\n## Getting Started with Adapters\n\nInstall the host-side CLI and run a harness immediately:\n\n```bash\nnpm install -g @a5c-ai/adapters-cli\nadapters doctor\nadapters run claude \"explain this codebase\"\n```\n\nTo use Adapters from inside a harness as a Babysitter orchestration run, install that harness's plugin (see the per-harness pages) and use its command surface.\n\n---\n\n## Related Documentation\n\n- [Adapter Types reference](../reference/adapter-types.md) - All 20 adapter package types enumerated (Adapters is a family)\n- [Adapters (ecosystem overview)](../ecosystem/adapters.md) - Introductory tour of the adapters family\n- [Adapters CLI Reference](../reference/adapters-cli.md) - Every `adapters` command and flag\n- [Architecture & How It Fits Together](../architecture.md) - Where Adapters sits in the whole ecosystem\n- [Architecture Overview](architecture-overview.md) - Where Adapters sits in the v6 architecture\n- [Hooks](hooks.md) - The Hooks Adapter and per-harness continuation models\n- [Harnesses: Install Matrix](../harnesses/install-matrix.md) - All supported harnesses\n- [Claude Code](../harnesses/claude-code.md) · [Codex](../harnesses/codex.md) - Fully-worked harness pages\n- [Glossary](../reference/glossary.md) - Adapter, Harness, Atlas, and related terms\n\n## Next steps\n\n- **Next:** [Adapter Types reference](../reference/adapter-types.md) — all 20 types\n- **Related:** [Adapters CLI Reference](../reference/adapters-cli.md), [Install Matrix](../harnesses/install-matrix.md), [Hooks](./hooks.md), [Architecture & How It Fits Together](../architecture.md)\n",
    "documents": []
  },
  "outgoingEdges": [],
  "incomingEdges": [
    {
      "from": "page:docs-user-guide-features",
      "to": "page:docs-user-guide-features-adapters",
      "kind": "contains_page"
    }
  ]
}