Agent framework

The library layer you build an agent with: orchestration, memory, tool invocation, workflow and multi-agent coordination, supplied as code you import rather than as a product you run. Distinct from the harness, which is a finished agent someone else assembled and you operate.

Paged 2026-08-10, when turingpost-13-frameworks surveyed thirteen of them. Until then this spoke covered the layer only where a specific entry forced it — adk, langchain — and never as a class.

Where it sits

The common framing is a ladder of how much arrives pre-built: model → API → SDK → framework. An SDK hands you a toolbox; a framework adds the loop, the state and the coordination between agents.

Do not confuse it with Anthropic’s ladder in claude-agent-sdk — Client SDK → Agent SDK → Managed Agents — which sorts by who executes the loop and whose machine it runs on. Both call the middle rung an SDK. They are measuring different things, and the ambiguity is live in the vocabulary rather than something either source invented.

The axes that separate them

turingpost-13-frameworks‘s five, which are the corpus’s first stated comparison scheme for this layer:

• Language. Python is near-universal (12 of 13 in that survey); TypeScript is a minority and TS-native is a single entry.
• Abstraction level. From a minimal runtime that mostly gets out of the way (smolagents, whose CodeAgent writes Python and runs it sandboxed) to a full platform with storage, scheduling and access control (Agno) — and the more a framework supplies, the more of your architecture it decides.
• Specialization. Voice and telephony, RAG and documents, research simulation, enterprise coordination. General-purpose is no longer the only shape.
• Production posture. Type safety, durability, checkpointing — the properties that matter once an agent runs longer than a demo (durable-agents).
• Multi-agent support. Handoffs, crews, A2A — agent-orchestration as a framework feature rather than something you assemble.

The category has no agreed membership

Two censuses landed a day apart and do not describe the same set. turingpost-13-frameworks lists 13; llm-engineer-toolkit lists 27 under Agents. Seven are on both (CrewAI, LangGraph, Agno, OpenAI Agents SDK, smolagents, Pydantic AI, CAMEL).

What each one misses is patterned. Turing Post has the vendor SDKs (ADK, Microsoft Agent Framework, Strands) and the non-Python entries (Mastra, LiveKit) that the toolkit lacks; the toolkit has an entire community stratum (AutoGen, Swarms, Composio, Browser Use, AgentOps, Langroid, AgentStack…) that Turing Post lacks. Neither states an inclusion rule.

So “agent framework” is a category with a contested boundary, and any count of it is a statement about the counter. Treat a census here as evidence of what its author was looking at.

What the corpus can and cannot say

It can say the layer is crowded, Python-shaped, and specializing. All three are visible in the censuses, and the second one strengthens the first two: 27 agent libraries where the survey found 13, and essentially all of the extras are Python.

It cannot say whether any of them helps. No source here measures a framework against building directly on an API, and the surveys that catalogue them grade on ergonomics and community size. That is the same hole this spoke keeps finding one layer up, where cc-thinking-skills and context-files-ablation-paper did run controls and found process effects without correctness effects. Nobody has run that experiment on frameworks.

Related

turingpost-13-frameworks · claude-agent-sdk · agentic-coding-harness · agent-orchestration · durable-agents · adk · langchain · a2a-protocol