AXME
Stop polling. Stop gluing webhooks. Use intent lifecycle instead.
Polling wastes compute and introduces lag. Webhooks require endpoint management, retry logic, and state reconciliation. Neither scales to 50 concurrent async operations.
Replace your polling loops, webhook endpoints, and retry middleware with AXME's durable intent model.
Polling wastes compute and introduces lag. Webhooks require HMAC, idempotency, backoff, and DLQ — often 200+ lines per integration. Neither scales to fifty concurrent async operations.
The hidden cost of polling and webhook farms
Polling loops are simple until you have fifty in-flight operations — CPU burns, dashboards lag, and race conditions appear when two pollers update the same row. Webhooks shift the problem to endpoint sprawl: HMAC verification, idempotency tables, exponential backoff, dead-letter queues, and reconciliation when a callback arrives twice — often 200+ lines per service pair.
AXME replaces both with a durable intent: submit once, observe lifecycle transitions, complete when work is done. Clients choose stream, poll, push, or inbox delivery — the receiver picks the mode; the sender does not maintain a webhook per consumer.
Example: order fulfillment pipeline
An agent charges payment, waits for warehouse API confirmation (minutes), then waits for carrier tracking (hours). Today: enqueue job, poll status table, webhook from warehouse, another webhook from carrier, custom retry on each — plus a cron to clean idempotency keys.
With AXME: one intent, WAITING_FOR_TOOL for warehouse and carrier, platform retries at the intent layer, completion via push or SSE — no while-not-done loop and no per-integration DLQ.
Webhook stack → intent lifecycle
Webhooks + poll
while not done: poll(job_id); sleep(30) # + POST /webhook, retry, DLQ
AXME
intent_id = client.send_intent({...})
result = client.wait_for(intent_id)SOLUTION
How teams solve this with AXME.
No polling
Lifecycle tracks completion.
No webhook farm
Delivery modes built in.
Retries included
At intent level.
Migration path
Identify the highest-churn polling paths first (approval status, long API jobs). Map each to submit + wait_for_tool or wait_for_time. Run AXME parallel to existing webhooks during cutover — see /migrate/from-webhooks/.
Retire per-integration state tables when intent history becomes the source of truth for ops and audit.
Common questions
- Do I still need webhooks at all?
- External systems may still callback; AXME can receive those as tool completions on an intent — you do not need a unique endpoint per workflow step.
- How do I observe progress in the UI?
- Subscribe via SSE stream delivery or poll intent status — same lifecycle, different binding.
- What about idempotency?
- Submit with idempotency keys at the SDK layer; intent state deduplicates duplicate submissions.
Related capabilities
Related links
Ship your first durable agent — in under 10 minutes.
Free tier. No credit card. Self-host or hosted — your choice.