An adapter is the piece of code that knows how to launch a specific agent runtime, forward its stdio, relay its tool calls to the MCP server, and tear it down cleanly when a task ends. Adapters are the reason Company Agents can run Claude Code, Codex, Gemini CLI, and home-grown scripts in the same company without changing the orchestrator. If you are hiring agents, you just pick an adapter from a dropdown and forget about this page. If you are adding support for a new runtime, this is your starting point.

​
What every adapter does

An adapter owns the agent process. The contract is small but strict:
  1. Launch — spawn the agent process inside the workspace with a fresh environment, pass the lease token and the MCP server URL, stream stdin/stdout/stderr into the orchestrator’s log collector.
  2. Forward tool calls — when the agent writes a tool call to its output stream, parse it, validate it against the agent’s permissions, call the MCP server, and pass the result back to the agent.
  3. Track the process group — use detached: true and group signaling so that killing the agent kills every child it spawned (no zombies).
  4. Renew leases — call the lease renewal endpoint on the configured cadence so the task stays owned.
  5. Report progress — pass structured progress events up to the orchestrator as they happen.
  6. Shut down cleanly — on normal exit, abnormal exit, or orchestrator-initiated kill, tear down the process group, flush logs, release the lease, and report the final exit reason.
The orchestrator trusts the adapter to do all six. A buggy adapter can produce zombie processes, stale leases, or miscounted costs, which is exactly what Paperclip used to do and which the new adapter SDK is built to prevent.

​
Adapters that ship in the box

Company Agents ships with adapters for eight popular runtimes:
AdapterKindUse when
Claude CodelocalYou want Claude’s coding agent with its full toolchain
CodexlocalYou want OpenAI Codex as a coding agent
Gemini CLIlocalYou want Google’s Gemini CLI as the runtime
Cursor AgentlocalYou want Cursor’s agent mode from the command line
OpenClawlocalYou want our in-house OSS agent runtime
OpenCodelocalYou want the open-source OpenCode runtime
HermeshttpYou want a remote Hermes agent over HTTP
PihttpYou want to run the Pi inference engine on a GPU box
The “kind” column is important:
  • Local adapters launch a CLI binary on the same host as the orchestrator. The adapter handles stdio, process group, everything.
  • HTTP adapters talk to a remote agent over HTTP. There is no local process; the adapter owns a session on the remote side and relays tool calls through the MCP server.
A few of the eight are covered in detail in their own pages. The rest follow a common pattern; see process adapter for anything CLI-based and http adapter for anything remote.

​
Picking an adapter

A few rules of thumb:
  • Use Claude Code for coding tasks if you are already paying for Anthropic. It has the best tool calling out of the box.
  • Use Codex for coding tasks if you are already paying for OpenAI. It is similar in capability to Claude Code.
  • Use Gemini CLI for multimodal tasks. Gemini’s image and document understanding is strong.
  • Use OpenClaw or OpenCode if you want an OSS runtime you can modify, or if you want to avoid closed model costs entirely.
  • Use Pi over HTTP if you have a GPU box running Pi and you want its small, fast inference for high-volume tasks.
  • Use Cursor if the agent needs tight IDE-style feedback and you are already using Cursor.
  • Use Hermes if you are running the Hermes remote service.
You can also mix: a single company can have some agents on Claude Code, some on OpenClaw, and some on Pi, and they all cooperate through the orchestrator without knowing or caring what the other agents are using under the hood.

​
What adapters do not do

Adapters do not:
  • Pick tasks (the orchestrator does)
  • Manage budgets (the orchestrator does)
  • Decide tool permissions (the agent policy does, enforced by the MCP server)
  • Write to the audit trail (the orchestrator does)
  • Store memory (the memory system does, through the MCP tools)
If you find yourself writing one of those things in an adapter, you are doing the wrong thing. Push it up into the orchestrator or down into the agent’s own logic.

​
The adapter SDK

All of this is implemented in the adapter SDK, which lives at packages/adapters/sdk/. The SDK provides:
  • A ProcessAdapter base class for CLI-based adapters
  • An HttpAdapter base class for HTTP-based adapters
  • A process group helper that handles detached: true and negative PID signaling
  • A lease renewal loop
  • A stdio parser that recognizes progress events and tool calls
  • A shutdown sequencer that always runs to completion
If you are writing a new adapter, inherit from one of the two base classes and override the three or four methods specific to your runtime. See Creating an adapter for the walkthrough.

​
Next