The Harness Isn't Your Problem, The Router Is
Published ....
Last modified ....
From Boston, MA
Share this status update on BlueskySee discussion on Bluesky
A lot of engineering work over the past year or so has been around building better harnesses. While that effort has brought a lot of great advancements (just look at the Codex ChatGPT mac app and all the features it supports for an example!)
That being said, I think the environment is shifting rapidly from one where the harness is all that matters to one where the router will be far more important.
The frontier models are really, really good. Yet each model can accel at different aspects of the problem being solved. Additionally, it can become cost prohibitive to send off that "fix this typo" prompt over to Fable 5 max each time. That's where a router comes in!
A router (at least in the context of AI agents) is a networking component that allows for different agents/models to be used for different requests. Imagine you send a prompt into the router, and then the router splits the work up by sending off a part of the prompt to a planning agent, and then takes the result of the plan and hands it off to a fleet of execution agents.
While you can use one model for everything (which I've been doing with GPT 5.6 Luna because of its cost efficiency), the best possible results for more problems is to leverage different models for different parts of the overall work.
A common breakdown I see shared widely on twitter at the moment is:
- Use Fable 5 for planning
- Use GPT 5.6 Sol for execution
- Use GPT 5.6 Luna for sub-agents
There's a variety of hosted router companies out there, OpenRouter perhaps being the largest and most well known at the moment. However I think the next big leap will be an on-device router, e.g. something that sits on top of or next to your desired harness and handles routing to the different agents for you, without you needing to completely move over to only using a single global router.