Guides
What Is an Agent Harness?
An agent harness is the loop, tools, context, and memory around an LLM that determines task performance. How it differs from a framework and an agent.
Garrett Scott
,
Head of Marketing
What Is an Agent Harness?
Take a team building an agent to triage internal IT tickets. They pick CrewAI to structure the code,
write a system prompt, wire up three tools — create a ticket, look up an asset, page the on-call
engineer — and give the agent a rolling memory of its last ten tickets. CrewAI is the framework. The
specific combination they assembled with it — that prompt, those three tools, that memory window,
tied together in one loop — is the agent harness. And the process running right now, triaging
ticket #4,391, is the agent.
Agent harness, agent framework, and agent get used interchangeably in practice, but they name three
different layers of the same system, and mixing them up is why two people can compare "agent
projects" and mean entirely different things — one comparing frameworks, the other comparing what a
team built with one.
Agent harness vs. agent framework vs. agent: what's the difference?
A harness is a specific, configured instance; a framework is the toolkit used to build one; an agent
is the running process that comes out the other end. In the IT-ticket example, CrewAI answers "what
was this built with," the prompt-plus-tools-plus-memory combination answers "what is this specific
system made of," and the live triage run on ticket #4,391 answers "what is it doing right now" —
three different questions, three different answers, one system.
The distinction holds regardless of which framework a team picks. A framework such as LangGraph or
CrewAI supplies reusable abstractions — a way to define steps, route between them, and manage state —
but it doesn't specify what any particular agent should do. A team uses that framework to assemble a
harness: a chosen model, a system prompt, a specific set of tools, a memory strategy, and a loop that
ties them together for one product's use case. Run that harness, and the agent is the live process
executing it. Two teams can use the identical framework and end up with harnesses that behave nothing
alike, because the framework only supplies the scaffolding.
Agent harness | Agent framework | Agent | |
|---|---|---|---|
What it is | A specific configuration of loop, context, tools, and memory | The software toolkit used to assemble that configuration | The running process executing the configuration |
Example | The IT-ticket harness: its prompt, its three tools, its ten-ticket memory window, tied together in one loop | CrewAI, LangGraph, or a hand-rolled agent loop | That harness running right now against ticket #4,391 |
Who controls it | The team building the specific product | The framework's maintainers | Whichever process or user invoked it |
A related term worth separating out is an agent skill — a packaged, reusable capability a harness can
load as a component, distinct from the harness itself. What qualifies as an agent
skill covers that distinction in more depth.
What are the components of an agent harness?
A harness is made of four working parts: a loop, context, tools, and memory. Changing any one of them
changes how the same underlying model performs the same task.
The loop is the control flow that lets the model act more than once before answering — call a
tool, read the result, decide whether to call another tool or respond. Without a loop, a model can
only produce one response from one prompt; with one, it can gather information and revise its own
plan mid-task. Anthropic's writing on building effective
agents is a useful primer on how
much of an agent's behavior traces back to this loop, not the model in isolation.
Context is the system prompt plus whatever working information the model currently has —
instructions on how to behave, the current conversation, and any retrieved facts relevant to the
task. A harness with the same tools but a vaguer system prompt will behave less predictably, even on
identical requests.
Tools are the functions the model can call to take action or fetch information outside its own
training data — searching a database, sending a message, running a calculation. A harness can wire
tools up by hand, following a schema like OpenAI's function-calling
format, or by connecting to an MCP server —
the Model Context Protocol, an open standard for exposing tools, prompts, and resources through one
common interface instead of a custom integration per tool. MCP is defined in more depth
here: in short, the protocol started out built for a
locally-running process and only picked up a remote HTTP option afterward. Both transports are in
active use today, and which one a harness's tools rely on changes where they execute and how the
harness authenticates to reach them.
Memory is the record the harness carries forward — earlier turns of a conversation, prior tool
results, or decisions made in an earlier step of a longer task. Some harnesses keep memory only for
the length of one session; others persist it across sessions so the agent doesn't start from zero
each time.
Components at a glance:
Loop — lets the model act, observe, and act again before answering
Context — the system prompt and working information the model currently has
Tools (including MCP) — the functions the model can call to take action or fetch information
Memory — what the harness carries forward from earlier turns or steps
Back to the IT-ticket harness: its loop lets it look up the reporting employee's asset before deciding
whether to escalate; its tools are the create-ticket, asset-lookup, and page-on-call functions; its
memory carries the last ten tickets forward so it doesn't ask the same employee to re-describe a
recurring problem. Swap any one part — a shorter memory window, a fourth tool, a vaguer prompt — and
the same underlying model handles the identical ticket differently.
Agent harnesses in practice
A harness's context and memory components don't have to stay static once real third-party data is
involved. Paragon's Managed Sync keeps a harness's retrieved context current
as source systems update — Salesforce records, Slack messages, files in Google Drive or Confluence —
without a team hand-building and re-running that ingestion pipeline itself.
The tools component doesn't have to be built from scratch either. Paragon's ActionKit is
a pre-built tool layer: a developer authenticates a user's third-party account once, the resulting
actions are exposed to the model as callable tools, and each call produces a log entry a team can
review or replay. Paragon's MCP server exposes the same actions over the open MCP standard for
harnesses built around remote tool calling. Paragon connects hundreds of integrations this way, backed
by SOC 2 Type II.
None of this replaces the model, the loop, or the judgment behind either — it's the tools and the
data-freshness layer arriving pre-wired, sitting inside the broader
integration-infrastructure layer agents run on. Teams
evaluating a tool layer for their own harness can read the ActionKit
docs directly.
When do you need a custom agent harness?
A single, unconfigured model call is enough when a task is narrow, one-shot, and needs no outside
information — summarize this paragraph, classify this sentence. A custom harness becomes worth
building once a task needs to call outside systems, needs more than one step to complete, or needs to
stay consistent across many runs. As those requirements increase, teams typically move from a default
agent setup to deliberately configuring the loop, tools, and context for their specific task, instead
of relying on whatever a general-purpose default provides.
How do you know a harness is working?
A harness's performance breaks down into four measurable parts. Tool correctness checks whether
the right tool got picked for the job. Tool usage checks whether it called that tool with
the right inputs — a well-chosen tool with malformed inputs still fails. Task completion checks
whether the final output actually satisfies the original request, typically judged by a human or a
second model comparing output to prompt. Task efficiency checks how much it cost to get there —
how many loop iterations, how many tokens. A team building test cases from real user prompts, running
them against a harness, and tracking these four numbers has a concrete way to tell whether a change to
the loop, a tool, or the system prompt made the agent better or worse.
FAQ
What is an agent harness? An agent harness is the combination of loop, context, tools, and memory
that surrounds a large language model and determines how it performs a task. It is distinct from an
agent framework, which is the software used to build a harness, and from an agent, which is the
running process that results.
How is an agent harness different from an agent framework? A framework — LangGraph or CrewAI, for
example — supplies reusable building blocks for defining steps and managing state. A harness is a
specific, configured instance built with those blocks: a chosen model, prompt, tool set, and memory
strategy for one task.
What is MCP and how does it relate to an agent harness? MCP, the Model Context Protocol, is the
open standard now behind more and more new tool integrations — a harness talks to one MCP server
instead of writing a bespoke connector per tool. It's one way to build the tools component, not a
requirement: hand-written functions still work, and a harness can mix both.
Do agent harnesses need a dedicated tool-integration layer? Not always — a small harness can call
a couple of hand-written functions directly. Once a harness needs many third-party tools kept current,
a pre-built layer like Paragon's ActionKit handles the per-user authentication and action catalog so
the tools component doesn't have to be maintained by hand.
In brief
Back to the IT-ticket team one more time. Swap CrewAI for a hand-rolled loop and nothing about the
harness itself changes — same prompt, same three tools, same ten-ticket memory, just a different
framework underneath. Cut the memory window to zero, though, and the identical framework and tools
produce a measurably worse harness, because the fourth component — memory — is gone. That is the whole
distinction in one system: the framework supplies the toolkit, the harness is the specific set of
choices a team made with it, and the agent is that harness running, right now, against whichever
ticket just came in.
