HarnessRouter - Bring the world's best AI agents into your app, with one API

Amazing launch congrats👏 @renchu_song  does each sandbox have direct outbound internet access for tool scraping or can we configure strict egress rules?

Congratulations on your launch, @renchu_song Curious about the handoff between agents. If I build with Claude Code today and switch to Codex later, how much context and setup carries over without rebuilding the workflow?

@st0rm_27 Great question, Mohit. I think teams, especially highly technical ones, tend to build their own agent harness infrastructure in-house, and that decision itself is surprisingly risky. We made the same mistake, until earlier this year we realized agent harnesses are getting commoditized fast. Competing with frontier labs, well-funded startups, and open source communities by hand-crafting our own harness just wasn't a wise use of our time.

So we chose to leverage rather than build. That freed us up to focus on what actually differentiates us, and it's let us build great applications both for ourselves (more launches coming soon!) and for our customers. HarnessRouter is us packaging up those learnings and handing the same leverage to the builder community.

@renchu_song  @st0rm_27 I’ve personally built an agent harness to run my projects, so I know many ways to get it wrong.

You end up designing orchestration across tools, MCP, models, sandboxes, files, permissions, usage caps, retries, streaming, and observability. Each piece becomes almost its own product, and then you still have to think carefully about how all those pieces interact.

That’s why I think this is the better path for most teams: instead of building and maintaining the harness itself, stand on the shoulders of existing harnesses and customize the parts that actually encode your domain: instructions, tools, skills, evals, and product workflow.

Fewer infrastructure mistakes, less maintenance, and faster, better outcomes.

@roguetink you absolutely nailed it, Shivangi! Yes, just like there are a lot of model routers / token routers vendors in the market, the market need a vendor neutral platform and aggregator for the harness layer. Harness + Model = Agent. With the M harnesses * N models options, any business have the flexibility to avoid vendor lock-in for the best of their benefit.

@roguetink Hi Shivangi, you’re exactly right. Builders don’t want to be locked into a single agent, especially when the best system may combine different agents, each optimized for a specific task.

We’re already seeing labs use HarnessRouter’s infrastructure to evaluate models and agents across different tasks. Over time, this performance data can power smarter routing and become an increasingly valuable intelligence layer.

@nivotools thank you for your insightful question! We built a OpenAI responsive API compatible contract for the harness response, and cannicalized all harness repsonse to this format. So that any AI app built with OpenAI responsive API can do a one line swap to upgrade their one-shot chat completion backend to an agentic intelligence backend.

@renchu_song  @vikramp7470 We love this question! Some parts of it are already on their way to being open source. We plan to build with the community and contribute as much as we can.

@vikramp7470 Thanks, Vikram! 🙏 And yeah — that sinkhole is very real, that's kind of the whole bet behind building this.

Open-sourcing parts of it is something we've talked about internally. The parts that'd make the most sense to open up are probably the runner/SDK side (how a harness actually executes a turn) rather than the routing/billing/multi-tenant plumbing, which is more specific to running this as a hosted service.

No promises on dates, but if self-hosting is something you'd actually use, worth telling me more about the use case (compliance? cost? just wanting to hack on it?). That's the kind of signal that'd push it up the list!

@thys_beesman Great questions, both are things we learned the hard way rather than designed on a whiteboard.

On harness portability, you're right that a bare prompt tuned to one agent doesn't transfer for free, and we don't claim swap-and-forget. What makes switching practical for us is that the harness definition stays deliberately thin, and the domain expertise lives in two layers that are genuinely portable: skills (explicit, procedural instructions paired with deterministic scripts the agent invokes: recipes, not model-idiom prompting) and typed tools (every tool exposes a strict input schema; the schema is the contract, and both runtimes consume it the same way). The system prompt describes the job, not the model's habits.

The honest second half: every harness config ships with an eval suite, real domain cases scored against rubrics, with human-expert alignment checks on the grader. Switching the underlying agent means re-running the suite and fixing what it surfaces, which is usually tool-boundary discipline rather than instruction rewrites, where runtimes differ in how carefully they fill tool arguments, we add validation guards at the tool layer instead of forking the instructions. Today we run some verticals on one runtime and some on the other, chosen by eval results, not loyalty. So "one line of config" is the mechanism; the eval suite is what makes it safe to actually pull the lever.

On data residency: this is the first question every healthcare compliance team asks, and the answer is structural, not policy: agent runs execute in sandboxes inside the same private network where the data already lives, there is no third-party backend the documents travel to. Each run gets an isolated workspace; reference material is mounted read-only; the workspace is destroyed when the task completes. What persists is exactly what a compliance team wants persisted: the audit trail, what was asked, which tools ran, what was produced, not copies of source documents. Customer data is never used for model training. Happy to walk through the architecture in detail under NDA, that conversation is usually shorter than people expect because the answer to "where does our data go" is "nowhere."

Great question@aryan787544 Ultimately, we see it working this way:

Different tasks are routed to different agent harnesses, models, skills, and tools. The routing is dynamic and adapts as agent harnesses and models evolve.

@aryan787544 inspirational question, Aryan! I in-vision a dynamic routing to the best harness + model combination adaptively will be a moat, and the orchestration layer stays on top of frontier model labs, which is to stay

@albattran thank you for your support, Samir!

@albattran Thanks for supporting our team Samir!

@huisong_li thank you for your support, Huisong!

@renchu_song  Thanks @huisong_li for supporting our team!

@galdayan great question, Gal. For enterprise customers with deep domain expertise, we send forward-deployed engineer to customer site and work with customer side by side, distill the human expertise into both the agent skills, AND the evaluation sets. To iterate, we build tools for human experts to easily rank and label different versions of agent response, and use that signals to gate go/no-go on harness swap