Teams are wiring AI agents to their databases the way they once wired microservices: a row changes, an event fires, and an agent decides what to do. But change streams deliver at-least-once, which is harmless only when the consumer is deterministic. If you replay an event to an agent, it may take a different action and charge you twice for the model call. When it writes back, its own change arrives in the stream and triggers it again.

This session presents architectural patterns for agents that consume change streams, with Debezium as the running example:

- Replays: recording the agent's decision instead of re-deriving it, because idempotency keys aren't enough.
- Feedback loops: attributing writes so an agent doesn't trigger itself.
- Transaction boundaries: never acting on half a transaction.
- The outbox pattern: committing an action and its decision together.
- Recovery: staleness limits and when a replayed event goes to a human.

You'll leave with patterns for putting a nondeterministic consumer on a change stream, and the questions to ask before any agent reacts to production data.

Target audience: developers and architects building agents that react to changes in operational data, and the platform teams who will run them. Intermediate. Familiarity with event-driven systems helps; no change data capture or agent framework experience is needed.

Format and duration: regular 55-minute session, about 45 minutes of talk with 10 minutes for questions.

Technical requirements: slides only, no live demo. Projector with HDMI.

First public delivery: yes. This is a new talk written for Devnexus 2027.

Related prior talks: Change Data Streaming Patterns in Distributed Systems, Devnexus 2023. That talk covered consumer patterns for conventional, deterministic services. This one asks which of those patterns fail when the consumer is an agent, and what replaces them. The overlap is limited to a brief recap of delivery semantics.

Additional information: the patterns are vendor-neutral; Debezium is the running example because I maintain it, and the same issues apply to any change stream feeding an agent. I have built both ends of these pipelines, the Oracle source connector and the JDBC sink connector, so the delivery guarantees discussed are ones I have implemented rather than observed. This session complements my Production AI Engineering submission, which covers the read path (keeping a retrieval index current). This one covers agents that react to changes and write back, where the problems are replay, feedback loops, and attribution rather than freshness. The track notes that AI does not remove the need for sound architecture and, in many cases, makes it more important; this talk is a concrete example of that. It is placed in System Design because it covers architectural patterns for systems with a probabilistic component in the loop, and because established principles (idempotency, transactional handoff, auditability) matter more once that component is present.