How to choose an agentic harness for useful, accountable work
Choose the runtime around an AI model by testing recovery, tools, permissions, human approval and observability. Compare practical fit across the harnesses in our guide.
Define the job before the framework
An agentic harness is the surrounding execution system that turns model decisions into a working process. It may manage tools, state, context, permissions, retries and human intervention. The model is one component. A stronger model cannot by itself repair a missing approval step, a duplicated payment or a workflow that loses its state after an interruption.
Start with one complete task and a measurable outcome. Write down what the agent can read, what it can change and which decisions must remain with people. If the process follows a stable sequence, a conventional workflow with a small number of model calls may be simpler to operate. Anthropic's engineering guidance distinguishes predefined workflows from agents that choose their next actions.
Compare control and operational ownership
Our directory covers LangGraph, OpenAI Agents SDK, Claude Agent SDK, Microsoft Agent Framework and Google ADK. These are not interchangeable products, and capabilities can differ between language packages and releases. Treat the overview as a starting point and validate the exact version you plan to deploy.
LangGraph emphasises stateful orchestration, durable execution and human intervention. OpenAI Agents SDK provides an agent loop, tool integration, handoffs and tracing. Those capabilities are useful building blocks, but the application still needs authentication, deployment, retention rules and a recovery procedure. A hosted agent service and an SDK can allocate those responsibilities differently.
- Choose explicit workflow control when business rules and review gates dominate the task.
- Inspect tool permissions and the execution environment when an agent can run commands or change files.
- Check persistence and recovery when jobs span interruptions or human review.
- Ask which parts your team operates and which are operated by the service provider.
Test failure, not just the happy path
| Test | What a useful result looks like |
|---|---|
| A tool times out after performing an action | The system checks the result before repeating the action. |
| A worker denies an approval | The agent stops or follows an explicitly permitted alternative. |
| The process restarts halfway through | State is recovered and completed actions are not silently repeated. |
| A source document contains malicious instructions | Retrieved text remains untrusted data and cannot expand permissions. |
| The budget or time limit is reached | The run stops predictably and exposes what remains unfinished. |
Evaluate a representative set of tasks
Use examples from the real process, with sensitive data handled under your organisation's controls. Include incomplete requests, contradictory documents and edge cases. Measure task completion, correctness, human review time, failure recovery, latency and total cost per acceptable outcome. Keep the evaluation set separate from the examples used while developing the system.
Record both the model and harness versions. A change to prompts, tools, permissions or orchestration can affect outcomes even when the underlying model stays the same. Re-run the evaluation after material changes and keep a way to return to the previous configuration. Our model assessments describe trade-offs; they are not substitutes for this application-level evaluation.
Make a small, reversible choice
Select the simplest option that passes the important tests and that your team can support. Document the limits of autonomy and nominate someone who can stop a run. Start with a narrow workflow, inspect real traces and expand only when the evidence supports it. This is an editorial selection method, not a benchmark declaring one harness universally best.
Primary sources
Sources reviewed 21 September 2026. Product and software details can change; confirm the exact version and configuration.