Stop Calling Everything an Agent Framework

1Runtime vs framework vs harness, using LangGraph, LangChain, and Deep Agents to make the stack click…

2Fair warning: this is a slightly longer read. But if you clicked on it, you probably either want to clear the fog around runtimes, frameworks, and harnesses, or you already work with these systems and want to pressure-test the mental model you’ve been using.

3Also, this isn’t some AI-slop write-up. I’ve been working on production agentic systems for academia, and a lot of this comes from the things I’ve had to learn, build, break, and explore along the way. Call it roughly 70% me, 30% AI-assisted polishing 🤠.

4Agent engineering has a naming problem.

5We call almost everything between an LLM API and a product an agent framework.

6That was mostly harmless when an “agent” meant a model, a few tools, and a loop. It gets confusing now that agents can run for minutes or hours, pause for approval, write files, spawn subagents, recover from failures, remember things across sessions, and carry a task across multiple context windows.

7At that point, “framework” is doing far too much work as a word.

8A cleaner mental model is starting to emerge:

A runtime keeps the work alive. A framework makes the agent programmable. A harness makes the model effective at the work.

9LangChain’s own stack is a useful way to see this separation:

• LangGraph is runtime-first.
• LangChain is framework-first.
• Deep Agents is harness-first.

10The important word there is first. These boundaries are not laws of physics. LangGraph is also a framework. LangChain already includes a minimal harness. Deep Agents obviously contains framework-like abstractions. Harrison Chase has explicitly called the terminology “murky” and overlapping. 1

11Still, the distinction is useful because each layer answers a different engineering question.

Start with one agent, not three definitions

12Suppose you are building a research agent.

13The user gives it a task that sounds simple:

Research whether cultivated meat can realistically reach price parity with conventional beef. Compare the evidence, run the numbers, make charts, and give me a report.

14The model starts working.

15It searches. It reads papers. It saves notes. It runs some Python. It realizes one assumption is weak and searches again. It delegates environmental analysis to another worker. Halfway through, it needs approval before using an expensive data source. Seventeen minutes in, a process dies.

16Now ask three different questions.

1. Can the task resume without starting over? That is a runtime question.
2. How did we define the model/tool loop, middleware, tools, and state transitions? That is a framework question.
3. Why did the model know to make a plan, keep bulky results in files, delegate a subtask, and avoid stuffing everything back into its context window? That is a harness question.

17Same agent. Three layers of responsibility.

18That is the distinction worth remembering.

Runtime: can the work survive reality?

19The easiest way to understand a runtime is to stop thinking about intelligence for a moment.

20Imagine the model is already smart enough.

21Production still has ugly questions:

22What if the worker crashes?

23What if the agent has to wait six hours for a person to approve something?

24What if you deploy new code while twenty runs are active?

25What if the task branches into parallel work?

26What state needs to survive between steps?

27What happens when an API fails halfway through a node?

28This is runtime territory.

29LangGraph is a clean example because its core abstractions are built around state and execution. You describe work as nodes connected through transitions, and the runtime can checkpoint state at boundaries, pause on an interrupt, retry work, and later resume from persisted state. 2

30A simplified workflow might look like this:

31The important part is not the boxes.

32It is that human_approval can be a real pause, not a theatrical prompt saying “please come back later.” The graph state can be checkpointed, the process can disappear, and execution can resume when input arrives. LangGraph’s documentation shows exactly this pattern with interrupt() plus a checkpointer, including runs that resume days later.

33That gives us a useful one-line definition:

The runtime owns the lifecycle of the work.

34It does not primarily make the agent clever. It makes the agent’s execution dependable enough to exist outside a demo.

35A good runtime gives you boring superpowers

36Boring is a compliment here.

37A strong runtime gives you things such as durable execution, persistence, retry behavior, streaming, concurrency control, interrupts, resumability, and observability.

38Those features rarely make a flashy demo.

39You notice them the first time a 25-minute agent run fails at minute 24.

40Without a runtime, “long-running agent” often means “a Python process we hope stays alive.”

41With one, the process becomes replaceable. The run is the durable thing.

Framework: how do I express the agent I want?

42Now move one layer up.

43Even with durable execution underneath, you probably do not want to hand-write the same plumbing for every agent:

• model invocation
• tool schemas
• message conversion
• structured output
• model/tool loops
• provider integrations
• middleware hooks
• state updates

44A framework gives you a programming model for those pieces.

45This is where LangChain fits well.

46The current LangChain agent abstraction is intentionally small: a model runs in a loop, decides when to call tools, receives the results, and continues until it can answer. Middleware lets you intercept and modify that loop without rebuilding the whole thing. 3

