Agent brokers

What a broker is

A broker decides which agent, harness, or model-powered tool should receive a piece of work, hands it over, and collects the result. It does not run the agent loop. It does not execute tools. It does not hold task state while the work is happening.

Described that way it sounds like it barely exists, which is roughly the point. The value of a broker is concentration: it puts a small number of decisions in one place that would otherwise be made implicitly, differently, in every application that wants an agent to do something.

Why I think this category matters

Most people arrive at multiple agent harnesses without deciding to. One came with an editor. One was adopted for coding. One arrived embedded in a vendor product. One was built internally for a workflow nothing else covered. This is the normal state of affairs, not a mess to be cleaned up.

The problem is not that there are several. It is that each one has its own idea of what an agent is, its own configuration format, and its own place to store definitions. A useful agent defined in one is unavailable in another. Switching means rebuilding. Using two means maintaining two copies that drift apart within a quarter.

The usual responses are both bad. Standardizing on one harness is impractical and temporary, since a new one will arrive. Accepting duplication degrades quietly, and by the time anyone notices, the copies have diverged in ways nobody can reconcile.

A broker is the third option, and it only works if there is a portable definition of what an agent is. That is why my work on brokering and my work on the Open Agent Profile are the same project seen from two directions. Without a portable profile, brokering means translating between every pair of harness configuration formats, which does not scale and does not stay correct.

The line between broker and harness

This distinction gets collapsed constantly, and keeping it sharp is the most useful thing I can say about the category.

The reason to hold this line is not taxonomy. It is that a broker which grows an agent loop has become a harness competing with the harnesses it brokers, and at that point it has an incentive to route work to itself. The abstraction stops being neutral. Declining to run agents is what keeps the routing decision honest, which is why Merced AI is deliberately not another agent loop.

What a broker actually decides

Five things, each of which is otherwise decided by whichever calling application was written first.

• Which executor. Based on the kind of work, the data involved, what is installed and authenticated, and what the definition needs.
• Whether at all. Some requests should be declined or escalated rather than routed, and that check belongs in one place rather than in five callers.
• Under whose authority. Identity is a property of the request rather than of the executor, and it should travel with the work.
• With what budget. Step, time, and spend limits attached at dispatch rather than assumed independently by each harness.
• Where the record goes. One usage and outcome record across every executor. Without a broker this is essentially impossible to assemble, because each harness records in its own shape.

The honesty problem

Here is the part I find most interesting, and the part I got wrong before I got it right.

Harnesses do not support the same things. One enforces a tool allowlist natively. Another has no permission system at all and says so. One supports skills. One accepts a capability tier; another needs a specific model name. When you project one portable definition onto a runtime, some of it survives and some of it does not.

There are three ways to handle that and only one is safe.

Pretend uniformity. Silently drop what is unsupported. This is the worst possible outcome. A profile declaring a tool denylist runs on a harness that ignores it, and the operator believes a boundary exists that does not. The system is now less safe than if there had been no profile at all, because the profile created confidence.

Refuse anything not fully supported. Safe, and it reduces the broker to the intersection of every harness, which is close to nothing useful.

Project and report honestly. This capability is native here. This one is approximated. This one is degraded in this specific way. This one is unavailable. The operator then decides whether the projection is acceptable for this work.

I have come to think reporting degradation rather than hiding it is the single most important design principle for any abstraction over heterogeneous backends. Silent degradation is where trust in abstractions goes to die, and it is always the tempting option because it makes demonstrations smoother.

Several agents in one conversation

One arrangement a broker enables is worth describing on its own, because it is different from the usual multi-agent pattern and I think it is underrated.

The common pattern is a coordinator that decomposes work and dispatches to subordinates, each of which is a persona of the same system. The alternative a broker makes natural is several genuinely distinct bots, potentially running on different harnesses with different permissions, participating in one conversation with their contributions attributed.

The difference matters for two reasons.

Attribution is real. A person can see which bot said what. When three personas of one agent disagree, that is the same system being inconsistent. When three bots with different definitions and different tool access disagree, that is information.

Permissions can genuinely differ. An implementer with write access, a reviewer with read-only access, and a documentation specialist with a narrow tool surface are three different authority profiles. Collapsing them into one agent with three hats gives all three the union of the permissions, which is precisely the arrangement the reviewer role existed to avoid.

