Key takeaways
- Open-source choices include Deep Agents, which is presented as an MIT-licensed harness for long-running workflows.
- A feature list shows capability, not what a tool will do to your work.
- Score the options, then use a real task to confirm fit.
An open source agent harness is not just a longer menu of tools. It determines how work moves, what survives between runs, where your judgment enters the loop, and what happens after a failure. That operating model matters more than a repository label. The practical choice begins with the work you want to delegate and the consequences of a wrong turn.
What does an agent harness control?
An agent harness is runtime scaffolding that turns a language model into an agent capable of performing work. The model may generate the next response or action, but the harness drives the model and tool calls around it. That is where a sequence of isolated calls becomes an operating loop.
The harness also manages conversation state and context. Those responsibilities decide what the agent can carry from one step to another. Without that layer, each model call is only as useful as the history and working material supplied with it.
Control enters at the same layer. A harness can apply approval policies, which gives the system a place to pause before an action that needs a decision. It can also keep an agent progressing through a multi-step task. Together, these responsibilities make the harness part runtime, part memory boundary, and part control surface.
This definition helps separate a harness from a model or a collection of tools. A model produces outputs. Tools expose actions. The harness drives those calls, manages state and context, applies approval policies, and keeps the work moving. When you compare candidates, inspect those four responsibilities as a connected system. A strong tool catalog cannot answer whether the surrounding loop preserves the context or control your workload needs.
For a broader view of how these systems are packaged, our guide to AI agent frameworks maps the wider landscape. Here, the narrower question is which harness role matches your work.
Are there any open-source agent harnesses available?
Yes. Open-source choices are available, but they do not all occupy the same role. A useful comparison starts by keeping those roles visible:
- LangGraph is presented as an MIT-licensed agent runtime for complex agents that require precision.
- Deep Agents is presented as an MIT-licensed agent harness for long-running workflows.
- CrewAI is presented as an MIT-licensed multi-agent orchestration framework for rapid prototyping of role-based agent workflows.
- The OpenAI Agents SDK is presented as an MIT-licensed multi-agent workflow SDK for tightly scoped assistants and delegation workflows.
Those descriptions establish that open-source options exist across runtimes, harnesses, orchestration frameworks, and workflow software development kits. They do not make the four projects interchangeable, and they do not produce a universal winner. Each label points to a different starting role.
Discovery resources can help you widen the candidate set. One curated public GitHub directory covers agent harnesses, agent frameworks, workflow frameworks, and emerging agent protocols. Use a directory to find projects, then bring each candidate back to the operating questions below. A long list is useful at the discovery stage. It does not tell you how a candidate behaves when the work runs long, requires an approval, or needs to recover.
How should you choose the best open source agent harness?
Choose the best open source agent harness for your workload by scoring three things: context load, control surface, and reversibility. A feature list shows what a tool can do, but not what it does to your work. These axes expose the commitment behind the features.
| Axis | Question | What the answer reveals |
|---|---|---|
| Context load | How much setup and shared context must be loaded before execution? | High context load can buy shared understanding while increasing the time before the agent writes code. |
| Control surface | How much of your judgment stays active after work begins? | The degree to which the harness carries your judgment forward, including whether user decisions remain in the loop when a wrong turn is expensive. |
| Reversibility | How easily can the resulting change be backed out? | How much recovery room you retain after the agent acts. |
How much orchestration do you want to build yourself?
Decide how much of the operating loop you want to own. With a custom API implementation, loops and branching remain the developer's responsibility, while the Agents SDK provides the agent loop and lifecycle. The same split appears in coordination: a custom implementation requires the developer to build routing and delegation, while the SDK supplies agents-as-tools and handoffs.
That is a real architecture choice, not a feature-count contest. Custom work puts the loop, branches, routing, and delegation in your code. The SDK supplies an existing lifecycle and coordination mechanisms. Your scorecard should reflect the work you actually want to build and maintain.
Our note on the five levers inside an agent harness develops the surrounding design vocabulary.
This choice also shapes what you must inspect next. Once a harness owns more of the loop, its state and approval model become part of your system's behavior. A custom API implementation leaves loops, branching, routing, and delegation to the developer.
Can the harness preserve state and approval boundaries?
For long-running work, look for state that can survive interruption and approval flows that can resume. The Agents SDK adds sessions and resumable run state to options that include manual history, response chaining, or Conversations. It also provides input, output, and tool guardrails plus resumable approval flows. A custom API implementation provides tool-specific approvals but leaves broader controls to the developer.
The larger requirement appears when work outlives one context window or execution environment. A long-running AI agent can operate across multiple context windows and sandboxes, recover from failure, leave structured artifacts, and resume where it stopped. State, sessions, and structured handoffs account for much of the gap between a chat window and an agent that can be left running overnight.
Those mechanisms answer different operational questions. Sessions and resumable state preserve the run. Structured artifacts leave material that another run can pick up. Approval flows preserve a decision boundary without forcing the entire task to restart. When a candidate says it supports long-running work, inspect whether these parts exist in the implementation mode you plan to use.
Do not stop at a resume button in a demo. The long-running boundary includes multiple context windows and sandboxes, recovery after failure, structured artifacts, and resumption from the stopping point. Check those behaviors together. A run that preserves its conversation but loses the working artifact has not demonstrated the full long-running behavior described here. The same is true when an approval pauses work but cannot resume the run afterward.
Human checkpoints are also a deliberate design choice that can make agents safer and more reliable in production. They are most useful as real boundaries in the workflow, with a defined pause and a resumable path. A prompt that merely asks the model to be careful is not the approval mechanism described here.
Can you inspect and recover the real failure?
A successful request does not prove that a workflow completed correctly. Long-running recovery needs controls that observe workflow state and side effects because transport-level success signals can miss them. Observability belongs in the design from the start because a long-running black-box failure cannot be debugged effectively.
Tracing is one part of that control surface. The Agents SDK provides built-in traces across model calls, tools, agents, guardrails, and handoffs. A custom API implementation exposes response objects and API logs. The useful question is whether the available record follows the workflow far enough to show where its behavior changed.
Inspect the record at the same level as the failure. Model-call history can show what the model produced. Tool and agent traces can expose where execution moved. Guardrail and handoff traces can show the control path. Workflow state and side effects remain necessary because transport-level success can miss them. That wider view is what makes recovery a harness question instead of a request-log question.
Writes create a separate recovery problem. In write-heavy workflows, retrying without a record of prior execution can duplicate a partially completed mutation. Mutation operations should use idempotency keys and should not be retried naively. That turns retry behavior into an explicit part of harness selection. Inspect how a candidate records prior execution and protects a repeated mutation.
Budget failures may be invisible for a different reason. Internal replanning and retries can consume unbounded budget without appearing in infrastructure monitors, so reasoning loops need workflow-level limits. Those limits must sit where the harness can see the loop, not only the transport around it.
Traces, mutation records, idempotency keys, and workflow limits protect different boundaries. Together, they show whether a candidate gives you enough evidence to locate a failure and enough control to recover without repeating harmful work.
Our agent evaluation glossary defines another part of that inspection vocabulary.
Failures need different recovery paths
Recovery should match the kind of failure. A harness that sends every error through the same retry path can repeat a bad approach, stall on a blocker, or continue after the goal itself has failed.
- Transient errors: Network blips and temporary rate limits can be retried automatically.
- Recoverable errors: An incorrect input format or unexpected tool data calls for adjusting the approach before retrying.
- Blocking errors: Replan around the blocker when possible. Otherwise, escalate it.
- Fatal errors: An impossible goal or incorrect core assumptions should be surfaced to a human, and the run should stop.
This compact taxonomy gives recovery logic a concrete shape. Automatic retry belongs to transient errors. A recoverable error needs a changed approach before another attempt. A blocking error needs a route around the obstacle or escalation. A fatal error ends the run and surfaces the problem to a person.
When you inspect a candidate, look past the presence of a retry setting. The stronger question is whether its workflow can distinguish these paths and preserve enough state to take the appropriate one. That connects recovery policy to the state, observation, and approval controls already in the harness.
Costs depend on usage and project upkeep
Open source does not remove operating cost. For a long-running agent, cost depends heavily on the model, number of tool calls, and duration. The referenced Agents SDK capabilities use standard API pricing based on tokens and tool use. The license category and the cost of running the workload are separate parts of the decision.
Project upkeep matters too. Open-source project staffing should include a team member committed to community interactions, pull-request merging, feedback, and releases. Those four responsibilities give you a practical maintenance check. Inspect whether a candidate project has visible ownership of the work required to keep changes moving.
Your evaluation should therefore include both the workload's usage pattern and the project's upkeep. Estimate around the model, tool-call count, and duration your real task creates. Then inspect the maintenance activity that supports community interaction, merges, feedback, and releases. Neither a license label nor a repository feature list settles those costs.
How should you test a candidate harness?
Start with the simplest architecture that works for the use case. Add multi-agent operation, vector memory, or dynamic replanning only when the problems they solve arise. The scorecard identifies what to weigh, but only a real task can confirm fit.
Use a task that exercises the boundary you care about. One concrete staged pattern uses a Plan agent that researches the task and creates a plan without changing code. After plan review, the selected implementation agent receives that plan and the conversation context before implementation begins. The pattern lets you inspect a no-code-change planning boundary, the review point, and the handoff into execution.
Run that real task through the candidate and watch the operating consequences. Measure the context you must load before work starts. Observe which decisions remain active after execution begins. Test whether you can back out the resulting change. Then interrupt the run, resume it, inspect the trace, and exercise the relevant recovery path.
Keep the candidate that fits the task with the least unnecessary architecture. If you still need to compare its role with the surrounding ecosystem, use our AI agent framework landscape. Then make the adoption decision from the real run, not the repository label.