47Conceptually:

agent = create_agent(
    model=model_name,
    tools=[search, read_document, run_python],
    middleware=[summarize_context, require_approval]
)

48Do not get hung up on the API. The useful idea is where the abstraction sits.

49Instead of writing:

call model → parse tool request → execute tool → serialize result → append messages → call model again → handle error → repeat

50you work with concepts such as agent, tool, message, middleware, and model.

51That is what frameworks are good at: giving repeated engineering patterns a vocabulary.

52A good framework removes enough boilerplate that you can focus on your application, while still letting you reach underneath when the abstraction stops fitting.

53And that second part matters.

54Anthropic’s long-standing advice is still useful here: frameworks accelerate common work, but too many layers can hide the prompts and responses that actually determine behavior. Their recommendation is not “never use frameworks.” It is to understand what sits underneath the abstraction and add complexity only when it earns its place. 4

55So:

The framework owns the developer-facing building blocks of the agent.

56It answers: How do I compose this system without writing every low-level interaction myself?

Harness: what kind of world are you putting the model inside?

57This is the newer, and more interesting, layer.

58Take the same model twice.

59In system A, give it:

- 40 vaguely named tools
- a giant conversation history
- no workspace
- no plan
- no way to delegate
- no strategy for oversized tool outputs
- one massive system prompt explaining everything

60In system B, give it:

- a small, legible toolset
- a filesystem for intermediate work
- planning support
- skills loaded only when relevant
- subagents for isolated work
- automatic context compression
- clear approval boundaries
- good feedback after every action

61The underlying model can be identical.

62The resulting agent will not feel identical.

63That surrounding system is what people increasingly mean by an agent harness.

64A harness is more opinionated than a general framework. It does not just give you primitives and ask what you want to build. It arrives with ideas about how a capable agent should work.

65Deep Agents is a good example.

66Its default setup includes planning, filesystem tools, subagent spawning, skills, memory, context management, human-in-the-loop support, and prompts that teach the model how to use those capabilities. 5

67The filesystem part is especially revealing.

68A naive long-running agent treats the context window like RAM, disk, notebook, and event log at the same time. Every search result gets appended. Every intermediate thought competes with every future instruction. Eventually the model is reading an increasingly expensive pile of history just to figure out what matters now.

69A harness can change that operating model.

70Large information can move to files. The model can read only the relevant slice later. A specialized subagent can investigate one branch without polluting the parent agent’s context. Old conversation history can be summarized. A skill can stay on disk until the task actually needs it.

71That is not merely prompt engineering.

72It is context engineering: deciding what enters the model’s limited working context, when, and in what form. Anthropic describes context engineering in almost exactly those terms: curating the evolving set of instructions, tools, external data, and message history that reaches the model during inference. 6

73LangChain’s 2026 description of Deep Agents makes the same point even more directly: the job of a harness is to get the right context to the model at the right time. 7

74So:

The harness owns the model’s operating environment.

75Not the compute environment in the Docker/Kubernetes sense. The cognitive environment: tools, instructions, working files, delegation patterns, context policy, memory policy, and the feedback loop around actions.

76This also explains why coding agents made the term “harness” much easier to see.

77OpenAI describes Codex as a harness containing the agent loop, thread lifecycle, persistence, configuration, authentication, tool execution, MCP integrations, skills, and approval flows.8 Separately, it describes the environment as the place where commands actually execute and files live.9

78That distinction is useful:

A sandbox gives the agent a computer. A harness teaches the agent how to operate through it.

The part that usually causes confusion: the layers overlap

79Here is where neat diagrams can lie to you.

80Memory exists in the runtime and the harness.

81Human approval exists in the runtime and the harness.

82Files can belong to the environment and the harness.

83Retries can be implemented by the runtime, middleware, or application code.

84So how do you know which layer owns what?

85The trick is to ask what responsibility is being solved.

86Memory is a good example here:

87A runtime may persist a checkpoint containing:

{
  "task": "compare five papers",
  "completed": ["search", "extract"],
  "next_step": "synthesis",
  "artifacts": ["notes.md"]
}

88That is execution memory. It answers:

89Can the run continue correctly?

90The harness may look at everything available and decide:

For the next model call:
- include the current plan
- include the last two tool results
- summarize the previous 40 messages
- keep raw paper extracts in notes.md
- expose the citation skill because synthesis is next

91That is context management. It answers:

92What should the model know right now?

93Same broad word: memory.

94Very different responsibility.

