Triggering an AI agent instantly: Run now, @claude, and webhooks

Click Run now on a task, or write @claude in a comment on it — both create the same request, and Done delivers it to a connected agent instantly instead of waiting for its next scheduled check-in. If an agent is already streaming over MCP, it reaches that agent in real time; if nothing's connected, the request is queued as a durable row an agent picks up the moment it does connect, and Done can optionally fire a signed outbound webhook to a separate service so something can wake the agent up in the first place.

Why "it'll pick it up eventually" isn't always good enough

An agent that runs on a schedule — a nightly Routine, an hourly cron, a Claude Code session you kick off yourself — only sees what changed since it last checked in. That's fine for most work, but not for the ask that's actually time-sensitive: a blocker just cleared, a reviewer wants something turned around today, or you're looking at the board right now and want the next step started immediately, not at the next scheduled run. Triggers exist to close that specific gap.

Run now — the one-click version

Every task has a Run now button. Clicking it creates a trigger, and the response tells you honestly whether anything happened: "Delivered — an agent is listening" if a connected agent picked it up in real time, or "Queued — your agent will pick this up on its next connection" if nothing was there to receive it. Queued isn't shown as a failure, because it isn't one — a request nobody's connected to hear at 11pm is the normal case, and the whole point of recording it is that it's still there in the morning.

@claude in a comment does the same thing

Writing "@claude" in a comment creates the same request without leaving the conversation you're already having on the task. The parser is conservative on purpose: it strips code blocks and inline code first, so a pasted log line never fires it by accident, and it rejects an email address like ale@claude.ai and a different handle like @claudette — only the literal, standalone "@claude" counts. That's narrower than the handles Quick add recognizes when you're assigning a brand-new task to an agent in the first place (@agent, @claude, @chatgpt, and a few others all map to "assign this to an AI agent" there); for triggering an already-existing task, only @claude in a comment does it. An agent's own comment never triggers itself, either — writing "@claude" as the agent creates nothing.

What "delivered" actually means

Delivered means one specific thing: an agent's own authenticated connection to Done's live event stream was open at that exact moment. A human looking at the same task in a browser tab doesn't count — only a credential that authenticated as an agent, streaming right now, consumes a trigger's delivery. It's a deliberately strict definition, because "delivered" is a claim about what actually happened, not what should have.

When nothing's connected: queued, not lost

A trigger doesn't expire the moment nobody catches it. It stays open until an agent claims it, and it outranks ordinary queue order: an agent calling list_triggers sees every open request addressed to it — who asked, when, which task, and the instruction — ahead of whatever next_task would have handed it anyway. claim_trigger takes one atomically, so if two agents both check in around the same moment, only one of them ends up working that request.

Waking an agent that isn't running at all

list_triggers and the live event stream both assume something is at least intermittently connected. If nothing is — no cron has fired yet, no session is open — Done can notify a URL you register: an outbound webhook, fired the moment a trigger is created, that some other process (a small always-on service, a serverless function, whatever actually starts your agent) can use to kick a run off. It fires alongside the live stream push, never instead of it, so an already-connected agent isn't affected either way.

• Registering the URL is a human action inside Done, not something an MCP token can do — deliberately, since an agent that could point Done at a URL of its own choosing would have handed itself an outbound channel out of its sandbox.
• The payload is ids only: an event name, the task id, and the workspace id. No title, no notes, no instruction text. A leaked webhook URL, or a delivery that reaches the wrong host, learns only that a task id exists — the receiving agent still has to fetch the real content itself, over its own scoped MCP token, through the same access checks every other read goes through.
• Every delivery is signed — HMAC-SHA256 over the timestamp and body together, sent in X-Done-Signature and X-Done-Timestamp headers — so a receiver can verify it actually came from Done and reject anything replayed from an old delivery.
• The URL has to be https, and Done refuses to register one pointed at a private or loopback address.
• Deliveries are capped at 60 an hour per account with a 5-second timeout — a trigger is meant to be a human pressing a button, or an occasional @claude, not a firehose.

Setting up the webhook

Register a URL once from inside Done, and it hands back a signing secret at that moment only — stored hashed on Done's side, with no way to retrieve it again later, so copy it before navigating away. Replacing the URL rotates the secret, which doubles as the revocation story: point it somewhere else, or just stop trusting the old secret, without a separate revoke step.

What this doesn't change

Done is still a queue an agent has to ask, never a scheduler that reaches out and runs an agent's own tools on its own — none of this fires an MCP call on your behalf. What it solves is narrower: getting a request in front of a connected agent instantly instead of on its next poll, and giving something a way to wake an agent up when nothing's polling at all. Claiming, doing the work, and reporting back is still entirely the agent's own session, exactly like every other task.