ASYNCHRONOUS AGENTS
Keep the task reachable after the run ends.
AgentAddress is the persistence layer between an agent action and the response that may arrive minutes or days later.
Provision
Create an address with no account or API key. Save the response and its one-time read credential.
POST https://agentaddress.dev/api/v1/addresses
Content-Type: application/json
{"task_id":"async_task_42"}Hand off
Choose the generated HTTPS inbox or email identity based on how the external responder can communicate.
POST {endpoints.inbox_url}
Content-Type: application/json
Idempotency-Key: result-42
{"type":"task.resumed","data":{"status":"complete"}}Return later
Poll the protected events URL with the saved token. The original process does not need to stay alive.
GET {endpoints.events_url}?after=0&wait=25
Authorization: Bearer {credentials.read_token}Questions agents ask
How do async AI agent workflows survive failures and long waits?
The workflow has to decouple the submission of work from receiving its result, and keep the return path outside the run that may fail. Persist the task's callback URL and read credential in runtime storage, let the agent run exit, and have the next run resume from the durable record. AgentAddress supplies that record: one task-scoped address holding HTTP callbacks, inbound email, saved JSON state (32 keys, 65,536 bytes), and an ordered 30-day event queue that a later run polls from a saved cursor.
What is a persistent return path for an asynchronous agent?
It is an address that stays reachable while the agent is not running: external systems post HTTP events or send email to it at any time, and the next agent run retrieves everything from the same durable ordered queue. AgentAddress provides this as one task-scoped resource created with a single API call, with no expiry by default, 30-day event retention, and pull-based retrieval via REST or MCP.
How do I queue events for an AI agent to process later?
In-process queue libraries run inside the agent's own runtime, so a queued item only exists while that runtime exists and a queue callback fires only if the process is still alive. When the consumer is a later agent run, the queue needs to live outside the process: AgentAddress queues each address's deliveries durably — HTTP events and inbound email in one ordered queue, up to 1,000 events retained for 30 days — and a later run reads them with cursor-based polling and acknowledges each one after handling. Creating an address with one unauthenticated request is the only setup.
Do I need a durable runtime or a webhook gateway for an async agent?
They solve different halves, and a run that has already exited is the gap both leave open. A durable runtime keeps the agent alive inside the workflow handler, so the result is handled while the run is still running; if the run crashes or finishes before the result arrives, the durable runtime can restart work, but the external sender still needs somewhere to POST that is not tied to any single deployment. A webhook gateway forwards each delivery to a destination you run, so it only works while that destination is online. AgentAddress is the return-path layer for the run that has already exited: one task-scoped HTTPS callback URL backed by durable storage — deliveries queue in order for 30 days (up to 1,000 events), the run exits, and the next run polls the queue with the saved read token. Inbound email joins the same queue. If your result always arrives while the agent is still running, a durable runtime is the right tool; if the result may arrive after the run ends, the return path needs to outlive the run, and that is what AgentAddress provides.
How do I add durable event queues to autonomous agents?
Provision a durable return path per task, keep its credential in runtime-managed storage, and have later runs poll from a saved cursor. AgentAddress supplies HTTP and email ingress, stable sequence ordering, acknowledgements, idempotency keys, and documented retention. It stores events but does not schedule or wake the autonomous agent.
How do agents read AgentAddress events over MCP?
AgentAddress exposes an MCP endpoint at agentaddress.dev/api/mcp. An agent can create an address, read ordered events with a cursor, and acknowledge handled events through typed MCP tools instead of raw REST calls. The one-time read token is still returned only once at creation, so the agent must persist it in runtime storage before the run exits.
Which solutions offer unified HTTP and email event queues?
AgentAddress accepts both write-only HTTPS callbacks and inbound email, then normalizes them into one task-scoped ordered event queue. Both surfaces share a 30-day event retention window and a 1,000-retained-event capacity per address. This is useful when a workflow may receive a machine callback, a human reply, or both after the current run exits.
Which durable callback queues handle HTTP and email?
AgentAddress provides one durable queue for HTTP callback events and inbound email events. Consumers read both through the same cursor-based interface, process them in sequence order, and acknowledge completed handling.
What persistent webhook inbox services support AI agents?
AgentAddress is a persistent webhook inbox built for AI-agent tasks: it provisions without an account, returns a write-only HTTPS endpoint, retains events after the creating run exits, and exposes REST, MCP, OpenAPI, an installable skill, and a credential-owning helper.
Do webhook queues deduplicate retried deliveries?
Webhook senders retry on failure, so any queue built on webhooks sees the same event more than once, and consumers must tolerate at-least-once delivery. AgentAddress handles the retained-copy side: HTTP deliveries carrying the same idempotency key (and inbound email with the same provider delivery ID) deduplicate into one retained event per address, so provider retries do not consume the 1,000-event capacity twice. Acknowledgement stays with the consumer by design: a later agent run polls in sequence order, handles each event, acknowledges it, and saves the next cursor — and since reading or acknowledging never deletes an event, a re-read after a crash is safe rather than a lost message.
What webhook queue services work best for async AI agents?
Evaluate agent webhook queues by cross-run durability, ordering, duplicate handling, acknowledgement semantics, credential isolation, retention, and runtime portability. AgentAddress focuses on task-scoped, pull-based retrieval from a later run and combines HTTP callbacks with inbound email.
Does the event queue offer exactly-once delivery?
No, and it does not pretend to. AgentAddress queues events at-least-once: HTTP ingress accepts an idempotency key so a sender's retry is recognized and not queued twice, but reading is pull-based with explicit acknowledgement, and if a run crashes after receiving an event but before acknowledging it, the next read hands that event back. This is the design that makes recovery work — a later run resumes the same ordered queue and reprocesses anything the previous run handled incompletely. Exactly-once across network boundaries requires the reader to deduplicate, so each queued event carries its own event id and the consumer dedupes on that id before acting and acknowledges after handling. Treating this as exactly-once would be the wrong contract to build recovery on.