Who Owns the Harness?

Open the tools you used today and count the AI assistants. Your email client has one. Your docs app has one. Your IDE has at least two, one of which you don’t remember installing. The analytics dashboard has one that keeps offering to “summarise this view.”

Each has a sparkly icon and its own chat history, and none of them knows the others exist.

I’ve shipped one of these, and at the time it was clearly the right call. It still might be. But the pile of disconnected assistants points at a question that gets far less attention than harnesses themselves: who should own the harness? The model provider, the product, or the user? Each has a genuine claim, and where we land will shape how we interact with technology for the next decade.

The Orchestrator and the Runner

There have been a lot of articles covering what an agent harness actually is. I generally split it into two components: the Agent Runner and the Orchestrator.

The Agent Runner, often referred to as the agentic loop, is what turns text inference into hands-off agents. It is responsible for model calls, executing tools, context assembly, and streaming events. It will also handle translating protocols between the provider and orchestrator. The approach taken is converging and Agent Runners are becoming a commodity.

The Orchestrator is everything outside of this, and is what most people think of when we talk about an agent harness. It is responsible for persisting conversations, providing delegation and multi-agent abilities, human-in-the-loop, and any other tools that have been integrated. This space is moving fast and isn’t likely to slow down any time soon.

While both parts are crucial to a robust harness, ownership of the Agent Runner is becoming less and less important: the loops look increasingly alike, so swapping one out is cheap. The Orchestrator, however, is another matter altogether; it is responsible for opening up the true power of agents to the user. For most of this post, when I talk about who owns the harness, I mean who owns the Orchestrator.

The Contenders

Since the harness provides so much potential, it’s no surprise that there is a battleground starting to form around who owns it. Looking at the problem, I see three contenders all vying for control:

• The Model Provider
• The Product Assistant
• The End User

Consider an accounting platform, let’s call it XageBooks, that wants to bring AI into its product. They want to allow their customers to use agents to do everything from classifying spending, to making budgets, to creating year-end reports. There are three approaches they can take.

The Model Provider

Claude Desktop, Codex, and the like – these are how most of us use agents today. It makes sense: the pace of development in LLMs makes it hard for anyone to keep up. Anthropic can release an updated harness, already fine-tuned for the new models, alongside them. Fundamentally though, your harness is bundled with your model.

There’s also a new kind of “model” provider emerging, designed for enterprise: a company running its own internal harness, in its own cloud, with whichever models it has approved sitting behind it. To its employees, it looks just like any other provider’s app. To the company, it means their data stays where their compliance team wants it.

For XageBooks, the provider approach means going to where the user already is. A customer opens Claude or ChatGPT, adds XageBooks as a connector, and asks it to classify last month’s spending. XageBooks supplies the tools and context; the UI, authentication, and token budgets are all handled by the provider. That makes it very easy for XageBooks to get set up. They may need to target a few different providers, but it’s easy to do once one is done.

The downside to this is that we end up with a few walled gardens holding context hostage. Products will build and maintain connectors for the biggest providers, and the smaller providers will struggle to find a way in. If the model provider you want isn’t supported by a product you have to use, then you’re forced to compromise. When the provider is an external vendor hosting everything, it can also cause issues for companies with strict data retention and data residency requirements, which is exactly the gap the enterprise variant is trying to fill.

The Product Assistant

To avoid being restricted to a small set of providers, XageBooks might decide to build an AI assistant directly into the product. The technical side to this is becoming easier, and so in a few weeks they can have a working chat panel with access to every tool the customer needs. It also makes it easy to add bespoke context and a custom UI that fits the product design. Since the conversation now flows through their own backend, they can also gather analytics and see how the users are using the new assistant. This is the approach we’re seeing most often right now, and it’s the easiest to get off the ground.

This, however, comes with its own host of problems. XageBooks itself now has: a new per-user line item for LLM tokens, an extra service to manage and maintain, and conversation history to store and sanitise any PII. It’s even worse for the user. While they don’t need to pay for their usage on the site, the built-in agent has no context other than what’s in the product itself. Their personal agent may have access to their emails to attach receipts to line items, but the built-in assistant doesn’t have this knowledge, and shouldn’t. If the assistant could query their emails, it could leak all sorts of personal information not relevant to this application.

The End User

In each of these approaches, the end user has had to endure certain restrictions on what they can do with agents and what data they have had to share with whom. If instead the user owned the harness, it would be completely up to them how it would get used. They could choose their preferred models, install plugins, and provide context where it’s needed. Yes, they (or their business) would personally have to foot the bill for their AI usage, but it would provide them with flexibility, customisation and a single harness for every product they use. For XageBooks to implement this, all they need to do is provide an MCP server, or configure WebMCP in their web application. They’d have no ongoing costs other than the marginal costs of users hitting these endpoints and yet still supply the full set of features they want.

The obvious objection is that we already have this. XageBooks can ship an MCP server today, and it’ll show up in Claude Desktop. A provider-owned and a user-owned harness plug in tools the same way; what separates them is what's bundled together. A provider’s harness is open at the edges and closed at the core: you can add tools, but your model, your memory and your history come as one package. Want a better model from someone else? You’re starting again. A user-owned harness treats the model as a component. Your context, your configuration and your choice of tools belong to you, and the model is just the thing doing the thinking this week. It’s the difference between an email address on your provider’s domain and one on your own. The hosting might be identical, but only one of them lets you leave.

That also means the choice is a cheap one for XageBooks. They expose the same tools either way; what changes is who their users end up locked into.

