I used to put almost everything under the same label: agentic system.
Then I started comparing coding agents like Claude Code and Codex with frameworks like LangGraph. They are all used to build agents, but they solve different problems.
The distinction that made it click for me was this:
That sounds small, but it changes how I think about agent architecture.
Start with the agent
At the center, there is still a model. Give it tools and let it decide what to do:
Conceptually, the loop is simple:
while not done:
action = model(context, tools)
result = execute(action)
context.add(result)The model acts, sees what happened, and decides what to do next. For a small agent, that might already be enough.
Something like Claude Code needs much more around that loop.
The harness helps the agent work
Imagine asking a coding agent:
Fix the authentication bug.
The model needs a way to inspect the codebase, search files, edit code, run tests, execute commands, and see what happened. That surrounding system is the agent harness. It often bundles the loop with the context, instructions, tools, and permissions that let the agent work.
The harness gives the model an environment it can actually work inside.
Inside a dynamic coding-agent run, the model usually decides the path. One task might be:
Another might be:
You cannot always predict that path beforehand. That is why coding agents are very harness-shaped: the harness provides capabilities, while the model decides how to use them.
The runtime coordinates the process
Now imagine the agent is only one part of a larger product. Maybe you are building an incident-response system:
The question is no longer just, "How does the agent inspect logs?"
It is, "How does the whole process move from one stage to another?"
That is where the agent runtime comes in.
The harness helps the agent perform work. The runtime helps the application coordinate work.
State and checkpoints
Suppose a workflow looks like this:
Then the server restarts while the workflow is waiting for approval.
Now the system needs to know what already completed, what state to restore, whether previous steps should run again, and where to continue after the human responds.
That is bigger than tool calling. It is an execution lifecycle problem.
Routing
Some paths should belong to the application, not the model.
Or the application may classify a request and send it to a specialized agent:
This is runtime territory because the application owns meaningful parts of the path instead of handing every decision to one model.
Human interaction
An agent modifying production infrastructure should probably not go straight from proposal to execution.
Pausing, persisting state, waiting, and resuming later are runtime concerns.
Where LangGraph fits
LangGraph is one example of an agent runtime. It provides primitives for state, nodes, routing, checkpointing, persistence, and human-in-the-loop execution.
So instead of thinking, "LangGraph is how you build agents," I find this more accurate:
LangGraph is one way to run and orchestrate stateful agentic workflows.
The agent inside that workflow can still have its own harness.
They can live together
Harnesses and runtimes are not alternatives. A system can use both.
Imagine an automated software-engineering workflow:
There are two loops here.
Inside the coding agent:
The harness supports that loop.
Outside the coding agent:
The runtime supports that process.
Once I separated those two levels, these architectures became much easier to reason about.
When a runtime is worth it
Not every agent needs a runtime.
A research agent might only need a model, search and reading tools, and a solid agent loop:
Adding a full orchestration runtime could create more state and infrastructure than the product needs.
A runtime starts earning its place when the system itself becomes stateful:
- long-running work
- multiple stages or agents
- retries and branching
- human approval
- pause and resume
- persistent state
- background execution
Two questions
I now ask two separate questions.
What does the agent need to do its job?
Maybe files, a shell, browser access, APIs, search, memory, MCP, permissions, or context management.
That is a harness question.
What does the system need to manage the agent?
Maybe state, retries, routing, checkpoints, approvals, multiple agents, long-running jobs, or recovery after failure.
That is a runtime question.
The full picture
One possible composition looks like this:
The harness is about agency. It gives the model enough context, tools, permissions, and feedback to figure out how to accomplish something.
The runtime is about execution. It gives the larger process control, persistence, routing, and resume semantics. Observability usually comes from a separate tracing layer.
So before adding something like LangGraph, I would not ask:
Am I building an agent?
I would ask:
Do I have a runtime problem yet?
If the model mainly needs to explore, use tools, and figure things out, build the harness well. If the application needs to coordinate a larger stateful process around that agent, that is when an agent runtime starts to make sense.