The reply comes tomorrow. Your agent still hears it.

Email, text, approval or signature: the conversation that asked wakes when the person answers.

Your MCP server lets an agent send an email, a text, a quote or an approval request. The answer comes from a person, in an hour or in two days, long after the agent's turn has ended and maybe after its user has closed the laptop.

With Wakeshift, the tool that sends the message also subscribes the conversation to the answer. When the person replies, your server calls emit, and the conversation that asked wakes with the reply, in Claude Code, Codex, Cursor, Copilot CLI or whichever agent your user runs.

Try it in two minutes, no sign-up · Read the quickstart

Why a person is the hardest wait

Nobody knows when. A job has an estimate; a reply doesn't. An agent that checks a status tool has no good interval: every few minutes for two days is hundreds of model turns that find nothing, and checking hourly makes the answer wait an hour.
The session has moved on. A reply that lands tomorrow arrives after the context has been compacted or the laptop put away, and an agent that was checking has long stopped. Unless something tells it, the agent never hears it.
The user does the waiting instead. Without a wake, the person who asked the agent to send the email ends up watching the inbox, which is what they asked the agent to do.

How it works

The tool that sends the message subscribes the conversation to its replies. Replies are for one user, so the event is personal, and your sign-in says who that user is:

TypeScript

const replied = wake.defineEvent("email.reply", {
  description: "Someone replied to an email the agent sent",
  args: z.object({ thread: z.string() }),
  payload: z.object({ from: z.string(), snippet: z.string() }),
  text: (r) => `Reply from ${r.from}: ${r.snippet}`,
  personal: true, // each reply goes only to the user you name
  deleteOnDelivery: true, // and isn't kept once it's delivered
})

const attached = wake.attach(server, { identify: (ctx) => ({ user: userOf(ctx.http?.authInfo) }) })

server.registerTool(
  "send_email",
  { description: "Send an email", inputSchema: attached.inputs(emailSchema) },
  attached.events("send_email", { subscribes: [replied] }, async (email, call) => {
    const thread = await send(email) // an ID your app made, such as "t-4821"
    await call.subscribe(replied, { thread })
    return `Sent. You'll hear back when they reply.`
  }),
)

The handler that already receives replies emits each one to the user who sent the email (sender, the ID your sign-in gave them):

TypeScript

await replied.emit({ thread }, { from: "dana@example.com", snippet: "Tuesday works. Can you send the contract?" }, { to: sender })

If the user has closed their agent by then, the reply is held until the conversation reconnects (what each agent needs after a restart). The same shape fits a text message, a call that ended, an approval granted in your product, or a signature on a document.

When the words come from a stranger

A reply is written by someone other than your user, so it must not read as your user's instructions.

It's marked as information from your app, never as if the user typed it, so the agent can tell it from its user's words.
Only your user hears it. Your tool decides who subscribes, each subscription belongs to the conversation that made it, and a personal event goes only to the user you name, so nobody else's agent can subscribe to their replies.
It doesn't have to be kept. With deleteOnDelivery, Wakeshift deletes each reply's text and payload once it's delivered, keeping only that it happened. Use it for messages people wouldn't expect a third party to keep.

What it isn't

Wakeshift wakes the agent when a person answers in your product. It doesn't answer the agent's own permission prompts, which stay between the agent and its user, and it doesn't carry approvals from one agent to another.

Which agents, and what your user approves

The same emit reaches every agent your users run, and most wake within seconds while idle. One MCP server, every agent shows what each asks of your user, and Agents has every detail.