Agent Harnesses & Frameworks
Two very different things get called "agent tooling." Keep them separate:
(a) Harnesses are a finished agent loop you drive (a REPL/CLI that manages context, tools, permissions, and the model call). You configure and prompt it. You don't write the loop.
(b) Build frameworks are libraries you use to write your own agent/workflow in code (orchestration, state, tool-calling, memory).
(a) Harnesses you drive an agent through
| Harness | Best at | Watch out | Key fact |
|---|---|---|---|
| Claude Code | Long multi-step work across large codebases (plan → edit → run tests → commit); subagents, hooks, skills, MCP, permission modes; scriptable via the Claude Agent SDK | Runs commands and burns tokens; use permission modes and review | Anthropic's terminal-first harness, a de-facto reference implementation; included with Pro/Max or via API |
| OpenAI Codex | Delegating a task to run locally or hand off to the cloud, on OpenAI models; also inside ChatGPT Work | "Codex" spans a CLI, IDE extension, and cloud agent, so know which you're using | Open-source CLI; use with a ChatGPT plan or API |
| Pi | Being small enough to read end-to-end and bend to your own workflow; model-agnostic | A toolkit for building your own agent, not a batteries-included consumer app | Minimal, hackable terminal harness by Mario Zechner; open source, npm @mariozechner/pi-coding-agent (writeup) |
| OpenClaw | A self-hosted, pluggable, cross-platform assistant that can wrap external coding harnesses via ACP | Community project, so capabilities and stability vary; verify current state before depending on it | Open source (aka Clawdbot); GitHub |
| Amp | Team-shared, aggressive autonomous runs (also in Coding Tools & CLI Agents) | Token-metered; can get pricey on big runs | Sourcegraph's high-autonomy harness; usage-based |
Emerging interop standard: ACP (Agent Client Protocol), an open protocol from the Zed team (think "LSP for coding agents"), lets editors talk to any compliant agent harness, so Claude Code, Gemini CLI, and others can appear inside different front-ends. It's editor-to-agent, complementing MCP's agent-to-tool role (MCP & the Tool/Context Ecosystem).
(b) Build frameworks (roll your own agent)
| Framework | Language | Model | Best at | Note |
|---|---|---|---|---|
| LangGraph | Py/JS | Any | Stateful, graph-based agent workflows | From LangChain; production-oriented |
| LangChain | Py/JS | Any | Broad integrations, RAG glue | Large surface; some see it as heavy |
| LlamaIndex | Py/TS | Any | RAG / data-connected agents | Best-in-class retrieval |
| CrewAI | Python | Any | Role-based multi-agent "crews" | Simple mental model |
| AutoGen / AG2 | Python | Any | Multi-agent conversations | Microsoft origin; forked into AG2 |
| OpenAI Agents SDK | Py/JS | OpenAI-first | Lightweight handoffs + guardrails | Successor to Swarm |
| Claude Agent SDK | Py/TS | Claude | Production agents on the Claude Code engine | Same harness that powers Claude Code |
| Pydantic AI | Python | Any | Type-safe, validated agent I/O | Great DX for Python teams |
Links: LangChain/LangGraph · LlamaIndex · CrewAI · AutoGen / AG2 · OpenAI Agents SDK · Claude Agent SDK · Pydantic AI.
Framework vs. roll-your-own. For a single agent with a handful of tools, a plain provider SDK + a loop (or a thin harness) is often simpler and more debuggable than a framework. The model does the reasoning. You mostly need a good tool layer and context management. Reach for a framework when you need durable state, multi-agent coordination, human-in-the-loop checkpoints, or heavy retrieval, i.e., orchestration you'd otherwise reinvent. When in doubt, start minimal (many teams found frameworks added indirection they later removed).