TL;DR: The most popular AI agent harnesses in 2026 were built for coding: Claude Agent SDK, Codex, Goose, Pi, and Deep Agents. A customer conversation needs a different environment. Myna is that harness: turn-taking, business tools, policy, persona, channels, and a reply that only claims what the tools actually did.
What Are the Most Popular AI Agent Harnesses?
If you search for the best or most popular AI agent harnesses right now, you will notice something pretty quickly.
Almost all of them were built around coding.
Claude Code. Codex. Pi. Goose. OpenCode. Cursor.
That is not an accident.
Software development was one of the first environments where agent harnesses became obviously useful. A coding agent needs access to files, a terminal, tools, context, permissions, tests, and a loop that lets it keep working until the task is finished.
A model on its own cannot do that.
The harness gives it the environment. What an agent harness is, in short: the runtime around the model.
But coding is only one kind of agentic work.
A customer-facing conversational agent has an entirely different set of problems. It needs to maintain a conversation over time, retrieve customer and business context, call business tools safely, follow policy, preserve a persona, handle interruptions, adapt to different messaging channels, and produce customer-facing language without exposing the machinery underneath.
That is the category we are building Myna around.
So rather than pretending every agent harness is interchangeable, it makes more sense to look at the major harnesses by what they were actually designed to do.
Claude Agent SDK
Claude Agent SDK is probably one of the clearest examples of a modern, batteries-included agent harness.
It is the same underlying harness used by Claude Code. Anthropic exposes the SDK so developers can use the same core infrastructure to create agents for applications beyond software development. Anthropic describes it as providing the context management, tools, and permissions systems behind Claude Code, along with capabilities such as subagents and hooks.[1]
What Claude Agent SDK is good at
Claude’s harness grew out of a demanding environment: giving an AI model meaningful autonomy inside a developer’s computer.
That requires a lot more than sending prompts to Claude.
The harness manages things like:
- Context
- File access
- Tool execution
- Permissions
- Hooks
- Subagents
- Background tasks
- Long-running work
Claude Code is particularly good at being dropped into a project, exploring it, deciding what needs to change, modifying files, running tools, and iterating.
Anthropic has since expanded that same infrastructure into the more general Claude Agent SDK.
Where Claude fits
Claude Agent SDK makes sense when you are a developer building an agent that needs significant autonomy over a working environment.
Coding remains its most obvious use case, but Anthropic explicitly positions the SDK as infrastructure for agents outside coding as well.[1]
The tradeoff is that you are building on a fairly opinionated Anthropic agent stack.
If what you actually want is a customer service representative communicating across SMS, WhatsApp, and email, there is still considerable application infrastructure you would need to build around it.
OpenAI Codex
Codex is OpenAI’s answer to the same broad problem.
Most people know Codex as a coding agent through its CLI, IDE integrations, or desktop experience, but OpenAI now explicitly describes its underlying system as an open agent harness.
The harness handles context gathering, reasoning, tool use, approvals, execution boundaries, and carrying work forward across an agent session.[2]
What makes Codex interesting
Codex has invested heavily in something every serious harness eventually has to deal with.
The model should not automatically be trusted with everything it wants to do.
Its sandbox defines where an agent can operate, while approval policies determine what happens when it tries to move outside those boundaries. OpenAI also uses agent-native logging and configurable network restrictions around execution.[2]
This is harness engineering in a very literal sense.
The model reasons.
The harness decides where that reasoning is allowed to become action.
Codex is becoming more than a coding UI
OpenAI has started exposing the Codex harness as a platform rather than restricting it to its own coding interfaces.
That means developers can potentially embed its agent infrastructure into specialized applications instead of forcing the user into a generic coding assistant.[2]
It is still heavily shaped by the coding-agent problem, however.
Files, shells, sandboxes, and software execution are first-class concepts.
For a coding agent, that is exactly what you want.
For a conversational customer-facing agent, the dominant abstractions are different.
Goose
Goose takes a different approach.
It is an open-source, general-purpose agent originally created by Block and now part of the Agentic AI Foundation under the Linux Foundation.
Unlike some model-specific harnesses, Goose is explicitly model-agnostic.
Its current documentation lists support for numerous model providers including Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, and Bedrock.[3]
Why developers like Goose
Control is probably Goose’s biggest appeal.
You can run it locally and connect your own models and extensions instead of committing your entire agent architecture to one provider.
It also has a particularly strong implementation of MCP, with dozens of extensions for connecting the agent to external systems.[3] Myna uses that same protocol so business tools are contracts the runtime can call, not paragraphs in a prompt.
Goose also supports something it calls Recipes.
These are reusable YAML configurations that can describe agent workflows, instructions, extensions, and parameters.
That makes it possible for a team to package up a repeatable agentic task rather than repeatedly giving an AI the same prompts.
Goose’s place in the market
Goose has become one of the more interesting options for people who want an open agent harness with a relatively broad scope.
Its official site currently reports more than 45,000 GitHub stars and more than 500 contributors, so this is not a tiny experimental project anymore.[3]
But its core operating environment still looks a lot like the world most general-purpose harnesses came from: tools, machines, files, workflows, and tasks.
That is different from building an agent whose primary environment is an ongoing conversation with a customer.
Pi
Pi sits almost at the opposite end of the spectrum from a massive batteries-included harness.
Its own description is refreshingly direct: it is a minimal agent harness.[4]
The philosophy is that the harness should not decide everything for you.
Instead, Pi gives developers a small foundation they can customize through extensions, skills, prompt templates, and packages.
Why Pi became popular
There is a legitimate criticism of increasingly sophisticated harnesses.
They can become enormous.
You start with a powerful model.
Then the harness adds system prompts.
Then tools.
Then memory instructions.
Then planning.
Then skills.
Then MCP servers.
Then summaries.
Eventually a significant part of the model’s context is consumed before it even begins working on your actual task.
Pi deliberately pushes against that.
The idea is that developers who care about precise control should be able to own more of the harness themselves rather than inheriting a large stack of hidden behavior.
Who Pi is for
Pi is especially interesting for technically sophisticated users who do not mind assembling the exact agent they want.
That flexibility is also the downside.
A smaller harness means more responsibility falls on you.
If your goal is to build a customer-facing system with channel handling, policy enforcement, retrieval, tool safety, customer memory, and response composition, you would still need to engineer those systems.
Pi gives you a foundation.
It intentionally does not try to make every product decision for you.
LangChain Deep Agents
LangChain spent years being known primarily as an agent framework.
Deep Agents is something different.
LangChain now explicitly calls Deep Agents an open-source agent harness built for complex, long-running tasks. It provides planning, context management, subagents, a virtual filesystem, and persistent memory as built-in capabilities.[5]
That distinction is worth paying attention to.
LangChain vs LangGraph vs Deep Agents
LangChain itself now explains its stack this way:
LangGraph is the low-level runtime.
LangChain is the agent framework.
Deep Agents is the opinionated harness sitting above them.[5]
That is actually a useful way of understanding what “harness” means.
A framework gives you pieces.
A harness has already made more decisions about how those pieces should work together.
Deep Agents includes things like:
- Planning
- Context compression
- Long-term memory
- Filesystems
- Subagents
- Tool handling
- Human-in-the-loop controls
- Tracing through LangSmith
It is also model-agnostic rather than being tied exclusively to one provider.[5]
Why Deep Agents matters
LangChain has spent years watching developers independently rebuild the same agent infrastructure.
Deep Agents packages much more of that infrastructure into an opinionated runtime.
That puts it much closer to Claude Agent SDK than traditional LangChain chains.
It is especially compelling for research, coding, and long-running knowledge-work agents where the system needs to break apart a complicated objective and continue working over a long period.
Myna
A conversational AI agent harness
Myna belongs on this list for a different reason.
We are not trying to build another coding harness.
Myna is built around conversational agents.
That sounds like a small distinction until you look at what the harness actually has to solve.
A coding agent spends most of its life interacting with files, source code, shell commands, tests, and repositories.
A Myna agent spends most of its life interacting with people, conversations, customer records, business knowledge, CRMs, calendars, support systems, messaging channels, and business policies.
The underlying idea of a harness is the same.
The implementation is very different.
Why conversational agents need their own harness
A coding agent can disappear for several minutes, edit 14 files, run a test suite, and eventually come back with a result.
Try that experience with someone messaging a business on WhatsApp.
Customer conversations happen turn by turn.
The agent needs to know what the person said, what information has already been gathered, what the business needs, what tools are available, what policy permits, what happened earlier, and what the customer should hear next.
And it needs to do all of that without making the conversation feel like someone is interacting with a state machine.
That is the environment Myna’s harness was designed around. It is also why the best customer service agent is the one you can trust with a real conversation, not the one with the best demo.
Myna separates the conversation from the work
One of the most important decisions in Myna’s architecture is that performing work and speaking to the customer are not the same job.
We call it plan, then speak.
An agent may need to search business knowledge, retrieve customer information, update a contact, check a calendar, create a ticket, call an external integration, and verify that something happened.
Those steps happen inside the runtime.
Then a separate composition layer determines what the customer should actually receive.
This matters more in conversational AI than it might initially seem.
You do not want internal tool language leaking into a WhatsApp conversation.
You do not want a failed API call turning into a robotic error message.
And you definitely do not want the agent telling someone “your appointment is confirmed” because the model intended to book it even though the booking tool failed.
The harness needs to distinguish intent from evidence. The runtime reference walks through that turn: context, policy, approved tool calls, confirmed state, then a reply.
Myna uses modular runtime prompts
Another difference is how we handle instructions.
A lot of agent applications eventually create one enormous prompt containing the agent’s personality, policies, goals, tool instructions, and every edge case anyone has discovered.
We do not think that is a good way to run production conversational agents.
Myna separates configuration into purpose-specific modules.
That includes persona, objective, policy, and workflow instructions.
Those modules are compiled into the stages where they are actually relevant.
You can change how an agent should speak without rewriting how it books an appointment.
You can change an objective without modifying the policy system.
You can tighten a policy without stuffing another warning into a 10,000-word prompt.
Myna uses deterministic gates around AI reasoning
There is also a difference between asking an AI not to do something and making sure it cannot do it.
We use both.
Some decisions are appropriate for an AI model.
Others are not.
Myna has deterministic gates before and after agent execution for conditions where probabilistic reasoning is not necessary.
Depending on the workflow, that can include opt-outs, human takeover, consent, business-hour restrictions, terminal states, required evidence, and invalid actions.
The AI remains free to reason inside those boundaries.
The boundary itself does not have to be negotiable.
Tools have contracts
A business tool is not just another paragraph in a system prompt.
Myna tools have structured contracts.
Inputs and outputs matter.
Policies matter.
Side effects matter.
And the runtime cares about whether the action actually succeeded.
This is important because conversational agents act on behalf of businesses.
Scheduling an appointment is not the same thing as generating some text that looks like an appointment confirmation.
Creating a ticket is not the same thing as saying you have created one.
Updating a customer record is not the same thing as extracting the customer’s new address correctly.
A production harness has to connect language-model reasoning to real-world evidence.
The harness understands the channel
This is another place where a conversational harness differs from the coding-first tools on this list.
The environment includes the communication channel.
An email is not an SMS.
An SMS is not WhatsApp.
WhatsApp is not a webchat.
The same business objective may exist across all of them, but the way the agent communicates should change.
Myna’s composition layer can account for that channel while keeping the underlying agent and business logic consistent.
So the same harness can power multiple communication channels without simply copying the exact same message format into each one.
Context means something different in a conversation
Coding harnesses often think about context in terms of files, repository structure, tool output, and plans.
For Myna, context also includes the current conversation, previous conversation state, contact information, relevant business knowledge, tool results, customer history, current workflow state, the channel, and agent configuration.
You do not want all of that shoved into every turn.
You want the information relevant to what the agent is trying to do right now.
That is why retrieval and context management are fundamental parts of the harness rather than an add-on chatbot feature.
Myna verifies the agent’s work
There is another layer after the conversational agent has done its work.
Verification.
The runtime can compare what the agent is about to communicate against the actions and evidence produced during the turn.
The principle is simple: do not let confidence substitute for evidence.
An LLM can sound extremely certain about something that never happened.
The harness does not need to take its word for it.
So Which Agent Harness Is Best?
There is not one answer because these harnesses solve different problems.
Use Claude Agent SDK when you want a powerful, opinionated agent environment closely integrated with Claude and inspired by the infrastructure behind Claude Code.
Use Codex when your agent needs strong coding, execution, sandboxing, and approval infrastructure, especially if you are building around OpenAI’s agent stack.
Use Goose when you want an open-source, model-independent general-purpose agent with strong MCP support and local control.
Use Pi when you want a small, transparent harness and would rather design the architecture yourself than inherit a large set of defaults.
Use Deep Agents when you want an open, model-neutral harness for long-running research, coding, or knowledge-work agents with built-in planning, memory, and subagent orchestration.
Use Myna when your agent’s primary job is having conversations with customers and taking business actions inside those conversations.
That is the distinction.
Coding Harnesses and Conversation Harnesses Solve Different Problems
I think this distinction is going to become more important as the agent market matures.
Right now, people often talk about “agent harnesses” as if they are one product category.
They are not.
Claude Code’s harness has been optimized around coding.
Codex has been optimized around coding and computer execution.
Myna is optimized around conversations.
Those environments create different requirements.
For a coding agent, you care heavily about filesystems, shell execution, code edits, sandboxing, testing, and repository context.
For a conversational agent, you care heavily about turn-taking, conversation state, knowledge retrieval, business tools, persona, policy, customer context, channel behavior, response composition, real-time latency, and verification. Automating support without ruining the experience is mostly a harness problem, not a model problem.
There is overlap.
But the optimization target is different.
And I do not think the long-term agent ecosystem will be dominated by one universal harness that does everything equally well.
Vertical Agent Harnesses Are Probably Where This Goes
The earliest harnesses had to be general because the category itself was new.
Now we are starting to see specialization.
Credal distinguishes between general-purpose harnesses and vertical harnesses, pointing out that the best harness architecture depends heavily on what the underlying agent is actually supposed to accomplish.[6]
That framing makes sense to us.
A coding agent should have an environment built for coding.
A research agent should have an environment built for research.
And a conversational agent should have an environment built for conversations.
Trying to force all three into exactly the same runtime eventually means making compromises for all of them.
Why the Harness Matters as Much as the Model
One thing almost everyone building agents eventually discovers is that changing the harness can dramatically change what the exact same model is capable of doing.
LangChain recently reported 10 to 20 point improvements on a subset of its agent benchmarks simply by introducing model-specific harness profiles that changed prompts, tools, and middleware around the underlying models.[7]
Anthropic has similarly shown how much capability comes from the infrastructure surrounding Claude, which is why it made the Claude Code harness available as the Claude Agent SDK in the first place.[1]
This is also why asking an AI vendor “which model do you use?” tells you less than people think.
Two products can use the same model and produce completely different agents.
The interesting questions are becoming: what context does the model get? What tools can it use? What happens when a tool fails? What can it never do? How is state maintained? How is its work checked? What happens when the user tries to derail it? How does the system recover?
That is the harness.
The Best Harness Is the One Built for the Environment Your Agent Works In
Claude Agent SDK, Codex, Goose, Pi, and Deep Agents are all interesting for different reasons.
I would not rank them from one to five without first knowing what you are trying to build.
That is a little like asking whether VS Code is better than Salesforce.
Better for what?
For developers creating autonomous coding or general-purpose agents, there are already several excellent harnesses.
For us, the interesting gap was somewhere else.
Businesses increasingly want AI agents that live inside real customer conversations.
Those agents need to talk naturally, retrieve business knowledge, call tools, follow company policies, maintain state, work across messaging channels, and still reliably arrive at the right outcome.
That is why we built Myna as a conversational AI harness.
The model is important.
But the model is not the product.
The environment you build around it determines what it can actually become.
Sources
- Anthropic — Claude Agent SDK overview
- OpenAI — Codex
- Goose — Agentic AI Foundation
- Pi
- LangChain — Deep Agents
- Credal — Best agent harness platforms
- LangChain — Tuning Deep Agents to different models
Related:
