TURION .AI
Start building
/ deep dives · field note

Event-Driven AI Agents Are Replacing the Request-Response Loop — and That Changes Everything

Balys Kriksciunas · · 9 min read
#ai #agents #deep-dive #event-driven #durable-execution #kafka #temporal #restate #architecture
Futuristic 3D architectural diagram of an event-driven AI agent system with glowing agent nodes connected by directional light pulses flowing through a central event bus against a dark technical grid background

The synchronous agent loop is dying. In its place: event-driven agent systems built on Kafka, Flink, Temporal, and Restate. Here's why the shift is happening now, what the new architecture looks like in code, and what breaks when you get it wrong.

Twelve months ago, the dominant agent architecture was deceptively simple: a while loop that calls the LLM, executes tools, and repeats until the model emits a stop signal. It worked in notebooks. It broke everywhere else.

The problem wasn’t hidden. A five-step agent pipeline with a 3-second LLM call per step means 15 seconds of blocking latency. Add fan-out to parallel agents and you get a brittle chain where one timeout poisons the whole run. Add human-in-the-loop and you’re polling a database row, hoping the approval arrived before the process OOM’d.

This year, the ecosystem is converging on a different answer: treat agents as event-driven distributed systems, not synchronous function chains. Pub/sub for inter-agent communication. Event sourcing for audit trails. Durable execution for crash recovery. Streaming platforms for real-time agent pipelines. The consensus is forming fast — and it changes what “production-ready” means for every agent you build.

Why the Synchronous Loop Broke

Let’s be precise about what fails.

Take a lead-scouting agent that researches companies, scrapes websites, extracts structured data via LLM, and generates a summary report. In a naive synchronous implementation, this is five sequential steps. Each one can fail: the search API rate-limits, the scrape times out, the extraction model hallucinates. If step four fails, you restart from step one — re-burning tokens on steps that already succeeded.

This isn’t hypothetical. If each step is 95% reliable, five sequential steps give you 0.95^5 = 77% end-to-end reliability. Fourteen steps — common in real agent workflows — drops you to 0.95^14 = 49%. Your agent is a coin flip.

The synchronous loop has three structural problems that retry logic alone can’t fix:

  1. Tight coupling. Every step blocks on the previous one. No parallelism, no buffering, no graceful degradation.
  2. No persistence boundary. If the process dies between steps, all intermediate state evaporates. There’s no journal to resume from.
  3. No isolation. A failure in agent B shouldn’t crash agent A. In a synchronous chain, it does.

These are solved problems — in distributed systems. The insight driving 2026’s architectural shift is that agents are distributed systems, just with LLMs in the hot path.

The New Consensus: Three Layers of Event-Driven Infrastructure

Pull back and look at what teams shipping agents at scale are actually deploying. Three infrastructure layers have emerged, each solving a different failure mode.

This is where inter-agent and cross-system communication lives. Instead of agents calling each other directly, they publish events to topics and subscribe to the events they care about.

Confluent documented four canonical multi-agent patterns built on Kafka pub/sub in 2025: Orchestrator-Worker (a central coordinator emits task events, workers consume and return results), Hierarchical Agent (a parent monitors a topic and spawns ephemeral child agents per event), Blackboard (all agents share an event log as shared memory), and Market-Based (agents bid on opportunity events and a coordinator assigns work).

These aren’t abstract patterns. We’re seeing production deployments where a fraud-detection agent subscribes to transactions.*, a compliance agent subscribes to transactions.flagged, and both operate independently with no orchestration code tying them together. When the fraud model gets updated, compliance isn’t affected. When compliance adds a new regulation check, fraud sees zero latency impact.

Apache Flink is joining the picture too. Confluent’s Flink Agents model brings exactly-once consistency to agent orchestration — something batch-oriented frameworks like LangChain and CrewAI cannot provide natively. A Flink agent pipeline processes events with streaming guarantees: if a checkpoint fails, the agent replays from the last consistent snapshot, not from scratch.

