Agents & Cognition · 06.01
The Runtime Abstraction Layer: Adapters & the Normalized Contract
How AdapterManager drives Claude Code, Codex, Cursor, Hermes, Antigravity, and HTTP runtimes through one normalized task/result contract.
The ownership case, and the engineering underneath it
Own Your Agents makes the case for why the Runtime Abstraction Layer matters — memory and skills survive a model swap. This page is the mechanics: AdapterManager registers, dispatches to, cancels, and health-checks every runtime through one interface, wrapping each adapter type in its own circuit breaker and a shared global concurrency semaphore, so a flaky runtime degrades gracefully instead of taking the whole platform down with it.
Six adapters today, one contract
ClaudeCodeAdapter, CodexAdapter, CursorAdapter, HermesAgentAdapter, AntigravityAdapter, and HttpAdapter each translate their runtime's native protocol into the same normalized shape — a NormalizedTask in, a normalized stream of thoughts, tool calls, and results out. Nothing upstream of the adapter boundary — the engine, the Brain, chat — is written against any one runtime's actual API.
Continue
transform, code, data_query, http_request, aggregate_window, knowledge, browser, artifact_save, mcp, human_input — every data/compute/IO node explained.
Every workspace agent is ranked ready, offline-capable, enablable, or incapable against a node's declared requirements — never a hardcoded agent name.