This maps onto how people actually work. We do not give one person every role and ask them to remember which hat they are wearing. The reason agent systems keep reinventing that arrangement is that, without a portable agent definition, creating a genuinely separate agent is expensive, so personas are the cheap approximation. Once agents are files, separate agents cost almost nothing, and the approximation stops being necessary.

When you need one

• More than one harness in use. The prerequisite. This is the trigger, and it usually arrives sooner than expected.
• Agents that should outlive tool choices. When a definition is worth more than the runtime it currently runs on.
• Evaluating harnesses. Running the same bot on three runtimes and comparing is far easier than defining it three times.
• Heterogeneous machines. When different people have different tools installed and the agent should work anyway.
• Mixed capability requirements. When a governed harness should handle some work and a fast one should handle the rest.

When you do not

A single developer using one harness gains nothing from a broker and adds a component. I want to be straightforward about that, because the temptation in writing about your own work is to imply everyone needs it.

The value appears at the point where duplication starts, which is the second harness rather than the first. Before that, a broker is indirection without benefit, and the right move is to keep your agent definitions in a portable format so that adding a broker later costs nothing.

That last point is the real advice. The portable definition is what matters. The broker is one way to exercise it.

What building one taught me

Three things surprised me while building Merced AI, and they generalize beyond this category.

Discovery is harder than routing

Deciding where to send work is easy. Finding out what is installed, which version, how to invoke it non-interactively, and what it actually supports is most of the work. Interfaces change between versions, and a broker that assumes uniformity produces confident failures.

It also has to be done safely. Determining a version usually means executing something, which means a discovery scan is a subprocess execution surface. Bounded execution without a shell, with timeouts and explicit path overrides, is not a detail.

Machine-readable output changes what a tool is

A broker whose output is only human-readable is a convenience. One whose inventory, profiles, dry runs, and results are all structured is a component other things can build on, script, and run in continuous integration. I did not appreciate the size of that difference until people started using it in ways I had not anticipated.

The inspection steps have to come first

Check the projection before running. Dry run before executing. This ordering feels slow and is what separates informed use from optimistic use. It is the same instinct behind writing a plan as a document before running it, and I now think it applies to every layer of an agentic system.

Sessions turn out to matter more than runs

I built one-shot execution first, assuming that would be the common case, and it was not. Most real use is multi-turn work that spans more than one sitting, which means durable session records with resume are not a convenience feature. Atomicity matters too: an interrupted write that corrupts a session is worse than losing it, because a corrupted session fails confusingly rather than obviously.

Where I think this goes

I will be direct about the speculative part, since this is my site and the reader can weigh it accordingly.

The current situation, where every agent product invents its own idea of what an agent is, resembles the state of database access before drivers were standardized, or editor tooling before language servers. Those situations resolved the same way: not by one product winning, but by the interface between products becoming a specification that several people implemented.

If that pattern holds here, three things follow.

Agent definitions become organizational assets rather than product state.A company's agents, skills, and procedures become artifacts it owns and versions, the way it already owns its source and its schemas. The runtime becomes a choice rather than a commitment.

Brokering becomes routine infrastructure. Nobody thinks of a database connection pool as an architectural statement. A component that decides which runtime should execute a piece of agentic work, under whose identity, with what budget, will be similarly unremarkable.

The interesting competition moves. If definitions are portable, harnesses compete on execution quality, safety, and operational characteristics rather than on how much of your configuration they hold. That is a better competition for everyone except whoever currently holds the configuration.

I could be wrong about the timeline and I am fairly confident about the direction, because the alternative requires every organization to accept that its agent definitions belong to whichever vendor it chose first. That has not been an acceptable arrangement in any previous layer of the stack, and I do not think it will be in this one.

What a broker is not

A broker is not a policy enforcement point. It can decline to route. It cannot make a harness enforce something the harness does not implement, which is exactly why the projection report matters.

A broker is not an agent framework. If you find yourself adding an agent loop to a broker, you have started building a harness, and the honest move is to admit that rather than to keep calling it a broker.

A broker is not a hosted platform. Everything I have built in this category is local-first, meaning it discovers what is on the machine rather than managing remote infrastructure. That is a design choice about where control sits, not a limitation I intend to remove.