This section has three tracks:

Design documents for integrating adapters capabilities into the babysitter SDK, enabling processes to discover available agents/models and dispatch work to external harnesses.

Comprehensive inventory of missing capabilities, stub implementations, and architectural weaknesses across agent-core (L4), agent-runtime (L5), agent-platform (L6), tasks-adapter, tools-adapter, transport-adapter, and babysitter-sdk.

Use this directory as the source of truth for repository-level AI agent guidance.

This section collects long-form writing that helps readers understand the ideas behind Babysitter without making those essays part of the core task-oriented docs flow.

These guides cover the current harness-integration surface for Babysitter.

The catalog runtime has been unified into @a5c-ai/atlas as the

Generated: 2026-05-07

Babysitter blueprints are version-managed instruction packages distributed through a marketplace. They were previously called Babysitter plugins; the old plugin: CLI commands remain as deprecated aliases for one release, but new documentation and command surfaces should use plugin:.

"Babysitter plugins" (managed by babysitter-sdk CLI, stored in marketplace) should be renamed to "blueprints" to distinguish them from agent plugins (the unified/generated hooks-adapter plugins installed into agents).

This guide walks through a realistic flow that exercises the babysitter CLI and the deterministic test harness exposed from @a5c-ai/babysitter-sdk/testing. The examples target Babysitter 6.0.0 (edition v6). The end-user CLI is installed from @a5c-ai/babysitter; the programmatic runtime used by the testing harness ships in @a5c-ai/babysitter-sdk:

Architecture, philosophy, and component guides for the a5c agent orchestration platform.

Silent fallback mechanisms that hide real problems, introduce unexpected degraded behavior, or make debugging impossible. Ordered by severity within each section.

94 of 147 gaps were upgraded from their original status. The original inventory classified many features as "Missing" that had since been fully or partially implemented. The codebase has advanced far beyond what the backlog reflected.

The agent stack packages should be renamed to use the "genty" brand consistently.

This guide explains how to use the official Babysitter GitHub Action(https://github.com/a5c-ai/babysitter) (a5c-ai/babysitter@main) for automated, AI-orchestrated workflows in your CI/CD pipeline.

This guide explains how to integrate the Babysitter plugin with Claude Code GitHub Actions(https://github.com/anthropics/claude-code-action) for automated orchestration workflows in your CI/CD pipeline.

This guide explains how to integrate the Babysitter plugin with OpenAI's Codex GitHub Action(https://github.com/openai/codex-action) for automated orchestration workflows in your CI/CD pipeline.

This guide explains how to integrate the Babysitter plugin with Google's Gemini CLI GitHub Action(https://github.com/google-github-actions/run-gemini-cli) for automated orchestration workflows in your CI/CD pipeline.

(excludes test infrastructure in harness-mock: 55 refs)

This gap analysis identifies feature gaps in the Babysitter orchestration platform from the babysitter-native perspective. All gaps are framed around what the orchestration platform needs -- not what any specific host harness (like Claude Code) provides.

Unmarked coupling, maintenance hazards, missing caveats, and dangerous zones. This is the map of places where a well-intentioned change will bite you.

Hermes Agent is a Python-based (83.6% Python, 12.6% TypeScript) MIT-licensed autonomous AI agent by Nous Research. Its architecture centers on a monolithic AIAgent class (~4,400 lines in runagent.py) that powers all surfaces: CLI, messaging gateway (20+ platforms), ACP (IDE integration), batch, and API server. It supports 30+ LLM providers, 70+ tools across 28 toolsets, pluggable memory providers, a self-evolution companion system (DSPy + GEPA), and a community Skills Hub at agentskills.io.

This page is the canonical discovery index for package and plugin documentation in the Babysitter monorepo.

Agent plugins are the harness integration packages that install Babysitter into tools such as Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and GitHub Actions. They remain plugins.

This section contains the current reference docs that remain part of the published docs surface.

<!-- Generated by .claude/skills/assimilate-popular-workflows. Re-run to refresh. -->

1. Ensure release-notes.md matches the changelog section before approving the release.

<!-- Generated by .claude/skills/catalog-babysitter-users. Re-run the skill to refresh. -->

Core SDK improvements including CLI bash migration, shell-to-CLI refactor, DX optimization, path resolution utilities, completionSecret rename, prompt persistence, staging versioning, and hook thin-shell refactors. All completed successfully.

Supermemory is a cloud memory engine and context layer for AI agents, ranking 1

This directory defines the replacement testing strategy after the legacy Docker and Docker-E2E workflows were removed. The current CI implementation lives primarily in .github/workflows/publish.yml, with GitHub Actions owning the live-stack scenario and OS matrix. The new plan starts from repository-native package boundaries, Babysitter harness setup commands, the agent-platform runtime surface, and explicit model/no-model lanes instead of reusing the retired Docker image and e2e-tests/docker suite.

New here? Jump straight to Start here(start-here) for the 20-minute path, or use the task-based(i-want-to) and role-based(by-role-and-level) entry points below to go directly to the page you need.

When babysitter started, it was a single npm package that could wrap an AI agent session in a structured process. You called defineTask, wrote some effects, and the SDK kept your agent on the rails. That was useful, but it only worked with one harness, in one environment, with one person watching.

This directory documents a pragmatic V6 evolution for the Babysitter stack. The intent is not to describe the biggest possible modular future. The intent is to define the smallest architecture change that is worth shipping, can be validated against the current repository, and leaves room for later extraction if the seams prove real.

This document is the repo-level source of truth for which npm workspaces are active, which ones are release-critical, and which workflow path validates them.