95Human-in-the-loop works the same way

96The runtime gives you the primitive:

interrupt → persist → wait → resume

97The harness or application policy decides:

Ask for approval before:
- sending email
- spending > $5
- deleting a file
- publishing an artifact

98One provides the mechanism.

99The other decides how the model should use it.

100This distinction becomes extremely useful when you are designing your own agent stack because it tells you where a feature belongs.

101Do not put “resume after process crash” into a giant system prompt.

102Do not make your orchestration engine decide whether financial-analysis/SKILL.md should enter the next model context.

103Different layer. Different job.

So what is Deep Agents actually adding on top of LangChain?

104This is the fastest way to make the whole stack click.

105LangChain already gives you an agent loop.

106Deep Agents is not replacing that loop with some mysterious new form of intelligence.

107It is adding a set of opinionated behaviors around it.

108LangChain itself describes Deep Agents as essentially its core agent plus a collection of middleware and context-management defaults.

109That includes things such as:

• a planning/todo mechanism
• filesystem access
• subagent delegation
• skills
• memory
• context summarization and offloading
• default instructions for using all of the above

110And underneath that, LangChain’s agent abstraction runs on LangGraph.[7:2]

111So the stack is roughly:

112That does not mean every agent stack in the world must have exactly these three packages.

113It means these three projects happen to expose three architectural responsibilities unusually clearly.

114You can build your own harness on LangChain.

115You can use LangGraph directly and skip LangChain’s agent abstraction.

116You can build a harness from raw model APIs and Temporal.

117You can use a managed harness where much of this is hidden behind an API.

118The names matter less than knowing which responsibilities you have chosen to own.

Which layer should you start from?

119There is no universal answer, but there is a useful decision rule.

120If the workflow itself is the product logic, start lower.

121A compliance process with fixed gates, a financial approval workflow, or a support system with strict routing may benefit from LangGraph-style explicit control. You want to know where the system can go next, what gets persisted, and exactly where a human can intervene.

122If the agent loop is normal but the application is custom, a framework is often the sweet spot.

123Maybe the agent needs your retrieval stack, your tools, your auth model, and two pieces of custom middleware. You do not need a built-in planner, filesystem, or swarm of subagents just because they exist.

124If the work is open-ended and long-horizon, a harness starts earning its weight.

125Research, coding, data analysis, complex document production, investigation, and other tasks where the model has to decide how to make progress benefit from planning, files, delegation, skills, and deliberate context management.

126And yes, real systems mix them.

127You might have a deterministic LangGraph workflow whose “research” node invokes a Deep Agent. Or a Deep Agent whose sensitive tool calls ultimately trigger runtime-level interrupts. These layers compose because they solve different problems.

128The wrong question is:

Which one wins: LangGraph, LangChain, or Deep Agents?

129The better question is:

At which layer does my application need to be opinionated?

130If you need to own every state transition, work close to the runtime.

131If you need to own the agent composition, work at the framework.

132If you mostly want to own the domain while inheriting a strong general-purpose operating model, start from a harness.

133That is normal for a stack this young.

134What matters is not winning the terminology argument.

135It is knowing what you are buying, what you are abstracting away, and what you still own when your “agent framework” becomes a production system.

Refs :))

1. Harrison Chase, “Agent Frameworks, Runtimes, and Harnesses — oh my!”, LangChain, October 25, 2025. https://www.langchain.com/blog/agent-frameworks-runtimes-and-harnesses-oh-my ↩
2. LangChain, “Thinking in LangGraph.” https://docs.langchain.com/oss/javascript/langgraph/thinking-in-langgraph ↩
3. Sydney Runkle, “Deep Agents vs LangChain vs LangGraph,” LangChain, August 6, 2026. https://www.langchain.com/blog/deep-agents-vs-langchain-vs-langgraph ↩
4. Anthropic, “Building Effective Agents,” December 19, 2024. https://www.anthropic.com/engineering/building-effective-agents ↩
5. LangChain, “Deep Agents overview.” https://docs.langchain.com/oss/javascript/deepagents/overview ↩
6. Anthropic, “Effective Context Engineering for AI Agents.” https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ↩
7. OpenAI, “Unlocking the Codex Harness: How We Built the App Server,” February 4, 2026. https://openai.com/index/unlocking-the-codex-harness/ ↩
8. OpenAI, “Architecture: Understand the Harness, Environment, and Application Server.” https://developers.openai.com/api/docs/guides/agents-api/architecture ↩
9. Anthropic, “Effective Harnesses for Long-Running Agents,” November 26, 2025. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents ↩