Treat agent harnesses as callable endpoints instead of rebuilding them

Anyone weighing whether to write their own agent harness should first consider what LangGraph, assorted vendor SDKs, Pydantic, and hand-rolled function calling actually delivered: nothing that matched Claude Code. Months of infrastructure work tend to land behind what labs and open-source contributors have already sharpened. HarnessRouter's answer is to stop treating the harness as something you own and start treating it as a backend you call.

The obstacle it removes is format drift. Every harness speaks its own request and response dialect, so swapping one for another normally means rewriting glue. The Unified Harness Protocol (UHP) sits in front of that mess, taking on session state, event streaming, artifact delivery, and failure handling — the same consolidation role LiteLLM plays for model calls.

Docker is the quickest way to see a working deployment. Fetch and start the container:

docker pull harnessrouter/harnessrouter

docker run -d --name harnessrouter -p 127.0.0.1:3000:3000 -v harnessrouter:/data harnessrouter/harnessrouter

Then follow the output:

docker logs -f harnessrouter

Once that log reports “ready on :3000”, point a browser at http://localhost:3000. The username and password are both harnessrouter. Add API keys on the Integrations page; the Harnesses tab is where routing to Codex, Claude Code, or Hermes happens, along with per-harness instructions, skills, and MCP tools.

Starter kits cover BI dashboard agents, spreadsheet agents, and video generation. Rather than one guide per scenario, an AGENTS.md file is handed to your coding agent, which reads it and wires your app into the harnesses on offer.

The practical effect is that execution-loop plumbing leaves your plate. What remains is the part that differentiates a product: the skills and tools aimed at a specific problem, with no infrastructure layer to maintain underneath.