A step-by-step look at how mild.run pauses an MCP-compatible agent before a sensitive action, and only lets it proceed once a person approves.
Instead of an agent's own action tools, it calls an mild.run-gated tool — e.g. a refund, an email send, a Slack post — passing the same arguments it always would.
The call is held. mild.run creates an approval request with the full context (what, why, how much) and returns a pending status to the agent instead of executing immediately.
You get a message on Telegram, email or Slack with Approve/Block buttons. The agent polls or waits — up to a 24-hour window — for that decision.
If approved, mild.run performs the real action (calling Stripe, Gmail, Slack) and returns the result to the agent. If blocked or the window expires, it fails closed — nothing happens.
It means a person approves or blocks a specific tool call before it executes, instead of the agent's tool call running unattended. mild.run implements this as a drop-in MCP tool — the agent calls it exactly like any other tool, and a human decision gates the real side effect.
Yes — mild.run is exposed as a standard MCP server, so any MCP-compatible agent or client (Claude, custom agents, etc.) can call its tools without special integration code.
The underlying action (refund, email, Slack post) only executes after mild.run receives an approval. If the agent doesn't poll or the 24-hour window lapses without a decision, the action is treated as blocked — it never runs.
No. A chat confirmation only works while a human is watching the conversation in real time. mild.run works for autonomous or scheduled agents too — the approval request goes out over Telegram, email or Slack independent of whether anyone is looking at the agent's output.