Agentic AI Atlasby a5c.ai
OverviewWikiGraphFor AgentsEdgesSearchWorkspace
/
GitHubDocsDiscord
i.3Wiki
Agentic AI Atlas · Overview — Agent-Adapter Babysitter Integration
docs/adapters-babysitter-integrations/overviewa5c.ai
Search the atlas/
Wiki · linked records

Article and nearby pages

I.Current articlepp. 1 - 1
Effect Resolution Pipeline ChangesExternal Agent TasksPlugin Mode — Babysitter SDK Running Inside Host AgentsProcess Authoring UpdatesSDK-Level Agent-Adapter DiscoveryTasks-Adapter as Unified Task Routing Hub
I.
Wiki article

docs/adapters-babysitter-integrations/overview

Reading · 3 min

Overview — Agent-Adapter Babysitter Integration reference

Allow babysitter processes to discover what agents and models are available in the environment and dispatch work to them. When adapters is installed, processes gain access to external agents (claude-code, codex, gemini-cli, copilot, etc.) as first-class task targets alongside the internal genty-core session.

Page nodewiki/docs/adapters-babysitter-integrations/overview.mdNearby pages · 7Documents · 0

Continue reading

Nearby pages in the same section.

Effect Resolution Pipeline ChangesExternal Agent TasksPlugin Mode — Babysitter SDK Running Inside Host AgentsProcess Authoring UpdatesSDK-Level Agent-Adapter DiscoveryTasks-Adapter as Unified Task Routing HubTest Strategy — Agent-Adapter Babysitter Integration

Overview — Agent-Adapter Babysitter Integration

Goal

Allow babysitter processes to discover what agents and models are available in the environment and dispatch work to them. When adapters is installed, processes gain access to external agents (claude-code, codex, gemini-cli, copilot, etc.) as first-class task targets alongside the internal genty-core session.

Architecture

**tasks-adapter** is the unified routing hub. The SDK routes ALL task dispatch through tasks-adapter, which decides how to resolve each task based on responder type.

Code
Process Definition (defineTask)
  │
  ctx.task(myTask)
  │
  ↓ tasks-adapter routes by responderType:
  │
  ├─ responderType: "internal"  → genty-core session (direct API)
  ├─ responderType: "human"     → breakpoint → human responder (existing)
  ├─ responderType: "agent"     → adapters adapter (claude-code, codex, etc.)
  ├─ responderType: "tracker"   → external issue tracker (Jira, Linear)
  └─ responderType: "auto"      → tasks-adapter picks best available

This works identically in both modes:

  • **Standalone** (genty, agent-platform CLI): tasks-adapter resolves directly
  • **Plugin** (inside claude-code, codex): tasks-adapter resolves agent/tracker tasks internally; host-resolvable tasks delegated via stop-hook

Capability Layers

Layer 1: Discovery (SDK)

SDK optionally detects adapters and queries available agents/models. This information is injected into process creation context so the LLM can make informed decisions about task routing.

Layer 2: Task Definition (SDK)

defineTask gains responderType field. Tasks specify what kind of responder they need — internal, human, agent, tracker, or auto. tasks-adapter handles the routing.

Layer 3: Routing (tasks-adapter)

tasks-adapter matches tasks to responders based on type, availability, capabilities, and priority. Agent responders wrap adapters adapters. Tracker responders wrap external issue tracker APIs. Human responders use existing breakpoint infrastructure.

Layer 4: Effect Resolution (agent-platform + tasks-adapter)

When orchestrateIteration encounters a task effect, it delegates to tasks-adapter for routing. tasks-adapter resolves via the appropriate backend (adapters, breakpoint, tracker, internal).

Layer 5: Process Authoring (SDK + agent-platform)

Process creation prompts include available responders (agents, humans, trackers) when detected. The LLM chooses routing based on task requirements.

Key Constraint

Adapters is **optional**. The SDK must work without it. Discovery returns empty results when adapters is not installed. External agent tasks fail with a clear error if adapters is unavailable at runtime.

Packages Affected

PackageChanges
packages/tasks-adapterAgent responder backend, task router, responder types, adapters integration
packages/babysitter-sdkDiscovery API, responderType on tasks, route through tasks-adapter
packages/genty/platformEffect resolution delegates to tasks-adapter, process prompt updates
packages/genty/coreNone (internal agent tasks unchanged)
packages/adaptersNone (existing run/launch API consumed by tasks-adapter)
packages/adapters/hooksHost tool discovery, capability extensions

Non-Goals (This Phase)

  • Streaming subagent output back to parent in real-time
  • Multi-agent orchestration patterns (group chat, voting across external agents)
  • External agent session continuity (each dispatch is a fresh session)
  • Cost budget enforcement across external dispatches (tracked but not enforced)

Trail

Wiki
Babysitter Docs
Agent-Adapter ↔ Babysitter Integration

Overview — Agent-Adapter Babysitter Integration

Continue reading

Effect Resolution Pipeline Changes
External Agent Tasks
Plugin Mode — Babysitter SDK Running Inside Host Agents
Process Authoring Updates
SDK-Level Agent-Adapter Discovery
Tasks-Adapter as Unified Task Routing Hub
Test Strategy — Agent-Adapter Babysitter Integration

Page record

Open node ledger

wiki/docs/adapters-babysitter-integrations/overview.md

Documents

No documented graph nodes on this page.