Speaker
Abstract
Distributed systems are built around assumptions about workload behavior: connections have reasonable lifetimes, retries eventually stop, traffic spikes have recognizable causes, and application code produces somewhat predictable query patterns.
AI agents violate many of these assumptions. They can fan out rapidly, retry failures indefinitely, create large numbers of short-lived connections, and generate novel queries at runtime. In a shared database platform, behavior like this can turn a small application bug into a noisy-neighbor problem, a retry storm, or an expensive distributed failure.
In this talk, I’ll use lessons from operating a Distributed Postgres platform to examine what happens when unpredictable workloads meet shared distributed infrastructure. We’ll look at connection and resource management, admission control and backpressure, failure containment, rate limiting, and the signals needed to distinguish an overloaded system from a badly behaving client.
Key Takeaways:
- Recognizing Agentic Traffic Patterns: Understand how autonomous AI workflows change connection lifecycles, concurrency, retry behavior, and query patterns.
- Building Guardrails for Critical Infrastructure: Use admission control, backpressure, timeouts, quotas, and isolation to prevent one client or workload from turning into a system-wide failure.
- Monitoring and Debugging Agent Workloads: Catch agent-driven problems before they become expensive incidents.
Interview
My session is all about how agentic workloads change the way we build distributed systems.
For the last 2 years, we've seen the increasing prevalence of both agents and applications written by coding agents on our infrastructure,. I've been getting lots of questions about the nature of those workloads, and how these workloads change the way we build things.
I know we are not alone in this. I've been getting a lot of questions on this topic from my colleagues in many different companies. So this talk is all about sharing my experience and lessons. I expect these lessons will be useful for other senior engineers.
Large volume of agent-driven activity started around the start of the year and is only growing. The best time to discuss the problems this causes and techniques to handle this was probably a year ago. The second best time is now.
I see 3 categories of challenges:
- Discovering wrong assumptions underlying the architecture. To an extent I didn't appreciate earlier, our systems are built around assumptions of what users are likely or unlikely to do. Agentic workloads violate many of them. We need to identify the new behaviors and adjust the architecture accordingly.
- Attempts to accommodate everything the agents do. I see this a lot - agents introduce new behavior and the team assumes they have to support this behavior in order not to be left behind. But accommodating the agents isn't always the right thing - the system needs to remain stable, performant, cost-effective and legible. We need to be intentional about what we support and when we say "I can't let you do this, Claude".
- Attempts to teach agents new tricks. When agents do something obviously wrong, we want to try and teach them a better behavior. There are many ways to do this - skills, docs, comments, error messages, MCP, etc. The challenge is picking the right technique, validating the results and continuing to re-validate since agent behavior changes over time.
It really depends on what they encounter in their own system. Ideally the first thing to implement is observability, so the agent behavior can be tracked and analyzed. If this is already in place, usually the next step is rate-limiting.
It is one of the very few conferences that targets senior engineers specifically. So I know that the talks will be relevant to me (they are selected by and for senior engineers), and that the attendees will be highly experienced - which makes for the best hallway track in the industry!
In QCon AI NYC last year, one of the attendees shared (over lunch) how he used coding agents to speed up the rewrite and replacement of a legacy system. I took furious notes, and changed much in how my team and I worked as a result.
Topics
$2,955, Conference (3 days). Current pricing ends October 13th. All pass options.
QCon San Francisco 2026 is a three day conference for senior software engineers, architects and team leads. An international program committee of working engineers selects every session. Patterns and practices, not products and pitches.
From the same track
Tuesday 17 November
10:35 Ballroom BC Session Data Platforms Orderly Keys, Wild Values: Adaptive Compression for Distributed Key-Value Storage Joseph Lynch, Ayushi Singh At Netflix scale - billions of requests per day and petabytes of key-value data - even small inefficiencies in storage and network paths become expensive. 11:45 Ballroom BC Session Distributed Systems When Your Users Are Agents: Lessons from a Distributed Postgres Platform Gwen Shapira Co-Founder and CPO @Nile, Previously Engineering Leader @Confluent, PMC Member @Kafka, & Committer Apache Sqoop Distributed systems are built around assumptions about workload behavior: connections have reasonable lifetimes, retries eventually stop, traffic spikes have recognizable causes, and application code produces somewhat predictable query patterns. 13:35 Ballroom BC Session Adaptive Systems in Production: What Recommendation Systems Can Teach Us About Agents Mallika Rao Senior Engineering Manager @Zocdoc, Previously @Netflix, @Twitter and @Walmart As organizations race to build AI agents, many teams are encountering challenges that feel new: evaluation uncertainty, feedback loops, behavioral drift, exploration versus exploitation, and maintaining user trust in systems that continuously adapt. But these challenges are not new. 14:45 Ballroom BC Session Databases How to Build Online Systems with Object Storage Almog Gavra Co-Founder @Responsive.dev - Building Object-Native Databases, Previously @Confluent and @LinkedIn “Diskless” systems that delegate durability to object storage are everywhere, and for three good reasons: 15:55 Seacliff D Unconference Unconference: Distributed Systems in Production 17:05 Ballroom BC Session Autoscaling 800 Valkey Clusters: Distributed Systems Lessons from Scaling Stateful Fleets Kishor Yadav Kommanaboina Staff Software Engineer @Snapchat - Leading Caching and Storage Infrastructure Autoscaling stateless services is a solved problem. In a sharded datastore, a resize is not a capacity change — it's moving ownership of key ranges between nodes while the cluster serves live traffic, and rebalancing takes long enough that reacting to a traffic peak is already too late.