The key operational shift: event logs become the system of record. Every agent action is an immutable event — AgentDecision, ToolCalled, ResultEmitted. Agent state is a projection of this log, not a mutable database row. This enables time-travel debugging (reconstruct what an agent believed at any decision point), A/B testing (replay historical events through a new agent version), and catch-up processing (new subscriber agents replay the full history to bootstrap state).

Layer 2: Durable Execution (Temporal, Restate, Inngest)

If Layer 1 handles communication patterns, Layer 2 handles individual agent reliability. This is where the synchronous loop gets replaced by journaled, resumable execution.

Temporal remains the reference model: workflow code is deterministic; non-deterministic work (LLM calls, API requests, file writes) is pushed into Activities. The Temporal server stores workflow event history and replays workflow code against that history to reconstruct state after a crash. For agent builders, this means writing your agent as a Temporal workflow and wrapping every LLM call and tool invocation as an Activity. If the worker crashes at step 11 of 14, Temporal replays steps 1–10 from the event history and resumes execution at step 11. No re-burning tokens, no duplicate side effects.

The Pydantic AI team shipped a Temporal integration that makes this split explicit, separating deterministic orchestration from non-deterministic agent steps. Here’s the core pattern:

from temporalio import workflow, activity
from pydantic_ai import Agent

@activity.defn
async def call_llm(prompt: str, context: str) -> str:
    agent = Agent("openai:gpt-4o")
    result = await agent.run(f"{context}\n\n{prompt}")
    return result.data

@activity.defn
async def call_tool(tool_name: str, params: dict) -> dict:
    # External API call — wrapped as Activity for durability
    ...

@workflow.defn
class ResearchAgentWorkflow:
    @workflow.run
    async def run(self, query: str) -> str:
        # Deterministic orchestration
        plan = await workflow.execute_activity(
            call_llm, args=[f"Plan research for: {query}", ""],
            start_to_close_timeout=timedelta(seconds=30)
        )
        results = []
        for step in parse_plan(plan):
            result = await workflow.execute_activity(
                call_tool, args=[step.tool, step.params],
                start_to_close_timeout=timedelta(minutes=5),
                retry_policy=RetryPolicy(maximum_attempts=3)
            )
            results.append(result)
        return await workflow.execute_activity(
            call_llm, args=["Synthesize results", str(results)],
            start_to_close_timeout=timedelta(seconds=60)
        )

Restate takes a lighter approach. Instead of the Workflow/Activity split, you wrap expensive calls in ctx.run() and Restate journals the result. On recovery, it replays the journal and skips already-completed work. This means you can take an existing agent built with the OpenAI Agents SDK or Vercel AI SDK, add a middleware layer, and get durable execution without restructuring your codebase. Restate’s blog post on durable AI loops demonstrates this across both Python and TypeScript with minimal code changes.

The difference matters for team adoption. Temporal requires you to learn the Workflow/Activity model and respect determinism constraints. Restate lets you keep your existing agent code and add durability through middleware. Neither approach is wrong — they optimize for different starting points.

Inngest uses step memoization rather than full deterministic replay. Each step.run() result is persisted. On re-execution, completed steps are skipped and stored results are injected. Inngest also provides durable sleeps, event waits, and concurrency controls — primitives that map directly onto agent patterns like human-in-the-loop pauses.

DBOS persists workflow and step state in a database and has a direct integration for the OpenAI Agents SDK. Microsoft’s Durable Task for AI Agents (updated April 2026) positions Durable Task Scheduler as checkpointing infrastructure for agent frameworks. AWS Lambda Durable Functions and Cloudflare Workflows round out the picture.

The through-line: every workflow engine in 2026 is shipping agent-specific primitives. This isn’t a coincidence. The demand signal is unambiguous.

Layer 3: Agent-to-Agent Protocols (A2A, Event Mesh)

Google’s A2A protocol, now under the Linux Foundation with over 150 supporting organizations, uses Server-Sent Events for long-running task coordination between agents. This is event-driven architecture at the protocol level: agents don’t poll each other for status; they subscribe to task state changes.