This self-sovereign utopia does have a few pitfalls. Firstly, it requires a lot of standardisation, both on protocols and on interaction behaviours. We’re on our way towards this with MCP and WebMCP, but it takes time for these to cement into reliable layers in our technology. There are also more security concerns: for example, could a malicious tool extract information that it shouldn’t have from a naive agent? There are also some downsides for XageBooks. They would no longer have an understanding of what the user was trying to achieve, and only see the tools that were executed. It would also leave these endpoints open to abuse from malicious agents.

Mixing Things Up

While we focussed on the Orchestrator part of the harness, the owner of the Runner can also be split from this and lead to some interesting workflows. Here are a few examples of where you might find the different combinations:

XageBooks’s three options sit on the diagonal. The connector in Claude is Provider/Provider, the home-built chat panel is Product/Product, and the MCP server driven by the user’s own agent is User/User. Step off the diagonal and new options appear. If XageBooks embedded a chat window using “Log in with Claude” and a provider’s hosted agent loop, that would be Product/Provider: XageBooks owns the experience while Anthropic runs the agent. If XageBooks built a specialist year-end reporting agent and let the user’s harness hand work to it, that would be User/Product.

That last kind of hand-off needs protocols like A2A, which let one agent pass a task to another agent it doesn’t own and can’t see inside. The off-diagonal cells are where things get interesting, because they let each party keep the piece it cares most about: the product keeps its specialist agent, and the user keeps their context.

To Me, It’s All About Context

For better or worse, agents are becoming a central part of our lives. From creating personal apps, to planning your next holiday, we have come to rely on the ability of an LLM agent to understand our individual ways of working. The more I give to my agents in the form of tools and context, the more I get in return.

If we allow model providers to build walls around their models, we could easily end up dependent on them and their ability to keep up with the pace of development in the AI world. Just because a provider has the best model or UI now doesn’t mean they will do in the future. It’s being shown repeatedly that these companies cannot create a moat simply based on the abilities of their models, and the simplest solution is to use your own data as that moat. If the switching costs are too high, no one will move.

Letting each product create its own agents, each with their own workflows and user interactions, would lead to a lot of people solving the same problem but with restrictions that would hamper their usefulness. Yes, there may be tools that require this: sensitive or proprietary data shouldn’t be exposed directly to a user without some serious thought about where that data goes. However, this will likely become the exception and not the rule. Most of what makes a product’s assistant special, its bespoke context and its domain workflows, can be delivered to someone else’s harness as tools and context. And where a product genuinely needs to keep data behind its own walls, it doesn’t need a whole assistant to do it; a specialist agent that the user’s harness can delegate to does the job.

A harness owned by the user may provide some complex challenges, but once those are solved it provides the most powerful paradigm. Agents work for their users, so being able to control how they work is extremely important. Being able to personalise your harness allows each user to find the balance that works for them. A project manager can get a report on all their services in one place, while the team members can focus on what’s important to them. A dyslexic user can get content read to them, and an author can restrict an agent from writing while still ensuring consistency. Most importantly, the user would get the opportunity to choose what services they want their data going to, and have the ability to switch without too much of a cost. A user-owned harness is where I would like things to go.

Until We Get There

There’s an awkward truth at the heart of all this: the people who would have to build user ownership are the products, and they’re the ones who lose the most by doing it. An embedded assistant shows XageBooks every question its customers ask. An MCP server shows them a list of tool calls. Asking products to trade that insight for a better user experience is a hard sell, and it’s a big part of why this battle isn’t going to be solved overnight.

For anyone building a product or library like AG Studio, it can be hard to work out exactly what to build so developers using your product can start using its AI features as quickly as possible.

My advice would be to start with tools. These are atomic actions that a properly configured agent can choose to take within your library. Keep each one well-scoped so an agent can combine them, and make the set configurable so the developers integrating them can decide which tools are exposed and how they behave. You don’t know their workflow, and they do.

Then you need to provide context. It may seem obvious if you’re the developer of a library what context the AI should get, but that may not be true of your developers. Consider what state the AI truly needs to see, how “non text” content such as visualisations might be converted for use by the agent, and how best to teach your developers to provide this to their AI.

Finally, and only if it’s really necessary, you can build a harness to integrate into your library directly. AG Studio supports all three contenders: the same tools are exposed through WebMCP, so a provider’s harness or the user’s own can drive AG Studio, and we also ship a built-in assistant. That puts us in the Product/Product cell as well, and we chose it knowingly, for three reasons:

1. AI harnesses were very immature when we started and didn’t support some of the features we needed.
2. Our library runs entirely in the browser, hence the harness needed to as well.
3. AG Studio has zero external dependencies and the interfaces with other harnesses have not stabilised for integration.

Most importantly, no one knows who will win this race, so try to keep your options open.

Nobody & Everybody

So who owns the agent harness? Nobody, outright, and everybody has a claim. Right now, the providers own most of the usage, while products own most of the integrations, usually as simple embedded assistants. The more innovation we see in harnesses, the more fragmentation we will see in the harness market. The big providers such as OpenAI and Anthropic want to capture the market by being faster than the competition, but as custom harnesses appear for specialised use cases, that’s going to be an uphill battle. More and more products are shipping AI assistants, but they’re limited in what they can do, while the protocols for user-owned harnesses are lagging behind.

If the choice were left to me, I would be all in on the user owning the harness. It may take us a few years to see that come to fruition, but the benefits to users are substantial. Plus, I’m really tired of half-baked harnesses gatekeeping services I rely on, including, occasionally, my own.