Event-driven AI - Build Autonomous Agents That Think Asynchronously | APIDays Munich 2026

In this presentation, we explore the transition from synchronous AI chatbots to autonomous agents that function as asynchronous actors within an event-driven architecture. We explain how these agents maintain real-time awareness by subscribing to streaming state changes through change context capture patterns rather than relying on static prompts. By utilizing event streams as a durable commit log, we demonstrate how to provide agents with ordered memory that supports observability and governance for mission-critical operations. This approach allows building a resilient and scalable agentic mesh that avoids the limitations of traditional request-response systems

Transcript

1. FOST Munich Event-Driven Agentic AI JUL 2026 Building Autonomous Agents That Think Asynchronously Hugo Guerrero TSC & GOVERNANCE BOARD MEMBER, ASYNCAPI DEVELOPER ADVOCATE, KONG
2. FOST Munich 2
3. FOST Munich 3
4. FOST Munich
5. FOST Munich
6. FOST Munich WHAT WE’LL COVER TODAY Use cases for AI agents on event-driven systems 01 AGENTIC ORCHESTRATION USING EDA Agents as async event consumers in your system loop 02 REAL-TIME CONTEXT UPDATE Streaming state changes so agents always know what’s happening now 03 DURABLE COMMIT LOG FOR MEMORY & AUDIT Event streams as the source of truth for reasoning, replay & compliance
7. FOST Munich CONFIDENTIAL | NOT TO BE SHARED EXTERNALLY © Kong Inc. 7 Agentic Orchestration How agents become first-class participants in your event stream
8. FOST Munich 8 Agents are asynchronous system participants
9. FOST Munich AGENTIC ORCHESTRATION Agents as async event consumers in your loop 9 Agents become part of the system event loop
10. FOST Munich An event-driven workflow 10 EXAMPLE
11. FOST Munich CONFIDENTIAL | NOT TO BE SHARED EXTERNALLY © Kong Inc. 11 Real-Time Context Update Keeping agents in sync with what’s changing right now — not five mins ago
12. FOST Munich 12 CONTEXT UPDATE Agents need more than static prompts Agents require dynamic context: ▪ system state ▪ user activity ▪ workflow history ▪ environment changes ▪ operational signals 12
13. FOST Munich 13 CONTEXT UPDATE If a user changes their delivery address, the agent needs to know immediately Examples ▪ new transaction ▪ user preference change ▪ anomaly detected ▪ workflow completed
14. FOST Munich 14 CONTEXT UPDATE Stream state changes events. Agents subscribe, not poll. Pattern: Change Context Capture Examples ▪ OrderStatusChanged ▪ FraudRiskDetected ▪ InventoryUpdated
15. FOST Munich 15 When we combine event-driven agents with context streaming, we get a powerful architecture CONTEXT UPDATE
16. FOST Munich CONFIDENTIAL | NOT TO BE SHARED EXTERNALLY © Kong Inc. 16 Durable Commit Log Why the event stream is the right substrate for agent memory, replay, and compliance
17. FOST Munich 17 DURABLE COMMIT LOG Your agent knows WHAT. Not WHY. State tells you what is. A commit log tells you how it became so. Most agentic systems are black boxes with a chat interface. That’s fine for demos. Not for anything that matters.
18. FOST Munich 18 STATE VS. STORY Vector DBs answer: what does the agent know right now? The right question: how did the agent get there? STATE (SNAPSHOT) ▪ What the agent knows now ▪ Fast retrieval, no ordering ▪ Can’t explain how it got there COMMIT LOG (STORY) ▪ Every step, decision, tool call — in order ▪ Ordered, durable, replayable ▪ Vector DB + KV are projections off the log
19. FOST Munich 19 THREE CAPABILITIES When the event stream is your source of truth 01 OBSERVABILITY Trace exactly where reasoning left the rails — not just that it failed, but where and why. 02 GOVERNANCE Every tool call and decision is traceable and immutable. Auditors have a definitive answer. 03 DEBUGGING Replay agent reasoning step by step. Fix logic, not just prompts. Stop prompt whack-a-mole.
20. FOST Munich 20 EVENT STREAMS AS SUBSTRATE Brokers are great for distributed commit logs. That’s not a coincidence. It’s a hint about the right architecture. Build on event streams, and you get: ▪ Replay — rewind, swap model or prompt, run forward ▪ Observability — dashboards as a streaming problem ▪ Forking — branch from any point in history Govern the full data path — both synchronous API calls and async event flows — with the same rigor you’d apply to any mission-critical system. A reasoning trace without infrastructure visibility is like a flight recorder that only captures the last 10 minutes.
21. FOST Munich Let’s break things DEMO 21 21
22. FOST Munich AI Agent & RAG Event Flow Architecture DEMO 22
23. FOST Amsterdam 23 23 Operational Advantages WHY THIS ARCHITECTURE WORKS  Resilience Agents continue working independently  Scalability Event streams scale naturally  Observability Agent decisions become events  Better UX No blocking or timeouts
24. FOST Munich 24 24 Building for the Agentic Mesh ▪ Agents are asynchronous actors ▪ Context must be continuously updated ▪ Capture context changes as events ▪ Build agents on event-driven architecture Scale: Handle 10,000 agents without 10,000 open HTTP connections. Resilience: Events can be retried; synchronous calls just fail. Call to Action: Start by moving one 'bot' to an async worker.
25. FOST Munich 25 SCAN TO REGISTER Save $50 on registration
26. FOST Munich Thank you! Ready for what's next? Let's talk at the Kong booth FIND ME AT X (Twitter): @hguerreroo Bluesky: hguerreroo.bsky.social YouTube: hguerreroo LinkedIn: hugoguerrero FOST Amsterdam LINKEDIN SESSION FEEDBACK
27. FOST Munich 27
28. FOST Munich