But A2A alone isn’t enough. Solace’s engineering team made the case that A2A needs an event mesh underneath it — without one, point-to-point agent communication reproduces the same coupling problems that EDA solved for microservices a decade ago. An event mesh routes, filters, and buffers agent events across protocols and cloud boundaries.

This is the full picture: pub/sub event backbone → durable execution per agent → protocol-level event streaming for cross-agent coordination. Each layer solves a different failure mode, and the teams deploying agents at scale are adopting all three.

What This Means for Your Stack

If you’re building agents today and you haven’t adopted any of these layers, the migration path is clear — and it’s not “rewrite everything.”

Start with durable execution. Pick Temporal if you want the most battle-tested model and can invest in learning the Workflow/Activity split. Pick Restate if you want to wrap existing agent code with minimal restructuring. Either way, the first win is eliminating the “agent silently died at step 11” failure mode. That alone typically improves end-to-end reliability from ~50% to ~95%.

Add an event backbone when you have more than one agent. The threshold is surprisingly low — around three agents that need to coordinate. At that point, direct agent-to-agent calls create an N×N coupling problem. A single Kafka topic or Google Pub/Sub topic decouples them instantly. Start with the Orchestrator-Worker pattern; it’s the simplest and maps cleanly onto the supervisor/specialist architecture that most production multi-agent systems already use (which we analyzed earlier this year).

Treat A2A as the inter-org layer. Within your own system, direct pub/sub is faster and simpler. A2A shines when agents span organizational boundaries — your procurement agent talking to a supplier’s inventory agent, for instance. Don’t over-engineer early.

The Risks Nobody Talks About

Two failure modes are emerging as teams adopt this architecture.

First: the determinism trap. Temporal’s replay model requires workflow code to be deterministic. If your agent loop contains a datetime.now() call or a random seed, replay can produce different decisions than the original execution, and the workflow breaks. The fix is discipline: push everything non-deterministic into Activities. But that discipline doesn’t come naturally to teams accustomed to writing free-form Python agent loops.

Second: event schema evolution. Once you commit to an event log as the system of record for agent decisions, you’ve taken on a schema evolution problem. Change the AgentDecision event shape and you need to handle both old-format and new-format events in the same log. This is a solved problem in data engineering (Avro, Protobuf, schema registries) but largely unfamiliar to the AI agent community. We expect this to be the source of at least one high-profile production outage in 2026.

The Bottom Line

The synchronous agent loop was a prototyping convenience that became a production liability. The replacement architecture — event backbone, durable execution, event-driven protocols — is the consensus forming across every major infrastructure vendor in 2026. It’s not sexy. It’s not a new model release. But it’s the difference between an agent that works in a demo and one that survives 3 a.m. on a Tuesday.

We covered the convergence of agent frameworks on shared primitives last month. This is the second wave: the infrastructure layer underneath those frameworks is converging too. Together, they define what production AI agents look like for the rest of 2026.

Further reading:

← back to blog

Related Posts

3D render of a glowing translucent security dome encasing abstract AI agent nodes, with three concentric isolation layers against a dark navy background with cyan and amber accents Deep Dives

Agent Sandboxing: Firecracker, gVisor & Production Isolation

Docker containers aren't enough for AI agents. We break down Firecracker microVMs, gVisor, and Kata Containers — with code, benchmarks, and a decision framework for production.

Editorial illustration of multi-agent memory architecture with three agent nodes connected to layered memory tiers in warm orange, blue, and purple on dark background Deep Dives

Multi-Agent Memory Architecture: Patterns for 2026

Shared, isolated, or hierarchical? We break down the three memory architectures production multi-agent systems use — with benchmarks, code patterns, and the tradeoffs nobody talks about.

Abstract neural network visualization showing branching decision tree pathways for different reasoning levels in AI agents Deep Dives

Reasoning Models Are Rewiring Agent Architecture

How extended thinking, adaptive models, and test-time compute are replacing the ReAct loop. Concrete patterns, cost trade-offs, and when to skip reasoning entirely.