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. That minority gained a heavyweight three days later: deepseek-harness (2026-08-13) is TypeScript-first with Python as an SDK, and it arrived with more stars in one day than most of the thirteen have accumulated. One launch is not a trend, but the "TS is where the harnesses are, Python is where the frameworks are" split is now worth watching rather than assuming.
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. The specialization can also arrive as a separate component rather than a framework flavour: sayna is a Rust server that puts one WebSocket API in front of four STT/TTS vendors, so a framework gets a voice layer by mounting it instead of by being a voice framework.
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.

Google is in the censuses twice over and neither one counts it properly: adk appears in Turing Post's thirteen, but genkit — the lower-altitude library you embed in an app, which is the rung this ladder is actually about — is in neither list. Same shape as the DSPy case below, from the vendor side.

A third data point locates the seam (added 2026-08-20). dspy — 37.5k stars, 406 contributors, an ICLR 2024 paper, and a framework you build LM pipelines with by any plain reading — appears in neither count of this layer. Turing Post omits it; the toolkit carries it but files it under LLM Prompts, in a nine-entry category otherwise made of prompt compressors, while putting Guidance and LMQL in Structured Outputs again. Where the missing-in-one entries above were explained by the counter's vantage point, this one is explained by the sorting axis: both censuses sort by what you assemble — agents, chains, crews — and DSPy sorts by what you optimize. A compile step has no place in a taxonomy of assemblies, so it lands next to the compressors on the grounds that both touch the prompt. The peer-reviewed source disagrees with both: meaning-typed-programming benchmarks DSPy, LMQL and MTP as one comparable class.

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.

It can now say the layer is measurable, which is new (added 2026-08-21). agent-storage-footprint replays one identical trajectory through eight frameworks' persistence adapters and finds retained bytes differing 6.7×; across configurations that all score 100% on the same suite, 15.7× (LangGraph 5.10 MB against CrewAI 0.32 MB). A content-addressed store removes 4.8–32.7× of it with every restore check passing, so the spread is mostly duplication rather than eight teams pricing recovery differently.

Two caveats keep this from being the measurement above. Accuracy in that study is a control, pinned so storage can vary — so it compares frameworks to each other, never to writing the loop yourself. And its roster is another census with another author's vantage point: smolagents and Agno are in, dspy and the vendor SDKs are not, and nobody stated an inclusion rule there either.

What it does settle is that this category can carry a number at all. Across 108 SWE-bench Verified submissions, per-instance trajectory volume spans three orders of magnitude with no detectable correlation with resolve rate — measured on work people published for their own reasons, not in the authors' harness. Whatever the layer is doing, the benchmark everyone reports does not see it.

The nearest anyone has come is confucius-code-agent (Meta and Harvard), which ablates a harness on a real coding workload — one rung above this one, and still the only place in the corpus where somebody took the scaffolding apart to see which part carried the result.

dspy is the nearest thing to an exception and it does not close the hole. Its whole premise is a metric — you cannot run an optimizer without one (prompt-optimization) — so numbers exist here in a way they do not for the rest of the layer. But the number an optimizer reports is measured against its own seed prompt, not against a competent human writing the prompt by hand, and the corpus's one independent measurement of DSPy (meaning-typed-programming) tests the calling convention with the optimizer mostly switched off. The instrument is present; the comparison still isn't.

The boundary blurs from the other side

deepseek-harness is filed as a harness — it is a product you run, with a web UI — yet it is distributed as ~50 npm packages on a general-purpose plugin framework (cordis), and its own docs present the agent loop as a library row you can replace. Build a profile with only dsh-base and you are using it as a framework. The model → API → SDK → framework ladder assumes the layers ship separately; here one artifact occupies several rungs depending on which bundle you mount.

turingpost-13-frameworks · claude-agent-sdk · agentic-coding-harness · agent-orchestration · durable-agents · adk · langchain · a2a-protocol · deepseek-harness · cordis · dspy · prompt-optimization · llm-engineer-toolkit · meaning-typed-programming · genkit · sayna · confucius-code-agent · agent-storage-footprint