Agentic AI Atlasby a5c.ai
OverviewWikiGraphFor AgentsEdgesSearchWorkspace
/
GitHubDocsDiscord
i.4Wiki
Agentic AI Atlas · Architecture Overview
docs/user-guide/features/architecture-overviewa5c.ai
Search the atlas/
Wiki · linked records

Article and nearby pages

I.Current articlepp. 1 - 1
Adapters: Run Babysitter on Any HarnessBest Practices Guide: Comprehensive Reference for BabysitterBreakpoints: Human-in-the-Loop ApprovalHooks: Extensible Lifecycle EventsJournal System: Event Sourcing and Audit TrailParallel Execution: Running Tasks Concurrently
I.
Wiki article

docs/user-guide/features/architecture-overview

Reading · 10 min

Architecture Overview reference

Docs(../index.md) › Features(./index.md) › Architecture Overview

Page nodewiki/docs/user-guide/features/architecture-overview.mdNearby pages · 11Documents · 0

Continue reading

Nearby pages in the same section.

Adapters: Run Babysitter on Any HarnessBest Practices Guide: Comprehensive Reference for BabysitterBreakpoints: Human-in-the-Loop ApprovalHooks: Extensible Lifecycle EventsJournal System: Event Sourcing and Audit TrailParallel Execution: Running Tasks ConcurrentlyProcess Definitions: JavaScript Workflow OrchestrationProcess LibraryQuality Convergence: Iterative Improvement Until Targets MetRun Resumption: Pause and Continue WorkflowsTwo-Loops Architecture: Understanding Hybrid Agentic Systems

Docs › Features › Architecture Overview

Architecture Overview

**Version:** 6.0.0 (v6) **Last Updated:** 2026-06-22 **Category:** Feature Guide

---

In Plain English

**Babysitter v6 is built around one headline subsystem: Adapters - the harness-agnostic runtime that lets the same orchestration run on any supported AI coding harness.**

Think of it like this:

  • **Adapters** is the universal adapter plug - it lets Babysitter speak to Claude Code, Codex, Cursor, Gemini, and the rest through one common interface
  • **The SDK** is the operations team - it actually runs the process
  • **The Journal** is the filing cabinet - it keeps a replayable record of everything
  • **Breakpoints** are the approval desk - they pause for human review when needed
  • **Atlas** is the directory - the catalog the runtime reads to discover each harness's capabilities

**Tip for beginners:** You don't need to understand the architecture to use Babysitter. This document is for those who want to understand how it works under the hood, or who are building custom processes.

**Related:** Adapters for the headline subsystem, and Two-Loops Architecture for the conceptual model of orchestration and AI working together.

---

On this page

  • Overview
  • High-Level Architecture
  • Core Components
  • Data Flow
  • State Management
  • Extensibility
  • Design Patterns

---

Overview

Babysitter v6 uses a modular, **harness-agnostic** architecture designed for reliability, debuggability, and extensibility. The system combines a deterministic orchestration engine with adaptive AI capabilities, runs on top of the **Adapters** runtime so it is not tied to any single harness, and is backed by an event-sourced persistence layer.

The central change from the prior (Claude-only) design: orchestration no longer assumes one harness and one continuation hook. The Adapters runtime - together with the Hooks Adapter, Breakpoints Adapter, Transport Adapter, and the Atlas catalog - makes harness-agnosticism the core story.

---

High-Level Architecture

---

Core Components

1. Adapters Runtime

