Introduction

Recently I was going through X and I saw an article making the case that they did not want to use agents provided by third-party services but instead prefer to use their own user agent combined with the knowledge / skills / MCP servers that the company provides. Their argument was broken down into 2 main concerns. The first was model capabilities, where they believed that these services usually offer cheaper models, because running frontier models for all users is expensive, whereas they could be using their own user agent which is running frontier models. The second was context, where they made the argument that these service agents lack key information regarding local files, git repositories, etc.

This was very interesting to me due to my work on Stitch, where I’m building an agent to do my administrative work for me, and where I leverage open source models daily. My philosophy on this has actually been quite the opposite. I believe that my user agent should really only know me well, and anything it needs to learn should either be researched at runtime, or it’s my responsibility to provide it at prompt time. I do not want to become the maintainer of every company’s skills, MCP servers, and brittle config files just to get my user agent to use a service correctly.

My Disagreements

The argument in the original article, I think, was written from the perspective of a technical user who is still involved in the details of the work they do. But, as we see more nowadays, more users are unaware of the deep technicals of how their app works. Whether this is good or bad I leave up to you (I don’t think it’s good), and if we imagine that world to the end state, no one will care to maintain these things long term. I want to take the time to break down these arguments and why, while they look good and reasonable at a surface level, in my opinion they are actually the wrong way to approach these things long term.

Model Capability Is Not Agent Capability

Making the argument that you should always use frontier models over models selected by the service provider to do work for you is an easy trap. It assumes many things which I don’t think hold true.

Assumption 1: Frontier models are better for all tasks I think this is the weakest argument. Frontier models are great and yeah, you will probably get marginally better performance from them, but any task that is in the distribution of training will be fine on the Kimi/Deepseek/GLM models. You really don’t sacrifice much here. I think the cost argument is worth noting here: service providers are likely to introduce cheaper models, but I think this falls apart because we see token pricing coming down each year, and at a certain point using frontier models becomes overkill.

Assumption 2: Skills and MCP servers will transfer One of the potential ways of enabling user agents to do everything was to basically have the service providers host MCP servers and publish skills that user agents could use to implement the work. I believe this doesn’t work as well as you would think for a couple of reasons.

The first is that the agent harness is coupled to the model that it’s using. We can already see this in open source coding harnesses such as OpenCode, where depending on the model, they can switch the system prompts, and even the tool definitions when performing a task. Every small change impacts the model behavior. Assuming that the service providers are deeply considering the engineering of their service agents, they probably spent a lot of time evaluating their agents on the subset of models that they run on, and likely shaping internal apis / tools around those agents. This means that any skills or MCP servers that they publish will impact the user agents differently. How much this impact is, we can’t be sure, but I assume over time these differences will grow, in parallel with the advent of domain-tuned models and the large shift to open source models by the large enterprises. If companies start running their own domain-tuned models, those service agents may end up better at their own product than a generic frontier model calling exported tools.

The second reason is that there is no standard discovery and update layer right now on how to make user agents aware of changes in MCP and skills. Skills has become the new core primitive in the agent world, but it’s really hard to maintain a list of skills. There is also no good empirical way for users to know which skill is better, when it needs updating, or whether a failure is the skill, the model, or the agent harness. We have no way for service providers to communicate updates, and no standardization across the major agents (open and closed source). Having everything be exposed to users would necessitate a whole new protocol layer, which I don’t see working out. It would take all of the major frontier labs to accept the standardization and implement it, which is unlikely, given the differences we see already in defining agent files, skill file placements, etc.

Context Transfer

This is the hardest point to counter: it’s true there is no real feasible way to give service agents private context right now. There is no agent interface, and everyone seems to be making their own way to do this. The most common thing I see is local agents that explore files, or context engines that are accessible via MCP servers. This area I think is still being built, and I have my own thoughts on how we could solve this problem, but that’s not relevant to this blog entry.

My Proposal

The better integration model is not publishing more skills and MCP servers. It is giving user agents a standard way to call service agents. All current coding agents have some sort of sub-agent system, which effectively allows them to call LLMs to perform a specific task with fresh context and a limited set of tools / MCP servers, skills, etc. This is a very powerful primitive that currently is only really used for internal agents defined in the user agent harness. This should be extended to create an agent interface. This interface would define the agent name, the capabilities, and something to control if it’s local or external. If it’s external, we authenticate (similar to MCP servers) and then the user agent can communicate to service agents on what they need done over HTTP or any other transport. Coupled with a great discovery layer, like skills, I think this is a perfect way to handle everything. Agents can communicate with each other, send over private context, ask questions that either the user agent or the user can answer, and then work independently. My user agent stays the owner of my private context, and only passes the relevant pieces downstream when a service agent asks for it. This way the user only configures a service agent their user agent interacts with, without doing anything else. All upkeep is either automatic or unnecessary.

For example, I should be able to ask my user agent to setup my site on Cloudflare and add PostHog analytics. My user agent should talk to Cloudflare’s service agent and PostHog’s service agent, give them the relevant repo / account / preference context, let them do the work in their own systems, and then come back to me with the result. I should not need to install and maintain a Cloudflare skill, a PostHog MCP server, and whatever changes they ship next week.

Google has already set up this idea, called the A2A protocol, but this seems largely unimplemented across the board. Most people are creating their own agents locally, using skills from central marketplaces like skills.sh by Vercel, and then manually updating skills as they run into issues.

Zed, the coding editor, also has something similar called the ACP protocol, which allows them to use a standard agent interface to interact with coding agents but through the Zed UI. ACP seems to really be focused on coding agents currently, and is entirely controlled by Zed.

Both A2A and ACP are great, but neither are widely adopted, which I believe will change soon. Personally I think there are some gaps, like a standard questions, elicitation, and permissions layer that can be used by all agents. Whoever makes talking to service agents seamless via user agents will win out here. Google seems to be positioned, but not really doing anything.

Overall I agree with the original post that I don’t want to use your agent, but I want my user agent to be able to talk to your service agents. I don’t care about maintaining skills or MCP servers, I just want things to work.