I’m happy to partner with Svix on this newsletter.
Agents are killing your apps with compounding polling across workflows.
Your customers want their agent workflows to be efficient, so you’re losing deals if you don’t make them event-driven. Webhooks solve this issue, but implementing them is harder than it looks.
If you homebrewed your webhooks and are getting pinged at 4 in the morning for failed deliveries, this is for you.
Svix handles everything: retries, idempotency, security, and compliance. Qualified startups get $12,000 in free credits.
If you’ve used an AI agent1, you’d have noticed how much it can do on its own…
Give it a task; it calls a few tools, then keeps going without you guiding every step.
But agents still are NOT good at one thing: waiting.
An agent would wait for someone to approve a request, a payment to go through, a deployment to finish, or a customer to reply. The agent has done its part, but what it’s waiting for might happen seconds later or not until tomorrow…
It could keep checking for an update every few seconds, but this’d become “wasteful” pretty quickly. i.e., the agent is still doing nothing except asking whether anything has changed.
A better approach is to let the system send an event when the change actually occurs. So the agent does not need to keep asking & continues the workflow when the event arrives.
This is where “webhooks2” become useful.
It lets one system notify another when something happens, and it's been running behind many apps you use daily, long before AI agents needed it.
Now apply that to everything an agent would wait on: payments, deployments, customer replies, or human approval.
Plus, handling one of these events is easy. Yet handling thousands of them reliably across different customers & external systems gets extremely HARD…
In this newsletter, we’ll use Svix as a case study & look at how it solves this problem.
(Svix is a webhook infrastructure platform for reliable event delivery.)
§
Share this letter & I’ll send you some rewards for the referrals.
Onward.
§
What Is a Real-Time AI Agent
What changes with a real-time agent is not how it thinks, but what it hears.
Let’s start with what an agent needs before getting into real-time…
Agent Fundamentals
Agents (real-time or not) run on these same parts:
A Large Language Model3 (LLM) does the actual reasoning.
A decision loop4 lets it plan a step, take it, check the result, and decide what comes next.
Tools & integrations let it act beyond generating text, such as sending requests, running commands, and/or calling APIs.
State tracks where it is in a task, so it doesn’t lose the thread halfway through.
Without these pieces, you’re getting closer to a simple model response than an agent that can carry out a task.
Real-time is the layer on top of this…
What Makes an Agent Real-Time
A typical agent workflow starts when you give it a task.
It works through steps, uses whatever tools it needs & eventually finishes…
With a real-time agent, the work doesn’t end there. An external event could arrive after the original run ends, and the agent needs to resume the workflow when it does.
A payment could clear somewhere in the background a few minutes after the agent finished its original task. Instead of waiting for you to come back & tell it, the agent could receive the event5 and continue the workflow on its own.
It can pick a workflow back up without another prompt from you. Nobody needs to open a new chat/type anything. An agent does the asking instead.
And it can act on something arriving well after the original task ended. The original agent run might already be complete by the time the event arrives, and the agent still has to do something with it.
Also this brings up “latency”…
A real-time agent is NOT necessarily instant.
Latency occurs at several points in the workflow:
Network adds some delay,
Model takes time to reason,
Tools & external APIs take time to respond.
So when we talk about a real-time agent, we’re really talking about keeping the entire path “responsive”, not just getting a fast response from the model.
If you put these together, a real-time agent isn’t just running one job well. It’s also sitting ready for whatever comes in later, on somebody’s schedule.
Now let’s look at how these pieces actually work together inside the agent…
§
Real-Time AI Agent Architecture
A real-time agent is not one piece of code that does everything.
Instead, it’s a handful of layers, each with a different job…
The model handles the reasoning, deciding what to do next based on what it currently knows. Everything else in the agent supports this decision. It takes in input, takes action, and catches external events as they happen.
Here’s what each layer does:
Interaction: Receives input from you/another system.
Agent & reasoning: Runs the model & its decision loop.
Tool & integration: Performs actions on external systems.
Event delivery: Brings external events into agent workflow.
The agent & reasoning layer runs the model and its decision loop.
The other layers support it by bringing in input, carrying out actions & delivering external events.
Synchronous vs Asynchronous Workflows
Some operations finish immediately…
Ask to look up an order status & tool call returns the result within the same run.
Other operations don't finish right away…
Processing a file could take a minute. A payment can take a few seconds to clear, sometimes longer. An approval can sit unread for two days.
Synchronous operations return their result within the same run, so the agent could use it right away. Asynchronous operations don’t, and the workflow needs to continue once the result becomes available later.
When the result becomes available, the event gets delivered to the application, which then updates/resumes the agent’s workflow.
Let’s see how the event actually reaches the agent in the first place…
§
§
How Real-Time AI Agents Connect to External Systems
When an agent needs to react to something happening in another system, a webhook is one of the simplest ways to get the event to it.
One system notifies another when something happens. i.e., the receiving side does not need to check for changes repeatedly.
Webhooks are built for “discrete” events, not continuous streams of data.
A payment clearing counts as one. So does a build finishing or an approval landing in someone’s inbox. This is exactly the kind of event an agent needs to hear about to move a workflow forward.
The idea is simple, but it helps to see what actually happens when one of these events gets sent.
So let’s look at how webhooks work...
How Webhooks Work
Here’s how:
An event occurs in the source system.
Source sends an HTTP POST to a configured endpoint.
The receiving application verifies the event & triggers the appropriate workflow.
Sender records6 whether delivery succeeded/failed.
Four steps, each depending on the last.
If you skip verification, anyone can send a fake event to the endpoint. Or if you skip recording the result, a failed delivery disappears without anybody noticing.
Webhooks work well for individual events, but real-time systems also deal with continuous information streams.
Streaming vs Webhooks
Real-time systems typically handle information in 2 ways:
It keeps flowing continuously,
Or it gets sent when a specific event happens.
Streaming is useful when information needs to keep flowing.
A voice conversation, a live transcript, or an agent response generated token by token all need a connection that can keep data flowing.
Webhooks solve a different problem.
They’re useful when something happens outside the agent, and the agent needs to know about it. The event happens once, and the system sends a notification instead of making the agent keep checking.
For real-time AI agents, both matter.
Streaming keeps the user interaction responsive.
Webhooks handle everything happening around the agent that needs a response later.
As the number of events and external systems grows, delivering those events reliably becomes hard.
Someone has to handle failed requests, retries, duplicate deliveries, and track what was delivered & what wasn’t.
Svix handles this part of the stack…It provides the infrastructure for delivering webhook events to external systems, while the application stays focused on the agent itself.
Let’s understand the challenges of running webhook infrastructure reliably…
§
§
Challenges of Building Real-Time AI Agents
A webhook integration usually works fine in testing…
You send an event, watch it arrive & everything looks good, so you move on.
Once you put it into production, things change. Servers go down mid-deploy, networks drop packets for reasons that aren’t always obvious, and traffic suddenly comes in bursts instead of at a steady rate.
None of these things are unusual in production, but they expose problems that you simply don’t see when you’re testing with a handful of events.
Most of the problems fall into a few recurring areas.
Let’s dive in!
1. Reliable Delivery
An endpoint could go down during a production deploy…A webhook sent during that window then has nowhere to go.
You send it once and give up, and the event is gone. Whatever depended on it--an agent waiting to continue a workflow, or a customer expecting a receipt--never finds out anything happened at all.
Retries handle this; not by hammering the same failing endpoint over & over.
Each attempt waits a little longer than the last, giving a struggling server time to recover before getting hit again. The event itself needs to sit somewhere durable while all this plays out too, so a crash on the sending side doesn’t erase it along the way.
And if every retry eventually runs out, the event needs somewhere to land instead of vanishing without a trace.
2. Security and Verification
Anyone who has the webhook endpoint’s URL could send a request.
Nothing about the endpoint itself tells the difference between a real event & someone typing curl commands.
This is why legitimate events get signed before they’re sent. The receiving side checks the signature7. A mismatch rejects the event, thus preventing forged events. A timestamp on the request helps prevent an old, legitimate request from being captured & resent later. Also signing secret needs to be managed & rotated over time without breaking existing endpoints.
One risk lies on the sending side instead…
Sending a webhook means requesting a URL provided by someone else. An unchecked URL could point somewhere it should not, such as an internal system instead of a real customer endpoint.
Guarding against it matters as much as verifying what comes in.
3. Idempotency and Duplicate Events
Occasionally, an agent does everything right & still sees the same event twice.
It is NOT a bug. A delivery succeeds at the receiving end, but the confirmation gets lost on its way back to the sender. The sender has no way to know the event actually landed, so it tries again, and the same event arrives twice.
For most systems, a duplicate log entry is harmless.
Yet for an agent taking real action, it isn’t. Processing the same payment confirmation twice can mean sending a receipt twice, or worse, acting on the same instruction twice. A stable ID attached to every event, unchanged across every retry, lets the consumer tell the difference.
See the same ID again, skip it & move on.
4. Backpressure, Traffic Bursts, and Isolation
Two hundred events landing over an hour looks nothing like two hundred events landing in the same second.
Agents create this kind of burst when they run many tasks in parallel.
An agent could start 200 tasks at once. If many finish around the same time, they could generate a burst of completion events instead of a steady stream.
A slow-responding endpoint quickly becomes a bottleneck.
Deliveries pile up, and the backlog can spread into the rest of the system. Throttling8 keeps this contained by limiting how fast events go out to any one destination.
Plus, isolating each endpoint from the others matters just as much, so a single customer’s bad day never becomes everyone else’s.
5. Event Ordering
Two letters mailed on the same morning don’t always arrive in the order they were sent…One gets held up somewhere, and the other doesn’t.
Webhook events work the same way.
Update a subscription, then cancel it a moment later. The update event might fail and get retried while the cancellation goes through immediately. The cancellation shows up first. An agent would assume events always arrive in order. If an update arrives late, it’ll process it last and believe a canceled subscription is still active.
Consumers shouldn’t assume events will always arrive in order.
Handling this well means checking each event’s timestamp/version number before acting. This is safer than trusting the order in which events arrive. When strict ordering matters, you can enforce it by controlling how events get processed.
This could add latency & delay later events.
6. Observability and Recovery
When a customer says an agent never responded to their approval, what’s the actual answer?
Without logging, there isn’t one. Nobody can say whether the event got sent, whether it arrived, or what happened after. A working system tracks every delivery attempt, the response it got, and each endpoint's current status.
This turns a vague complaint into something checkable, an exact record of when an event went out, what came back, and how many times it was retried. And once whatever broke gets fixed, replay9 sends the same event again, closing the gap instead of leaving it there permanently.
Delivery, security, duplicates, bursts, ordering, visibility (and so on) need someone to solve each of these. You can build them yourself or use existing standards and infrastructure to handle the pieces you don’t want to own.
Let’s look at what a production-ready webhook needs to provide…
§
We are in the middle of the agentic AI era, please take advantage of it
Agents can crush your app with compounding latency across workflows.
Your customers expect fast, efficient agent workflows. But if your agents keep polling for updates, you risk losing deals. Webhooks make workflows event-driven, but building reliable webhook infrastructure gets complicated fast.
If your homegrown webhooks have you waking up at 4 AM to fix failed deliveries, there’s a better way.
Svix handles retries, idempotency, security & compliance for you.
Qualified startups get $12,000 in free credits.
§
What Real-Time AI Agents Need to Stay Reliable
You still need to handle all these problems when you put a real-time agent into production.
You need a consistent way to identify events, verify their source, and make sure old requests can’t be reused.
This is where standard webhooks help. It gives you a common way to handle the security and verification side of webhook delivery, instead of having to define your own format and rules.
Let’s start with how a webhook gets identified & verified...
Webhook Identity and Signatures
Every webhook carries a unique message ID, a timestamp showing when it was sent, and a signature that verifies its authenticity.
The signature itself uses HMAC-SHA25610.
It runs over the ID, timestamp, and raw payload11 together, using a secret known only to the sender and receiver. If you change even one character in the payload, then the signature no longer matches.
A receiver uses the same verification logic for any provider following the standard.
For an agent workflow, this means the application could verify an event before allowing it to trigger another action.
Replay Protection and Key Rotation
A valid signature proves a request came from the sender…yet it doesn’t prove the request is new…
Without a timestamp check, someone who captures a real request could resend it days later, and the signature would still pass. The receiver could enforce an acceptable timestamp window12. This ensures a captured request eventually stops being usable.
Also secrets need to change occasionally, and a receiver still verifying against the old one shouldn’t break during the transition. The spec supports multiple signatures during secret rotation. This lets a receiver verify requests using either the old/new secret during the rotation window.
For an agent workflow, this matters when an event could trigger an action.
An old signed request shouldn’t be accepted as a new event just because its signature is still valid.
Standardized Webhook Format
A provider following the standard uses the same headers & signing format.
Consumers could use one verification implementation across providers.
This is what makes interoperability13 possible. A team building a receiver can use one verification path for events from different providers. There is no need to write custom logic for each one.
Following the spec doesn’t remove the need for infrastructure behind it, though. Something still has to run the queues, retries, and delivery logic day to day.
Let’s look at how Svix puts them into practice & handles the infrastructure behind real-time AI agent events...
§
Svix: Platform That Connects AI Agents to Outside World
Every piece covered so far, including retries, signing, replay, ordering, and observability, has to actually run somewhere. None of it is optional once real customers depend on your agent reacting to real events.
Svix is built to be this somewhere.
Your application decides when something happened & creates the event.
Svix handles delivery, including retries, security, and everything needed to get it to the right place reliably.
How Svix Models Webhooks
Svix tracks these for each webhook it sends14:
Application: customer/tenant on your platform.
Endpoint: actual URL to which you’re sending the event.
Message: event itself.
Event type: kind of event, such as a payment clearing or a task finishing, and determines which endpoints receive it.
An application could have many endpoints…One event can reach several destinations, and you can use event-type subscriptions to control which events an endpoint receives.
How an Event Moves Through Svix
There are two ways events move through a real-time agent system15:
1. Outbound events
The agent or application produces an event when something happens.
This could be a tool call finishing or a workflow reaching a new state. The application sends that event to Svix through the API, and Svix delivers it to the configured downstream endpoints.
2. Inbound events
Something happens in an external system, and it sends an event back to the application.
Svix Ingest16 receives incoming webhooks. The application then processes the event and decides what the agent should do next. This could mean starting a new workflow or continuing one that was waiting for that event.
In both cases, the delivery happens separately from the agent’s main workflow.
The application doesn’t need to keep a connection open while the event is being delivered. It can keep the workflow state & handle the event when it arrives.
Queues, Workers, and Storage
Behind the scenes, events go into a queue17 before they're delivered.
Once Svix accepts the event, separate workers handle delivery instead of making your application wait for it to finish.
The message & its delivery state are stored along the way. This means a temporary problem at the destination doesn’t make the event disappear. You can retry or recover the delivery without keeping the original request open.
For an agent workflow that suddenly produces a hundred events at once, this matters.
Your application can hand those events to Svix without waiting for every downstream request to finish, while the delivery system works through them independently.
How to implement Svix
There are a couple of ways to get events into Svix18:
The simplest approach is to send them directly from your application whenever something happens. If you already have your own event system and/or queue, you don’t have to replace it. You could have the system forward the events to Svix when they’re ready to be delivered.
From there, you can create the applications, endpoints, and event types you need through the Svix API. The application represents the customer/tenant; endpoints define where their events should go, and event types describe the kinds of events they could receive.
Also you could give customers control over their own webhook setup through the Svix Application Portal. So they manage their endpoints and inspect delivery activity themselves, rather than coming back to your team every time something needs to change.
Reliable Delivery
The normal delivery path is straightforward when the destination is “healthy”…The harder part happens when it is not…
An endpoint could be down during a deployment, take too long to respond, or start returning errors for a while. Svix retries failed deliveries with backoff, giving the endpoint some time to recover instead of repeatedly sending requests at full speed.
If an endpoint keeps failing after retries are exhausted, you can recover the delivery once the underlying problem gets fixed.
Security and Outbound Delivery
Every event Svix sends gets signed…
So the receiving application could verify the webhook actually came from the expected sender & has not been changed in transit. Also Svix includes a timestamp with the request. This could be checked along with the signature to prevent an old, valid request from being captured & replayed later.
Signing secrets need to be changed from time to time as well.
Svix supports secret rotation by signing deliveries with both the old and new secret for 24 hours, thus giving endpoints time to switch to the new secret without interrupting delivery.
Also there is a risk on the other side of the connection.
Svix is making outbound requests to URLs provided by your customers, so those URLs can’t simply be trusted to point wherever they claim. Svix includes protections against server-side request forgery (SSRF19).
This helps prevent a webhook endpoint from reaching internal services or other destinations it shouldn’t be access20.
Observability and Scaling
When a delivery fails, knowing that it failed is only the first part.
You also need to see what was sent, when it was sent, what the endpoint returned, and whether another attempt was made. Svix keeps a record of delivery attempts and their results, making it easier to see which endpoints are working & which ones need attention.
As the number of events & endpoints grow, some systems also need more control over how those events are delivered.
Svix supports ordered delivery when event order matters, throttling when a particular endpoint shouldn’t receive events too quickly, and payload transformations when different consumers need the same event in a different format.
Plus, it supports multi-region delivery for setups with regional or data residency21 requirements. These aren’t things every agent needs, but they become useful when the same event infrastructure has to serve larger or more distributed systems22.
§
§
How Realtime AI Agents Handle Events and Actions
Let’s look at what happens on the agent’s side once one of these events arrives…
Tool Calling and Asynchronous Actions
The model does not actually run the tool; your application does23.
It decides which one to call & what to pass into it. Most of the time, the result comes back before the model finishes forming its next sentence.
It isn’t always this quick, though…
Waiting on a slow third-party API or generating something heavy like a video can take minutes instead of seconds. And the application cannot keep the connection open for the entire process.
Once the result is ready, a completion event can tell the application to continue the workflow. The application can use the workflow/run ID stored with the agent’s state to find the right workflow and resume where it left off.
This event still needs reliable delivery to arrive successfully.
It uses the same durable delivery and retry logic covered earlier, but the trigger is a finished tool call instead of an external webhook.
Agent Workflows and External Events
An agent can also have workflows that depend on something happening outside its own application.
It might start a task and then wait for an external event before it can continue. Instead of constantly checking for updates, the agent can wait for that event and continue when it arrives.
For example, a coding agent might be waiting for an update to an issue before it can continue. Once that update arrives, the application can use the event to decide what the agent should do next.
Svix Ingest handles the incoming side of the workflow.
External systems send their webhooks to Ingest, which receives and verifies them before passing them to the application. The application can then use the event to start or continue the agent’s workflow.
As an agent works with more external systems, one place to handle incoming events means you don’t need separate webhook handling for each integration.
Human-in-the-Loop Agents
Some decisions genuinely need a person behind them, not just an agent’s best guess24.
Say an agent drafts a refund & needs someone to sign off before it actually goes out. It sends an event asking for approval and delivers it wherever the approver already works. This could be a Slack channel, an internal dashboard, or whatever’s already set up. The approval might not come for a day.
Once it does, the response comes back as an event too, and the workflow picks up right where it left off. Svix handles the delivery side by retrying failed deliveries and keeping a record of each attempt.
This means an approval sitting for a day doesn’t quietly vanish in transit.
Local and Ephemeral Agents
Not every agent has a public URL sitting around waiting for traffic.
One running on somebody’s laptop, or spun up for a single task and torn down right after, usually has no stable endpoint for a provider to send a webhook to. Setting one up just for this rarely makes sense & sometimes isn’t even possible depending on where the agent runs.
Polling gives the agent another option.
Events arrive through Ingest, but the agent retrieves them when it connects instead of exposing a public webhook endpoint. It reaches out on its own schedule, using an existing outbound connection.
And it pulls whatever is waiting instead of needing somewhere for events to land25.
Designing Events for Agents
Most of what an agent does internally never needs to become an event26.
Whether a task actually finishes or an approval is requested matters more than every small decision along the way.
Naming matters here too:
agent.task.completed tells anyone downstream exactly what happened. Something vague doesn’t, and now whoever’s consuming it is guessing. Svix keeps these event types in a catalog, so people integrating with your application can see which events are available & what they represent.
Keep the payload limited to what a consumer actually needs. Version it if the shape changes, so existing consumers keep working.
All of this can be built by hand. At some point, though, it stops being a quick addition and turns into its own piece of infrastructure to maintain.
Let’s see how much of this infrastructure you actually want to own, and how much makes more sense to buy…
§
Build vs Buy for Realtime Agent Infrastructure
Building a webhook endpoint yourself is not hard when it’s just your own systems talking to each other27.
One service sends a request, another receives it, and if something breaks, you notice & fix it. Yet once a customer is on the other end of this connection, the requirements start to change. Now they’re the ones who notice when a delivery fails, and they have no visibility into why or how to fix it.
A bug you’d normally get to eventually becomes a support ticket showing up today.
Handling a webhook for something internal is a tiny problem.
But handling it for a customer, reliably and at scale, is a much bigger problem. It’s worth being honest about which problem you’re actually solving before picking a path. The decision isn’t really about whether you can write a webhook endpoint.
It’s about how much of the surrounding infrastructure you want to own and maintain.
Build Path
Building your own makes sense in a few specific situations:
Event volume is low, and only a handful of internal systems ever receive anything.
Requirements are specialized enough for no general-purpose tool to genuinely fit.
Reliability concerns, retries, durability, and observability are already handled by infrastructure you’re running for other reasons.
Webhook infrastructure itself is part of the core product you’re building, not something supporting it.
None of these are edge cases nobody hits…Plenty of people genuinely sit in this exact spot, at least for a while.
When Buying Makes Sense
A simple webhook is enough for a small internal setup.
The need for managed infrastructure comes when those events become part of a customer-facing product & you need more control over delivery:
Customers receive these webhooks, not just an internal system.
Endpoints and integrations multiply past what’s easy to track by hand.
Reliability & observability stop being nice extras and start being expected.
Engineering time spent maintaining webhook infrastructure is time not spent on your actual product.
As the number of customers and integrations grows, so does the amount of infrastructure around each one.
Each customer has its own endpoint and delivery requirements. Also you need to handle delivery failures & ensure events arrive reliably.
The first webhook endpoint is easy to build.
But the work piles up when you add retries, security, replay, observability, and a customer-facing portal. The challenge grows as you keep all those pieces working together. This cost doesn’t show up on day one. It shows up gradually, as more customers sign up and more reliability work gets pushed down the backlog.
It looks like nice-to-have work and never quite gets done.
Whichever path fits, the underlying job doesn’t change. Something still has to ensure an event actually reaches the agent when it’s supposed to.
§
Closing Thoughts
A real-time agent feels almost ordinary once everything works.
It just seems to know what to do next, picking a workflow back up the moment something changes, with no one having to nudge it along.
But beneath that smoothness runs an entire delivery system quietly in the background. Every piece covered here exists to ensure an event reaches the agent every single time. No one needs to think about the machinery behind it.
At this point, you should have a clear picture of what’s actually holding this together:
Webhooks are the mechanism, notifying the agent the moment something happens instead of making it check over and over
Reliable delivery, security, idempotency, ordering, and observability are what turn a single HTTP request into something production can actually depend on
Standard webhooks give senders and receivers a shared way to identify and verify events, instead of every provider inventing its own format.
Svix runs this entire delivery layer, so building an agent doesn’t also mean building a second system just to keep it connected to the world around it.
Once you see it laid out this way, a real-time agent stops looking like one clever piece of code… It’s a model wired into a delivery system built specifically to make sure nothing it’s waiting on ever slips through.
Agents will only take on more of this over time.
They will wait for more things to happen outside the conversation. They will also react to more of them with nobody watching. And the more an agent takes on, the more its reliability depends on one thing nobody notices until it breaks.
The events it waits for must actually show up.
§
Make your agents realtime
Slow agent workflows kill the user experience & can cost you deals.
Polling adds latency at every step. Webhooks let your agents react to events as they happen, but building reliable webhook infrastructure means dealing with retries, failed deliveries, security & compliance.
If your homegrown webhooks keep breaking and waking you up at 4 AM, Svix handles the hard parts for you.
Retries, idempotency, security & compliance are built in.
Qualified startups get $12,000 in free credits.
If you find this newsletter valuable, share it with a friend, and subscribe if you haven’t already. There are group discounts, gift options & referral rewards available.
Want to reach 250K+ tech professionals at scale? 📰
If your company wants to reach 250K+ tech professionals, advertise with me.
Thank you for supporting this newsletter.
You are now 250,001+ readers strong, very close to 251k. Let’s try to get 251k readers by 7 October. Consider sharing this letter with your friends & get rewards.
Y’all are the best.
An AI agent is a system that uses an AI model to reason about a task, decide what to do, and take actions through tools and/or external systems to achieve a goal.
You ask it something, and it doesn’t just answer once and stop. It reasons through the problem, decides what to do next, and keeps going until the task actually gets done. Along the way, it can call tools, read files, hit an API, or whatever the job needs.
A mechanism that allows one system to automatically send an HTTP request to another system when a specific event happens, instead of requiring the source-receiving system to repeatedly check for changes.
An AI model trained on large amounts of data that can understand and generate text. In AI agents, LLMs are used to reason about a task and decide what to do next.
The repeated process an AI agent uses to decide what to do, perform an action, examine the result, and decide what to do next.
A signal that something has happened, which can trigger an application or agent to take action without someone having to ask it again.
The sender uses the HTTP response status to determine whether the delivery attempt succeeded or failed.
A cryptographic value attached to a message that allows the receiver to verify that it came from the expected sender and was not modified.
Throttling means limiting how fast requests or events are sent to a destination.
For example, suppose your system suddenly has 1,000 webhook events ready to send, but the receiving endpoint can safely handle only 100 requests per second.
Without throttling:
1,000 events → sent immediately → endpoint may overload
With throttling:
1,000 events → max 100/sec → endpoint
The remaining events wait and get delivered as capacity becomes available.
The process of sending a previously delivered event again, usually to retry processing it after a failure or other issue has been fixed.
A method for creating a cryptographic signature using a shared secret and the SHA-256 hashing algorithm. It allows the receiver to verify that a message came from someone who knows the shared secret and was not modified.
The exact original data sent in a request before it is parsed, reformatted, or otherwise modified by the receiving application.
An allowed period around the time a webhook was sent during which the receiver will accept the request. Requests outside this period can be rejected to reduce the risk of replay attacks.
The ability of different systems or services to work together using shared standards or interfaces.
Think of Svix like a mail delivery system for events.
Suppose your AI agent finishes a task and needs to notify a customer.
Application = Who gets the mail
Usually represents a customer or tenant.
Example:AcmeEndpoint = Where to send it
The customer’s webhook URL.
Example:https://acme.com/webhooksMessage = What happened
The actual event and its data.
Example:Task #123 finishedEvent type = What kind of thing happened
A label describing the event.
Example:agent.task.completed
The event type also helps control which endpoints should receive which events.
Acme→ Applicationhttps://acme.com/webhooks→ EndpointTask #123 finished→ Messageagent.task.completed→ Event type
Svix needs to know who should receive the event, where to send it, what happened, and what type of event it is.
Outbound: Agent does something → app sends an event to Svix → Svix delivers it to other systems.
Inbound: Something happens in another system → Svix Ingest receives the event → app gives it to the agent → agent starts or continues its work.
Why this helps: The agent doesn’t need to wait with a connection open. The app saves the workflow state and continues when the event arrives.
A Svix component for receiving incoming webhook events from external providers before they are passed into the application.
Think of Svix like a delivery service with a waiting line:
Queue: Events wait here until they’re ready to be delivered.
Workers: Pick events from the queue & send them to the correct endpoints.
Storage: Keeps the event and delivery status so they aren’t lost if something fails.
Why it matters: Your app gives Svix the events and continues working. It doesn’t have to wait for every webhook to be delivered.
If delivery fails: The event is still available, so delivery can be retried.
App → Svix queue → Worker → Customer endpointi.e., your app hands off the delivery work and moves on.
Send events to Svix: Your app sends an event to Svix when something happens.
Already have a queue? Keep it. Your queue can send events to Svix when they’re ready.
Application: Usually represents your customer or tenant.
Endpoint: The URL where that customer’s events should go.
Event type: Describes what happened, such as
agent.task.completed.Application Portal: Lets customers add/manage their own webhook endpoints and check deliveries.
Your app → Svix → Customer’s endpointSvix handles the webhook delivery infrastructure for you.
SSRF = Server-Side Request Forgery.
A customer gives Svix a webhook URL.
Svix’s server sends HTTP requests to that URL.
A malicious customer could provide a URL pointing to a private/internal service instead of a legitimate webhook endpoint.
If Svix blindly sends the request, the attacker could use Svix to reach systems they couldn’t access directly.
For example:
Attacker → malicious webhook URL → Svix server → private internal service
So SSRF protection checks/restricts where the server is allowed to send requests.
A security vulnerability where an attacker tricks a server into making requests to URLs or internal services that the attacker normally wouldn't be able to access.
Signature: Proves the webhook came from the expected sender & wasn’t changed.
Timestamp: Helps stop attackers from capturing a valid webhook & sending it again later.
Secret rotation: Lets you replace an old signing secret with a new one without breaking webhook delivery.
SSRF protection: Stops malicious webhook URLs from making Svix access private/restricted systems.
TLDR: Svix protects both the webhook receiver and the system sending the webhook.
The requirement or practice of storing data within a specific geographic region or country, often because of legal, regulatory, or organizational requirements.
Delivery logs: Show what Svix sent, when it sent it, what response came back, and whether it retried.
Ordered delivery: Keeps events in the correct order when order matters.
Throttling: Limits how quickly events are sent to an endpoint so it doesn’t get overwhelmed.
Payload transformations: Changes an event’s format when different systems need different formats.
Multi-region delivery: Helps deliver events across different geographic regions when needed.
TLDR: Svix helps you see what happens to your webhooks and control how they’re delivered as your system grows.
Model chooses the tool: It decides what tool to use and what information to send it.
Application runs the tool: The application actually executes the tool call.
Fast task: The result comes back quickly, and the agent continues.
Slow task: Something like video generation could take minutes, so the workflow waits for the result.
Completion event: When the task finishes, an event tells the application the result is ready.
Resume: The application finds the saved workflow using its ID and continues the agent from where it stopped.
Agent → Start task → Wait → Completion event → Resume agentAgent needs approval: Some actions are too important for the agent to decide alone.
Agent asks a human: For example, it asks someone to approve a refund.
Agent waits: The approval could take minutes, hours, or even a day.
Human responds: The approval comes back as an event.
Agent continues: The workflow resumes from where it stopped.
Svix handles delivery: It retries failed webhook deliveries and tracks delivery attempts.
Agent → Ask for approval → Human decides → Approval event → Agent continuesSvix is not inherently required for human-in-the-loop agents. You need it only if the approval workflow uses webhooks/events that need reliable delivery.
For your refund example, Svix could help in 2 places:
1. Sending the approval request out
Agent → Your app → Svix → Approval system
Svix makes sure the webhook reaches the external system. If delivery fails temporarily, Svix retries it.
2. Receiving the approval back
If you use Svix Ingest:
Approval system → Svix Ingest → Your app → Agent resumes
Svix Ingest receives the webhook & reliably forwards it to your application.
So Svix’s job is event delivery, not approval logic. Your application still decides:
when human approval is required
what the human is allowed to approve
how to save the paused workflow
what the agent does after approval
Problem: Some agents run on a laptop or exist only for a short time, so they don’t have a public URL where webhooks can reach them.
External event happens: Event is received by Svix Ingest.
Event waits: The local agent doesn’t need to be online when the event arrives.
Agent checks for events: When the agent is ready, it connects outward to Svix & retrieves the events waiting for it.
Why this helps: You don’t need to expose your laptop or temporary agent to the internet with a public webhook endpoint.
TLDR
External system → Svix Ingest → Event waits → Local agent retrieves itinstead of:
External system → Public URL on your laptop → AgentDon’t create events for everything: Only important changes need events, such as a task finishing or approval being requested.
Use clear names:
agent.task.completedclearly tells other systems what happened.Event catalog: Svix keeps a list of available event types so consumers know what events they can receive.
Keep payloads small: Send only the data the receiving system needs.
Version changes: If you change the event format, use versions so existing integrations don’t break.
Internal webhooks are simpler: If both systems belong to you, you control both sides and can fix problems yourself.
Customer webhooks are harder: Failed deliveries affect customers, so reliability matters much more.
More infrastructure is needed: You may need retries, security, delivery logs, monitoring, and tools to recover failed events.
Build: You create and maintain all of this infrastructure yourself.
Buy: A webhook platform such as Svix handles much of the delivery infrastructure for you.