Somewhere right now, an engineering team is holding a retro about their AI agent. It worked in every demo. In production, a customer says it "just didn't do anything." The team is debating a prompt rewrite.
The logs tell a different story. The agent reasoned correctly. It chose the right tool. It made the call. The call timed out. Nothing retried it. The action never happened, no one was notified, and the model took the blame for a networking problem.
This is the most common agent failure we see, and no prompt will fix it.
Agents are event-driven systems wearing a trench coat
Strip away the novelty and an agent action is three steps: decide, act, confirm. The deciding gets all the attention. The acting is usually a bare HTTP call: fetch(url) and hope.
Backend engineers already know how this movie ends, because webhooks taught us. Networks fail. Endpoints rate-limit. Processes restart mid-request. The industry's answer wasn't smarter senders. It was delivery infrastructure: persistence, retries, idempotency, observability. Payments companies have run on it for a decade.
Agents have quietly inherited the exact same problem. Every tool call, callback, and notification an agent produces is an event that needs to arrive. And most agent stacks today deliver those events with less care than a 2015 webhook integration.
What a lost action costs
When a prompt is mediocre, the output is mediocre: visibly, immediately, fixably.
When a delivery fails silently, the cost is deferred and compounding. The customer wasn't notified. The workflow half-completed. And because fire-and-forget leaves no trail, there's nothing to debug: no status code, no attempt history, no way to distinguish "the agent decided wrong" from "the agent decided right and the network ate it."
That last distinction is everything. Without it, every infrastructure failure becomes an indictment of your model, and you'll spend your time tuning prompts that were never the problem.
The reliability checklist that actually moves the needle
None of this is exotic. It's the same discipline reliable webhook systems use, applied to agent actions.
Persist before you attempt. Write the event down before trying to deliver it. If the process dies or the deploy restarts, the intent survives and delivery resumes. Anything held only in memory is a coin flip.
Retry with backoff, and know when to stop. Most delivery failures are transient: a timeout, a 502, a rate limit. Exponential backoff resolves them without hammering the endpoint. A circuit breaker stops you from making a struggling endpoint worse.
Make retries safe. At-least-once delivery means occasional duplicates, so every send needs an idempotency key. In Mittr's MCP tools, mittr_send_event takes an idempotencyKey parameter for exactly this reason, so the model can retry a tool call without double-charging anyone.
Log every attempt. Status code, latency, response body, timestamp. "The webhook never arrived" should be a 30-second lookup, not a day of grepping.
Keep a replay button. Some events fail past any reasonable retry budget, like when an endpoint is down for a full hour. That should be recoverable, not fatal: dead-letter it, alert on it, replay it when the endpoint is back.
Correlate by run. Agent debugging has a dimension webhooks never had: one reasoning loop produces many actions. Tagging every event with a run identifier (agentRunId, in Mittr's case) means you can pull up everything an agent did in a single run and see precisely which action failed, when, and why.
Where the leverage is
Here's the argument in one comparison.
Improving your prompt makes the agent decide a bit better, some of the time. Improving your delivery layer makes every action the agent takes (every tool call, every callback, every notification) either arrive or leave a recoverable, visible trail. One is a marginal gain on the intelligent part. The other removes an entire failure class from the system.
Prompts are a craft. Delivery is a guarantee. Production systems are built on guarantees.
The boring ending
The uncomfortable truth about production agents is that the differentiating work (your product, your reasoning, your UX) sits on top of a pile of undifferentiated plumbing: queues, retry engines, dead-letter queues, audit logs, replay systems.
You can build that pile. Teams do, and it takes weeks to build and years to babysit. Or you can treat delivery as infrastructure, point your agent at it, and spend those weeks on the part of the system your customers actually see.
That second option is why Mittr exists. Your agent sends the event. We do the rest.
Mittr is delivery infrastructure for events, webhooks, and agent actions: persisted first, retried with backoff, logged on every attempt, replayable any time. Agents connect over MCP in one config block: docs.mittr.io/guides/ai-agents. The free tier is 3,000 messages a month, no credit card.
Top comments (0)