An agent harness is everything wrapped around a large language model that decides how it carries out a task: the loop that runs it, the context it sees, the tools it can call, and the memory it keeps between steps. A framework such as LangGraph or CrewAI is the toolkit a team uses to build a harness, and the agent is the live process that runs once the harness is assembled. When the tool list grows past a few hand-written functions, Paragon’s ActionKit supplies those tools as a managed catalog of actions with each end user’s authentication handled, over a REST API or the Paragon MCP server.
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.
