# Event-Driven AI: Agents Shouldn’t Have to Keep Asking if Something Happened > Source: > Published: 2026-09-30 16:00:00+00:00 # Event Driven AI: Agents Shouldn’t Have to Keep Asking if Something Happened Alex Drag Head of Product Marketing **Kong Webhook Engine turns business events into triggers for applications and AI agents — connecting what happens in the business to what happens next.** Most AI agent interactions today start with an explicit request. A user sends a prompt. An application invokes an agent. A workflow calls one. The agent wakes up, reasons, uses its tools, and responds. But businesses don’t operate only on requests. They operate on events. A payment fails. A customer cancels. An order ships. A security alert fires. Inventory falls below a threshold. A suspicious transaction occurs. What if any system, like an application, a SaaS platform, or an AI agent, could simply register for the events they care about — and act when those events happen? This is the foundation of an event-driven AI architecture, replacing continuous polling with immediate, context-rich triggers. Today, we’re introducing the private beta of Kong Webhook Engine, a new capability that lets applications and AI agents register for business events, like HTTP POST and Kafka events, and be invoked when those events occur. In simple terms: When this happens → invoke these systems. ## From business event to agent action Consider a bank using an AI agent to investigate potentially fraudulent transactions. A transaction is processed and the bank’s fraud detection system identifies suspicious activity. That event is published to Kafka: `**fraud.suspected**` The bank’s Fraud Investigation Agent has registered for that event. Kong Webhook Engine receives the event and delivers it over HTTP to the agent, triggering an investigation. This specific banking fraud AI event workflow managed by Kong ensures that critical alerts are never missed and are processed in near real-time. From there, the agent can reason about what happened and use its available tools to determine what to do next. It might retrieve the customer’s recent transaction history, check the device and location associated with the transaction, query a risk-scoring service, compare the transaction against known fraud patterns, open an investigation case, or escalate it to a human analyst. This is where event-driven architecture and agentic AI come together. **Events trigger agents. Agents trigger action.** ### Give any system the events they care about, without making them Kafka consumers Enterprises already have enormous amounts of real-time business context flowing through event infrastructure such as Kafka. But traditionally, if a development team wants an application to react to a Kafka event, it needs to build and operate a Kafka consumer. That means dealing with Kafka clients, consumer groups, offsets, failure handling, scaling, and the operational lifecycle around them. When evaluating a Kafka consumer vs. a webhook engine, the difference lies in operational overhead. A traditional consumer requires dedicated compute, library maintenance, and complex state management, whereas a webhook engine offloads all of this infrastructure burden. That’s a lot of infrastructure when what the developer really wants to express is: **When a suspicious transaction occurs, invoke my fraud agent.** Webhook Engine creates that bridge. A platform team connects a channel to an event source. Applications and agents can then register for the events they care about and provide an HTTP endpoint where those events should be delivered. Kong handles consuming the event and delivering it to the registered destination. Durable database-backed buffering also decouples event producers from downstream consumers. An application or agent doesn’t have to process events at the same rate they’re produced, and the event producer doesn’t have to wait for the receiving system. The destination doesn’t need to become a Kafka consumer. **It just needs to be ready to act.** ### From business event to system sync Consider a retailer whose order management system marks an order as shipped. That event gets published to Kafka: order.shipped Several systems care about that event, but polling for it is inefficient and could cause delays in action. Kong Webhook Engine delivers the event over HTTP to each one: the CRM gets updated with the new order status, the fulfillment partner's system gets notified so it can schedule delivery, and an internal analytics data warehouse for reporting. No custom integration built per destination. No point-to-point glue code between the order system and each downstream target. One event, delivered wherever it's registered to go. Order shipped → Event → Sync, notify, log. This is the same pattern that iPaaS platforms are typically brought in to handle (SaaS-to-SaaS sync, trading partner delivery, notification fan-out) now achieved in the same platform that is managing API traffic. ## One event can trigger many reactions Business events rarely matter to only one system. Consider the same suspicious transaction. The **Fraud Investigation Agent** might investigate it. A **Customer Protection Agent** might determine whether the customer should be contacted. An analytics application might capture the event for fraud-model analysis. A compliance system might record it for audit purposes. With Webhook Engine, each can independently register to receive the event through its own HTTP endpoint. Underneath, a channel consumes from the event source and fans events out through subscriptions to one or more target applications. The source system doesn’t need to know how many consumers exist or what they’ll do with the event. It simply publishes what happened. ## Using the Kong Event Gateway for even more flexibility We can make Webhook Engine even more powerful by placing the **Kong Event Gateway** between Kafka and the Webhook Engine. Instead of consuming directly from the underlying topic, Webhook Engine can consume from a governed virtual cluster where Kong applies event-level controls before anything is delivered downstream. That creates a clean separation: Event Gateway governs access to and use of the event stream; Webhook Engine turns the approved event into an HTTP-triggered action. That means the same event-triggered pattern can inherit enterprise policies around things like access control, isolation, and other Kafka governance controls before the event ever reaches the agent. The result is a stronger end-to-end model: **govern the event first, then trigger the action** — with Event Gateway controlling the event plane and Webhook Engine handling delivery to the application or agent. ## From request-driven to event-driven Much of the agentic AI conversation today focuses on what happens **after an agent has been invoked**. Which models can it use? Which APIs can it call? Which MCP tools can it access? Is it authorized to take a particular action? Those are critical questions. But there’s another side of agent connectivity: **How does an agent know there’s something it needs to act on?** Instead of continuously polling systems for changes or waiting for a human to provide a prompt, agents can react to events already flowing through the business. Kong Webhook Engine connects a critical part of that loop by turning enterprise events into triggers for the applications and agents that need to respond. And because the delivery mechanism is HTTP, Webhook Engine doesn’t dictate what sits at the other end. It could be a traditional application, a workflow, a SaaS service, or an AI agent — consistent with the Webhook Engine application model. For developers, the idea is simple: **Tell Kong what you care about. Tell Kong where to reach you. React when it happens.** Because your systems and agents shouldn’t have to keep asking whether something happened. **They should be ready when it does.** ## Frequently Asked Questions (FAQs) **Why shouldn't AI agents poll for changes?** Polling for changes is highly inefficient and resource-intensive. When an AI agent constantly asks a system "did something happen yet?", it wastes compute cycles, increases network latency, and can lead to delayed reactions. Event-driven AI architecture solves this by pushing the event to the agent exactly when it happens, ensuring immediate action with less overhead. **How do I deliver Kafka events over HTTP?** You can deliver Kafka events over HTTP by using a Kafka to Webhook bridge like the Kong Webhook Engine. Instead of building a custom Kafka consumer, you configure a channel that points to your Kafka topic. The engine automatically consumes the events and pushes them via an HTTP POST request to any registered webhook URL, such as an AI agent or a web application. **Can one Kafka event trigger multiple AI agents?** Yes. With a webhook engine, a single Kafka event (like fraud.suspected) can be fanned out to multiple independent destinations. For example, a Fraud Investigation Agent, a Customer Protection Agent, and a compliance logging system can all register separate HTTP endpoints for the same event. The engine handles delivering the payload to all of them simultaneously. **What is the difference between an event gateway and an event bus?** An event bus (like Apache Kafka) is the underlying infrastructure responsible for storing, organizing, and routing raw event data streams. An event gateway (like Kong Event Gateway) sits on top of the event bus to govern, secure, and shape access to those streams. While the bus handles data transport, the gateway applies enterprise policy controls, rate limiting, and access management before the data reaches consumers. **What happens after a suspicious transaction event in banking AI?** In an event-driven AI workflow, a suspicious transaction event is published to a topic. A webhook bridge instantly delivers this event over HTTP to a Fraud Investigation Agent. The agent then reasons about the event, uses its connected tools to retrieve transaction history or query risk scores, and takes automated action—such as freezing the account or escalating to a human analyst—without waiting for manual intervention. Most AI cost management starts with infrastructure. A provider can tell you that you consumed a certain number of input and output tokens on a particular model. An observability platform can show requests, latency, tokens, and traces. A cloud cost p Alex Drag # Kong AI Gateway 2.2: Built for what comes next in AI AI is not just producing different answers. It is starting to do different kinds of work. JEV introduces a different model for using AI: instead of generating text, it returns typed, probabilistic decisions that software can act on directly. By ret Alex Drag # Kong Gateway 3.9: Extended AI Support and Enhanced Security Today we're excited to announce Kong Gateway 3.9! Since unveiling Kong Gateway 3.8 at API Summit 2024 just a few months ago, we’ve been busy making important updates and improvements to Kong Gateway. This release introduces new functionality arou Alex Drag # Kong AI Gateway Goes GA, New Enterprise Capabilities Added More easily manage AI spend, build AI agents and chatbots, get real-time AI responses, and ensure content safety We're introducing several new Kong AI Gateway capabilities in Kong Gateway 3.7 and Kong Gateway Enterprise 3.7, including enterprise-o Marco Palladino # Kong API Gateway 3.16: From Debugging to Billing to Compliance Two kinds of problems only show up once an API is already live. Something breaks, and a team needs visibility into one specific node right now — not after a redeploy. Or the right behavior for a request depends on who's calling it: a consumer's plan FIPS 140-3 is the U.S. and Canadian government standard for validating cryptographic modules - the code that does encryption, key generation, and digital signatures. It's issued by NIST and CCCS and enforced through CMVP, the Cryptographic Module Va If you're running agents in production, you've felt this problem: every agent, every LLM application, every MCP client needs to be configured against a growing sprawl of MCP servers, each with its own endpoint, its own handshake, and its own access Greg Peranich # Take Control of the Economics of AI with Kong AI Gateway Most AI cost management starts with infrastructure. A provider can tell you that you consumed a certain number of input and output tokens on a particular model. An observability platform can show requests, latency, tokens, and traces. A cloud cost p Alex Drag # Kong AI Gateway 2.2: Built for what comes next in AI AI is not just producing different answers. It is starting to do different kinds of work. JEV introduces a different model for using AI: instead of generating text, it returns typed, probabilistic decisions that software can act on directly. By ret Alex Drag # Kong Gateway 3.9: Extended AI Support and Enhanced Security Today we're excited to announce Kong Gateway 3.9! Since unveiling Kong Gateway 3.8 at API Summit 2024 just a few months ago, we’ve been busy making important updates and improvements to Kong Gateway. This release introduces new functionality arou Alex Drag # Kong AI Gateway Goes GA, New Enterprise Capabilities Added More easily manage AI spend, build AI agents and chatbots, get real-time AI responses, and ensure content safety We're introducing several new Kong AI Gateway capabilities in Kong Gateway 3.7 and Kong Gateway Enterprise 3.7, including enterprise-o Marco Palladino # Kong API Gateway 3.16: From Debugging to Billing to Compliance Two kinds of problems only show up once an API is already live. Something breaks, and a team needs visibility into one specific node right now — not after a redeploy. Or the right behavior for a request depends on who's calling it: a consumer's plan FIPS 140-3 is the U.S. and Canadian government standard for validating cryptographic modules - the code that does encryption, key generation, and digital signatures. It's issued by NIST and CCCS and enforced through CMVP, the Cryptographic Module Va If you're running agents in production, you've felt this problem: every agent, every LLM application, every MCP client needs to be configured against a growing sprawl of MCP servers, each with its own endpoint, its own handshake, and its own access Greg Peranich # Take Control of the Economics of AI with Kong AI Gateway Most AI cost management starts with infrastructure. A provider can tell you that you consumed a certain number of input and output tokens on a particular model. An observability platform can show requests, latency, tokens, and traces. A cloud cost p Alex Drag # Kong AI Gateway 2.2: Built for what comes next in AI AI is not just producing different answers. It is starting to do different kinds of work. JEV introduces a different model for using AI: instead of generating text, it returns typed, probabilistic decisions that software can act on directly. By ret Alex Drag # Kong Gateway 3.9: Extended AI Support and Enhanced Security Today we're excited to announce Kong Gateway 3.9! Since unveiling Kong Gateway 3.8 at API Summit 2024 just a few months ago, we’ve been busy making important updates and improvements to Kong Gateway. This release introduces new functionality arou Alex Drag # Kong AI Gateway Goes GA, New Enterprise Capabilities Added More easily manage AI spend, build AI agents and chatbots, get real-time AI responses, and ensure content safety We're introducing several new Kong AI Gateway capabilities in Kong Gateway 3.7 and Kong Gateway Enterprise 3.7, including enterprise-o Marco Palladino # Kong API Gateway 3.16: From Debugging to Billing to Compliance Two kinds of problems only show up once an API is already live. Something breaks, and a team needs visibility into one specific node right now — not after a redeploy. Or the right behavior for a request depends on who's calling it: a consumer's plan FIPS 140-3 is the U.S. and Canadian government standard for validating cryptographic modules - the code that does encryption, key generation, and digital signatures. It's issued by NIST and CCCS and enforced through CMVP, the Cryptographic Module Va If you're running agents in production, you've felt this problem: every agent, every LLM application, every MCP client needs to be configured against a growing sprawl of MCP servers, each with its own endpoint, its own handshake, and its own access Greg Peranich ## Ready to see Kong in action? Get a personalized walkthrough of Kong's platform tailored to your architecture, use cases, and scale requirements.