Coding agents + agent runtimes

A coding agent or agent runtime is what actually runs an agent — loads its skills, manages its session, calls the LLM, executes tool calls, streams results back. It can be a CLI tool you launch (Claude Code, Pi Coding Agent, Codex) or a programmatic SDK you embed (Claude Agent SDK, OpenAI Agents SDK, LangGraph).

LIFEOSAI’s orchestration substrate doesn’t care which one you use. It needs an adapter contract — system prompt + working directory + tools + streaming response — and any runtime that meets it works.

What’s in production today

Runtime	Shape	Status	Notes
Claude Code	CLI tool · embeds Claude Agent SDK	✅ Production · default	All 40 production agents use it today. Long-form reasoning, careful editing, multi-file context, MCP, skills, sessions.
Claude Agent SDK	TypeScript / Python SDK	✅ Production	Same backend as Claude Code; called programmatically from inside applications.
Pi Coding Agent	CLI tool · open source	✅ Production-ready	Custom; supports local OSS models. Pluggable backend. Reaches MCP, skills, permissions same as Claude Code.

Where we are heading

Runtime	Shape	Why we plan to add it
OpenAI Codex	CLI / SDK	OpenAI’s coding agent — pairs with GPT-5 reasoning
Google Gemini agent	CLI / SDK	When Gemini’s agent surface stabilises and matches the contract
OpenAI Agents SDK	SDK	Programmatic OpenAI-shaped agents
LangGraph	SDK	Graph-shaped multi-agent flows
OpenClaw	CLI	Autonomous loops with tool use

Anything that meets the adapter contract lands here. The pillar is open — we add good runtimes as they ship.

CLI vs SDK — what’s the difference?

	CLI coding agent	SDK
Example	`claude` (Claude Code), `pi-coding-agent`	`@anthropic-ai/claude-agent-sdk`, `openai-agents`
How you invoke	Spawn a subprocess; pipe a prompt; read streamed output	Import a library; call a function; await a response
Where state lives	Filesystem (sessions/, skills/, MCP servers)	In your process memory + your DB
Best for	Interactive sessions, long-running tasks, file-system work	Embedding agents inside your own product
LIFEOSAI’s use	Default for engineers working on cases	Used by orchestration internally to invoke runtimes

Both serve the same role: take a system prompt + tools + memory and run an agent session. The adapter pattern lets you mix them — one agent uses Claude Code, another uses an embedded Claude Agent SDK, a third uses Pi Coding Agent for OSS-model workloads.

The adapter contract

The orchestration substrate (LIFEOSAI’s agent-invoker) reads each agent’s adapterConfig.adapterType and dispatches to the right runtime:

type AdapterConfig = {
  adapterType: 'claude-code' | 'pi-coding-agent' | 'codex' | ...;
  model: string;              // claude-sonnet-4-6 · gpt-5 · etc.
  mcpServers: McpServer[];
  systemPrompt: string;
  workingDirectory: string;
  // ...
};

For non-Claude runtimes (e.g. Pi Coding Agent), the Event Normalizer in the Runtime Tier converts their streams to a unified SDKMessage shape so downstream code sees one event format.

What an agent actually is

An agent is NOT an LLM. An agent is:

an LLM (the brain — see LLM provider freedom)
- a coding agent / SDK (the runtime — this page)
- skills (markdown instructions for specific work patterns)
- tools (MCP servers — Gmail, Drive, ERP, your APIs)
- memory (files, sessions, filesystem workspace)
- a place in the org chart (reports to a manager, works in a project)

The runtime is one piece. The structure around it is what makes the agent useful for real work.