**Package family:** @a5c-ai/*-adapter (formerly the -mux / Agent Mux packages) under packages/adapters/*

**Responsibilities:**

  • Presents a harness-agnostic run/session/options model to the orchestration engine
  • Normalizes each harness's distinct hook/continuation model via the Hooks Adapter
  • Routes runs to providers via the Transport Adapter and the proxy used by adapters launch
  • Reads the Atlas catalog to discover harness capabilities

**Technology:** Node.js, TypeScript. See Adapters and the Adapters CLI Reference.

---

2. Babysitter Skill / Plugin (per harness)

**Location:** plugins/babysitter-unified/skills/babysit/ (and the per-harness plugin packages)

**Responsibilities:**

  • Parses natural language commands into process inputs
  • Orchestrates the run loop via the SDK/CLI on top of the Adapters runtime
  • Manages iteration lifecycle and resumption
  • Reports progress back to the harness

**Technology:** The harness's plugin/skill system (JavaScript/TypeScript). The in-session command surface and continuation model **vary by harness** - see Hooks and the Install Matrix.

---

3. Babysitter SDK

**Package:** @a5c-ai/babysitter-sdk

**Core Modules:**

ModulePurposeKey Functions
**Process Engine**Executes process definitionsrunProcess(), iterate()
**Journal Manager**Event-sourced persistenceappend(), replay(), getState()
**Task Executor**Runs tasks (agent, skill, node)executeTask(), parallel.all()
**State Manager**Maintains run state cachesaveState(), loadState()
**Hook System**Extensibility pointsregisterHook(), trigger()

**Technology:** Node.js, TypeScript

---

4. Event-Sourced Journal

**Format:** Individual JSON files in journal/ directory, one per event, named {SEQ}.{ULID}.json (e.g. 000001.01ARZ3NDEKTSV4RRFFQ69G5FAV.json)

**Event Types:**

typescript
type JournalEvent =
  | { type: 'RUN_CREATED', recordedAt: string, data: { runId: string, inputs: any }, checksum: string }
  | { type: 'EFFECT_REQUESTED', recordedAt: string, data: { effectId: string, kind: string, args: any }, checksum: string }
  | { type: 'EFFECT_RESOLVED', recordedAt: string, data: { effectId: string, result: any }, checksum: string }
  | { type: 'RUN_COMPLETED', recordedAt: string, data: { status: string }, checksum: string }
  | { type: 'RUN_FAILED', recordedAt: string, data: { error: string }, checksum: string }

// Note: seq is derived from the filename, not stored in the event body.
// Breakpoints use EFFECT_REQUESTED with kind: 'breakpoint' and EFFECT_RESOLVED.

**Benefits:**

  • **Deterministic replay**: Reconstruct exact state at any point
  • **Audit trail**: Complete history of all actions
  • **Debugging**: Trace execution flow and identify issues
  • **Resumability**: Continue from last event after interruption

**Implementation:**

javascript
// Write individual JSON file per event
function appendEvent(event, seq) {
  const filename = `${String(seq).padStart(6, '0')}.${ulid()}.json`;
  fs.writeFileSync(path.join(journalDir, filename), JSON.stringify(event, null, 2));
}

// Replay by reading all JSON files from journal/ directory
function replayJournal() {
  const files = fs.readdirSync(journalDir)
    .filter(f => f.endsWith('.json'))
    .sort(); // lexicographic sort preserves sequence order

  const events = files.map(f =>
    JSON.parse(fs.readFileSync(path.join(journalDir, f), 'utf-8'))
  );

  return events.reduce(applyEvent, initialState);
}

For more details on the journal system, see Journal System.

---

5. Process Definitions

**Format:** JavaScript/TypeScript functions

**Execution Model:**

Code
+----------------------------------------------------------+
| Process Definition (JavaScript)                          |
|                                                          |
|  export async function process(inputs, ctx) {           |
|    // User-defined orchestration logic                  |
|    const result = await ctx.task(someTask, args);       |
|    await ctx.breakpoint({ question: '...' });           |
|    return result;                                        |
|  }                                                       |
+----------------------------------------------------------+
                          |
                          v
+----------------------------------------------------------+
| Context API (ctx)                                        |
|                                                          |
|  - ctx.task(task, args, opts)       Execute task        |
|  - ctx.breakpoint(opts)             Wait for approval   |
|    Returns BreakpointResult: { approved, feedback, ... }|
|  - ctx.parallel.all([...])          Run in parallel     |
|  - ctx.hook(name, data)             Trigger hooks       |
|  - ctx.log(msg, data)               Log to journal      |
|  - ctx.getState(key)                Access state        |
|  - ctx.setState(key, value)         Update state        |
+----------------------------------------------------------+

**Process Lifecycle:**

1. **Load**: Process definition loaded from file or default 2. **Initialize**: Context created with state and journal access 3. **Execute**: Process function called with inputs and context 4. **Iterate**: Process may loop internally or be called multiple times 5. **Complete**: Process returns final result

For more details on creating processes, see Process Definitions.

---

6. Task Execution System

**Task Types:**

TypeExecutorUse CaseExample
**Agent**LLM APIPlanning, analysis, scoringAny supported harness
**Skill**Harness skillCode operationsRefactoring, search
**Node**Node.jsScripts and toolsBuild, test, deploy
**Shell**System shellCommandsgit, npm, docker

**Execution Flow:**

Code
+---------------------------------------------------------+
| Task Request                                            |
| ctx.task(taskDef, args, opts)                           |
+-----------------+---------------------------------------+
                  |
                  v
+---------------------------------------------------------+
| Task Validation                                         |
| - Validate arguments                                    |
| - Check dependencies                                    |
| - Generate task ID                                      |
+-----------------+---------------------------------------+
                  |
                  v
+---------------------------------------------------------+
| Journal Event: EFFECT_REQUESTED                         |
+-----------------+---------------------------------------+
                  |
                  v
+---------------------------------------------------------+
| Execute Task                                            |
| - Agent: Call LLM API                                   |
| - Skill: Invoke the harness skill                       |
| - Node: Run JavaScript function                         |
| - Shell: Execute command                                |
| - Breakpoint: Wait for approval (kind: breakpoint)      |
+-----------------+---------------------------------------+
                  |
                  v
+---------------------------------------------------------+
| Journal Event: EFFECT_RESOLVED                          |
+-----------------+---------------------------------------+
                  |
                  v
+---------------------------------------------------------+
| Return Result                                           |
| - Success: Return task output                           |
| - Failure: Throw error or return error object           |
+---------------------------------------------------------+

**Parallel Execution:**

javascript
// Tasks run concurrently with Promise.all
await ctx.parallel.all([
  () => ctx.task(task1, args1),
  () => ctx.task(task2, args2),
  () => ctx.task(task3, args3)
]);

// All results returned when all complete
// If any fails, entire parallel group fails

For more details on parallel execution, see Parallel Execution.

---

Data Flow

**Complete Request Flow:**

Code
1. User Command
   |
   +--> Harness (Claude Code, Codex, Cursor, ...)
        |
        +--> Babysitter Skill
             |
             +-- Parse intent
             +-- Load/create run
             +--> CLI: babysitter run:iterate (on the Adapters runtime)
                  |
                  +--> SDK Process Engine
                       |
                       +-- Load process definition
                       +-- Replay journal -> restore state
                       +-- Execute process function
                       |    |
                       |    +-- ctx.task() -> Execute tasks
                       |    |    |
                       |    |    +-- Append EFFECT_REQUESTED
                       |    |    +-- Run executor (agent/skill/node/shell)
                       |    |    +-- Append EFFECT_RESOLVED
                       |    |
                       |    +--> ctx.breakpoint() -> Wait for approval
                       |         |
                       |         +-- Append EFFECT_REQUESTED (kind: breakpoint)
                       |         +-- Poll for response
                       |         +-- Append EFFECT_RESOLVED
                       |
                       +-- Append iteration events to journal
                       +-- Save state cache
                       +--> Return results to skill
                            |
                            +--> Report to the harness
                                 |
                                 +--> Display to user

---

State Management

**Two-Layer State System:**

1. **Journal (source of truth)**: - Append-only event log - Immutable history - Replayed to reconstruct state

2. **State Cache (performance)**: - Snapshot of current state - Rebuilt from journal if missing - Fast access without replay

**State Structure:**

typescript
interface RunState {
  runId: string;
  status: 'running' | 'paused' | 'completed' | 'failed';
  iteration: number;
  inputs: any;
  outputs?: any;
  processState: Map<string, any>;  // Process-specific state
  taskResults: Map<string, any>;    // Cached task results
  metrics: {
    startTime: number;
    endTime?: number;
    iterations: number;
    qualityScores: number[];
  };
}

---

Extensibility

**Hook System:**

javascript
// Register custom hooks
ctx.hook('task:completed', async (taskResult) => {
  await sendMetricsToDatadog(taskResult);
});

ctx.hook('quality:score', async (score) => {
  if (score < 70) {
    await sendAlert('Low quality score');
  }
});

// Built-in hook points
- 'run:started'
- 'run:completed'
- 'iteration:started'
- 'iteration:completed'
- 'task:started'
- 'task:completed'
- 'breakpoint:requested'
- 'breakpoint:resolved'
- 'quality:score'

**Custom Task Types:**

javascript
// Define custom task executor
function registerCustomTask(type, executor) {
  taskExecutors.set(type, executor);
}

// Use custom task
await ctx.task({ type: 'custom', fn: myExecutor }, args);

For more details on hooks, see Hooks.

---

Technology Stack

ComponentTechnologyPurpose
**Adapters Runtime**TypeScript + Node.jsHarness-agnostic run/session model
**Plugin**JavaScript/TypeScriptPer-harness integration (12 harnesses)
**SDK**TypeScript + Node.jsCore orchestration engine
**Process Definitions**JavaScript/TypeScriptUser workflow logic
**Journal**Individual JSON filesEvent persistence
**CLI**Commander.jsCommand-line interface

---

Design Patterns

**Event Sourcing:**

  • All state changes recorded as events
  • State derived from event replay
  • Time-travel debugging possible

**Command Query Responsibility Segregation (CQRS):**

  • Write: Append events to journal
  • Read: Query state cache or replay

**Saga Pattern:**

  • Long-running workflows with compensation
  • Breakpoints as decision points
  • Resumable across sessions

**Plugin Architecture:**

  • Extensible via hooks
  • Custom task types
  • Process definitions as plugins

---

Related Documentation

  • Adapters - The headline v6 runtime and harness-agnosticism
  • Hooks - The Hooks Adapter and per-harness continuation models
  • Two-Loops Architecture - Conceptual model of orchestration and AI loops
  • Process Definitions - Creating custom processes
  • Journal System - Event sourcing and replay
  • Breakpoints - Human-in-the-loop approval
  • Parallel Execution - Running tasks concurrently

---

Summary

Babysitter's v6 architecture is built on these key principles:

  • **Harness-agnostic by default**: The Adapters runtime lets the same process run on any supported harness
  • **Modular Design**: Each component has a clear, single responsibility
  • **Event Sourcing**: The journal provides a complete, replayable audit trail
  • **Two-Layer State**: Journal for truth, cache for performance
  • **Extensibility**: Hooks and custom tasks enable integration with any system
  • **Human-in-the-Loop**: Breakpoints enable approval workflows

This architecture enables reliable, debuggable, and auditable AI-powered workflows that can run on any harness and be paused, resumed, and replayed at any point.

---

Next steps

  • **Next:** Two-Loops Architecture
  • **Related:** Adapters, Journal System, Hooks

Trail

Wiki
Babysitter Docs
Babysitter User Guide
Features

Architecture Overview

Continue reading

Adapters: Run Babysitter on Any Harness
Best Practices Guide: Comprehensive Reference for Babysitter
Breakpoints: Human-in-the-Loop Approval
Hooks: Extensible Lifecycle Events
Journal System: Event Sourcing and Audit Trail
Parallel Execution: Running Tasks Concurrently
Process Definitions: JavaScript Workflow Orchestration
Process Library

Page record

Open node ledger

wiki/docs/user-guide/features/architecture-overview.md

Documents

No documented graph nodes on this page.