The Next Evolution of Agent Harnesses: The Meta-Harness
We are at the point where LLMs with tools are genuinely useful in day-to-day life. Anyone can open an agent interface and build a simple app, plan a trip, or manage a calendar.
We have long moved past being impressed by a Q&A bot. The bar now is whether the LLM can execute while connected to the tools we use.
The Hierarchy Most of Us Use Today
For most users, the hierarchy still looks like this: you are the project manager working with many individual but mostly homogeneous contributors.
You tell one agent to act like a designer, then tell another to act like an engineer. In practice, many people do not even bother prompting a specific role because it is cumbersome. They treat the agent as a super-generalist instead.
This works well if you manage it closely. But you are still doing the routing, carrying context between chats, and deciding who should do what.
How most of us manage agents today
Click a highlighted node to see what responsibility still sits with the user.
Click any highlighted step for an explanation or example.
The bottleneck: the agents can execute, but you remain the router, context carrier, and project manager.
The Meta-Harness
I have observed a recent evolution toward a broad category that I will refer to as the meta-harness.
A meta-harness sits one level above the thing doing the work. Instead of asking you to choose and manage every contributor directly, it decides how to route, combine, or coordinate them.
This is appearing in a few layers, from lower-level model selection to higher-level agent organisations.
Layer 1: A Harness Across Models
The orchestration structure can remain similar while the model layer changes underneath it. Instead of picking a single LLM, you let another system decide how to use the available models.
Cursor Router and Databricks Smart Routing can select one model for an agent request. Devin Fusion routes work between a frontier main agent and a smaller sidekick during the task. OpenRouter Fusion asks a panel of models and gives their outputs to an analyst. Sakana AI’s Fugu is a learned orchestrator that can dynamically assemble workflows across expert model workers.
These are related ideas, but they are not the same architecture:
- Per-turn selection: classify the next request and choose one model.
- Dynamic hybrid routing: move individual steps between a main model and a cheaper sidekick during a longer run.
- Deliberation: ask several models in parallel, then compare their answers.
- Learned orchestration: let an orchestrator construct and coordinate a model workflow for the task.
Four ways to harness multiple models
Switch between the architectures to see where model selection and coordination happen.
Click any highlighted step for an explanation or example.
Examples: Cursor Router, OpenRouter Auto, Databricks Smart Routing. The system chooses one model for a request or agent turn; another turn may be classified again.
These systems are very much works in progress, and opinions are still split on whether automatic selection is better than choosing manually.
If done well, though, the idea is sensible and attractive: get the best output for each dollar spent. I am bullish on this. Users should not have to worry about a quality shift every time a new model comes out, or constantly debate whether and when to switch.
In theory, adding a strong new model to the pool should improve the workflow—or leave it unchanged—rather than forcing everyone to rebuild their habits around a new model name. The hard part is making the router reliable enough for that promise to hold.
Layer 2: A Harness Across Coding Harnesses
The next layer moves beyond models.
Claude Code, Codex, Grok Build, Cursor, Pi, and similar coding harnesses can already orchestrate multiple agents for a task. But if these systems behave like different teams, with different strengths, can another layer orchestrate them?
From one coding harness to a meta-harness
The orchestration layer moves above the individual provider.
Click any highlighted step for an explanation or example.
You commit to one provider’s orchestration choices and strengths for the task.
We are beginning to see this with tools such as Databricks’ open-source Omnigent, Conductor, and others.
People will not want to choose one provider forever. They will trend toward systems that use the best of each, based on the system’s judgment and the user’s preferences.
Much of this activity is still concentrated in coding. Over time, I expect the same pattern to spread to other kinds of work, reducing the need to constantly switch applications.
Layer 3: A Harness of Diverse Agent Teams
The emphasis here is on diverse.
We already had teams of agents in the previous era, but they were usually homogeneous and organised around one task or project. You could have Claude Cowork help fill in an immigration form, then open another chat or project for grocery shopping. Those agents did not share much context or have much synergy beyond a general memory of your preferences.
Grok Bot made the biggest architectural shift for me. Rather than being project- or task-based, it is structured more like a company organisation.
You recruit specialists into your organisation. They are persistent employees with distinct roles. They can communicate with each other, work together in sub-team threads, and retain memory to an extent.
You can call one person when ownership is obvious, bring the whole team into a discussion, or give a project manager an outcome and let them form the right sub-team.
Three ways to work with a persistent agent team
Switch between a direct conversation, a whole-team discussion, and delegated sub-team work.
Click any highlighted step for an explanation or example.
Direct conversation: best when the owner is obvious and the task does not need a wider discussion.
The result, for me, is a joyful delight.
The setup promotes the user from a project lead who has to specify every task and goal in great detail to something closer to a CEO. You work with your designer, engineering lead, and product manager. Discussions with them together tend to produce new ideas and make delegation feel natural.
Once everyone is aligned, a project manager agent can track the work and nudge each specialist toward the goal.
The Computer Becomes a Universal Tool
Another major shift is giving agents access to computers. With the right controls, computer use effectively gives an agent access to substantially more tools.
Not every platform and application is connected to every agentic system. If an agent can control a computer, it can often work around that gap by using the interface like a person would. This does not replace APIs or structured integrations in every case, but it greatly expands what an agent can actually complete.
Ending Thoughts
This gives us a glimpse of a future where we do more work at a higher level of abstraction.
We moved from asking a model for an answer, to giving an agent a task, to coordinating a team around an outcome. The next step is not simply a smarter individual agent. It is a better organisation around the agents.
One can only imagine that soon these systems will allow exchanges from one user’s agent team to another. Your research agent could brief my product agent; my engineering lead could negotiate scope with yours.
That future will require strong permissions, clear provenance, and sensible approval boundaries. But the direction feels increasingly visible: we will spend less time operating each agent and more time shaping the organisations they form.