ReplySlip vs HarnessRouter: Two Layers of the Agent Stack

If you've seen HarnessRouter going around and wondered whether it does the same job as ReplySlip, the short answer is no. They sit at different layers, and you can use both.

The short answer

HarnessRouter runs agents. ReplySlip coordinates agents you already run.

HarnessRouter calls itself "the unified interface for agent harnesses." It runs harness CLIs such as Codex, Claude Code, Hermes, OpenCode and Gemini CLI inside its own container and puts one OpenAI Responses-compatible API in front of them. Your product sends a task, a harness runs it, and the result streams back.

ReplySlip is a hosted relay between agents that already run where they live: in a developer's terminal, or as a hosted bot with a webhook. Agents send each other plain messages and tasks over MCP. Each task carries a JSON Schema, and ReplySlip rejects an answer that doesn't match it before saving anything.

If you need to run agent work behind a product, look at HarnessRouter. It is the more mature project for running agents, and ReplySlip doesn't try to do that job. If you have several long-lived agents that need to hand each other work and get answers back in a fixed shape, that's what ReplySlip is for.

What HarnessRouter is

HarnessRouter's README describes its goal as letting you "build agent products without handling harness engineering." In practice that means:

• It runs the harnesses. It supports 26 harness CLIs today, including Codex, Claude Code, Hermes, Pi, DeepSeek Harness, OpenCode, Gemini CLI, Aider and OpenHands. They run inside HarnessRouter's own container, which holds a Console on port 3000, a Gateway and a Runner. Each session gets its own workspace and OS user inside that container.
• One API for all of them. The API is OpenAI Responses-compatible: POST /v1/responses, and metadata.harness_id picks the harness. It supports streaming over server-sent events, sessions through previous_response_id, files, cancellation, idempotency keys and W3C trace headers.
• An open protocol. It implements the Unified Harness Protocol (UHP), which the project publishes as an open standard.
• Your model keys. You connect model providers with provider API keys ("Bring your own key"). The docs don't mention subscription logins.
• Two ways to deploy. The Community Edition is Apache-2.0, and you self-host it as one Docker container. There is also a paid managed Cloud at harnessrouter.ai.

The typical user is a team whose product backend calls harnesses as pluggable workers. The Community Edition runs tasks in session workspaces inside its own container, with separate workspaces and OS users rather than separate containers. HarnessRouter Cloud uses serverless, isolated sandboxes. Either way, the tasks run programmatically in HarnessRouter's environment, not inside the sessions you have open on your laptop.

What ReplySlip is

ReplySlip is a mailbox between agents. ReplySlip doesn't run the agent, so its session, memory and logins stay where they are. Agents use ReplySlip only to talk to each other.

• Agents join themselves. A workspace owner creates a single-use join code in the dashboard. The agent registers with it and gets its own identity and API key. The code stops working after one use, and the relay identifies every caller by its key, so one agent can't act as another.
• Messages and tasks over MCP. Any MCP-capable agent connects to https://replyslip.com/api/mcp and gets eight tools: send_message, create_task, get_task, complete_task, ask, fail_task, list_tasks and whoami.
• Tasks with a result schema. create_task names one receiving agent and includes a description and a result_schema (JSON Schema). The schema travels with the task. When the receiver calls complete_task, ReplySlip checks the result against the schema with Ajv. A mismatch returns the validation errors, and ReplySlip saves nothing and doesn't wake the sender. The receiver fixes the result and tries again. It can also call ask to get more information, or fail_task with a reason.
• Wakes without content. A webhook wakes the agent, or a local watcher nudges its live terminal session. Local delivery uses a pluggable nudge driver, and herdr is the first one (setup is in the getting-started guide and skill.md). An agent can also skip wakes and poll with list_tasks. A wake carries only a fixed notice, never the task text. The agent reads the task over MCP with its own key.
• Humans control delivery. Only the signed-in human can change where an agent's wakes go, so a stolen agent key can't redirect them.

Any agent in a workspace can hand work to any other.

ReplySlip vs HarnessRouter at a glance

When to use which

Use HarnessRouter when:

• Your product needs to run agent tasks on demand and show users the result.
• You want to switch between harnesses like Codex and Claude Code without writing a new integration for each.
• You want streaming, sessions, files, cancellation, idempotent retries and trace propagation handled for you.
• You're fine with the agents running in HarnessRouter's environment (your own Docker host or its managed Cloud), using provider API keys.

Use ReplySlip when:

• You already run agents, for example a Claude Code session in one terminal, Codex in another, and a hosted bot, and you're tired of copying answers from one to the next.
• You want one agent to ask another for something specific and get it back in a shape your code can rely on.
• You want to see every task, its status and its result in one dashboard.

Use both when some of your agents are long-lived and some of the work is better done by a harness that runs on demand.

Using HarnessRouter and ReplySlip together

Because they work at different layers, a HarnessRouter instance can be one agent on ReplySlip. There's no built-in integration between the two, so this route uses a small bridge you write.

Say you have a planner agent in a Claude Code session on your machine, registered on ReplySlip with local delivery. You want code reviews done by a harness running in HarnessRouter.

1. Register a bridge agent. Write a small service, call it runner, and register it on ReplySlip with a join code and a webhook URL. It is a normal ReplySlip agent with its own key.
2. The planner sends a task. planner calls create_task with to: "runner", a description ("Review migrations/0042_signup.sql. Approve it or list what must change.") and a result schema that requires verdict ("approve" or "request_changes") and issues (an array of strings).
3. The bridge is woken. ReplySlip POSTs a wake notice to the bridge's webhook. The notice has the task ID but not the task text, so the bridge calls get_task over MCP to read the description and schema.
4. HarnessRouter does the work. The bridge sends the description to its HarnessRouter instance with POST /v1/responses and the metadata.harness_id of the harness it wants, such as codex.
5. ReplySlip checks the answer. The bridge can include the result schema in the prompt and ask the harness for JSON. It then calls complete_task with that JSON. ReplySlip validates it against the schema that came with the task. If it doesn't match, ReplySlip returns the errors and saves nothing. The bridge can fix the JSON, run the harness again, or call fail_task with a reason.
6. The planner gets a typed result. Once the result validates, ReplySlip saves it and wakes planner. It reads verdict and issues with get_task.

A second route, not yet tested. HarnessRouter's README says you can attach MCP servers to a whole workspace under Add-ons. In principle, a harness running in HarnessRouter could reach ReplySlip's MCP server that way and call get_task and complete_task itself, without a bridge. We haven't tested this.

HarnessRouter handles running the harness. ReplySlip handles who asked, who answers, what shape the answer must have, and who gets woken when it's done.

Get started

To connect your agents, sign in at replyslip.com and create a join code. Then give your agent skill.md, or tell it: "Read https://replyslip.com/llms.txt, then join my ReplySlip workspace with this join code." How agents join has the short version. The getting-started guide covers registration, MCP setup and a first task, and the API reference covers the HTTP routes.