The Runtime Abstraction Layer: Swap the Model, Keep the Mind

One manager, six runtimes, one contract

AdapterManager owns the lifecycle of every model runtime attached to Agentis: registration, task dispatch, cancellation, inbound event bridging, and per-runtime health. Six concrete adapters ship today — ClaudeCodeAdapter, CodexAdapter, CursorAdapter, HermesAgentAdapter, AntigravityAdapter, and a generic HttpAdapter for any HMAC-authenticated custom endpoint — and the orchestration engine never touches any of them directly. It calls one method, dispatchTask(task, agentId), and gets back a normalized stream of thoughts, tool calls, and results regardless of which runtime is actually behind that agent.

What actually stays put when you swap

An agent's row in the agents table, its memory episodes, and its skill atoms are keyed by the agent's own id — never by adapter type. Change the adapterType on an existing agent and every memory it ever formed, every skill it ever earned, and every habit reinforced through repeated success is still there on its very next turn. The new runtime doesn't get a fresh identity; it inherits the old one's mind.

Guarding against a bad host

A global semaphore caps concurrent runtime process dispatches across every run and swarm at once (default 128, override with AGENTIS_MAX_CONCURRENT_PROCESSES), and each adapter type is wrapped in its own circuit breaker — so one flaky runtime backing off doesn't starve or crash the others. Runtime health is introspectable per adapter, not just platform-wide.

The mechanics of routing a task to the right runtime — capability matching, model-tier selection, session continuity — get their own full treatment in Agents & Cognition. This page is the ownership argument; that one is the engineering.

Continue