Show HN: Mercury – No-code orchestration for human and agent teams(mercury.build)
mercury.build
Show HN: Mercury – No-code orchestration for human and agent teams
https://www.mercury.build/
6 comments
Honestly I don’t even bother with interfaces anymore as I really like using voice dictation with Whispr + Claude, feels much more natural.
But actually building these teams of agents is a thing I didn’t try yet. So would be interesting to see how the platform evolves to support power users like me.
But actually building these teams of agents is a thing I didn’t try yet. So would be interesting to see how the platform evolves to support power users like me.
Good news - we have a Mercury MCP! We have a setup prompt you can feed to your Claude Code allowing it to interact with other agents in your team - without you needing to visit the UI at all.
I have a workflow using the MCP where my OpenClaw talks with 3 hosted Claude Codes which text me PRs via iMessage
I have a workflow using the MCP where my OpenClaw talks with 3 hosted Claude Codes which text me PRs via iMessage
looks interesting... where do you draw the line between human in the loop and agents going all in?
all write actions are human-in-the-loop by default. these actions are sent to a user's inbox where they can approve/deny requests and also view the lineage of A2A conversations that led to the action being proposed. this has been super helpful for debugging agent teams without taking on any risk.
but if you want, you can configure 'fast mode' where you let your agents take all actions (read/write) without human approval.
but if you want, you can configure 'fast mode' where you let your agents take all actions (read/write) without human approval.
We spent the last year in deploying AI agents for teams in large enterprises. The agents themselves worked fine. The problem was managing them. You've got Claude Code in a terminal, a research agent in a browser tab, a Slack bot somewhere else, a scheduling assistant in yet another window. It's chaotic. There's no single place to see what's running, who's doing what, or how things connect. As the number of agents grows, this gets unmanageable fast.
Mercury is a canvas where you bring your agents and humans together in one place. You draw connections between them to form agent teams. An edge between Agent A and Agent B means A can delegate work to B — B processes the request, calls its tools, and replies. Agents can delegate further down the graph. The canvas becomes a living map of how your team operates.
Some details on the stack:
- Delegation as a primitive: when Agent A messages Agent B, it creates a persistent task. Tasks survive across activations so multi-step work doesn't lose context. - Agent types: native Mercury agents (Anthropic SDK / Claude), plus adapters for Claude Code, Devin, Manus, OpenClaw, Gumloop, and any MCP-compatible agent. Mix them on the same canvas. - 800+ tool integrations via Composio (Gmail, Calendar, Slack, Linear, Notion, etc.) with per-agent OAuth. - Channels: agents reach humans via the web UI, iMessage, or Slack. External triggers (new email, calendar event) can wake agents and kick off workflows. - Human-in-the-loop by default: agents need approval before real-world actions. You relax controls per-agent as trust builds.
We've been running Mercury on Mercury for months — 30+ agents supporting a 3-person team. Scheduling, sales ops, engineering triage, finance. The thing that surprised us most: the hard part was never getting a single agent to be smart. It was getting five of them to not duplicate work, not contradict each other, and not spam the same human with redundant questions.
We've raised $1.5M from a16z, with investors from OpenAI, Cognition, and others. We're opening up alpha access — if you're interested: mercury.build
One question we'd love the community's take on: where should memory live — in the orchestration layer or the agent layer? We started by managing memory at the org level, exposing it as tools or injecting it into agent context. But not all agents are created equal. Some handle memory well on their own, and we need to pick our battles. The role of the orchestration layer in memory management is one of the harder design decisions we're wrestling with, and we'd genuinely love to hear how others think about it.
We put together a short walkthrough if you want to see the UX before signing up: https://youtu.be/jpKvbyjkXMU
Happy to answer anything about the stack, the agent communication protocol, or the dumb mistakes we made along the way.