Abstract

Every incident has the same bones: detection, declaration, assembly, diagnosis, resolution, postmortem. And every team bleeds in the same places.

This isn't a "presentation". It's a structured conversation. We'll walk through each stage of a bad incident together, name the friction points that never make it into the postmortem, and hear from the room: your war stories, your workarounds, your hard-won fixes.

No slides full of vendor claims. No theory. Just practitioners in a room being honest about what breaks, and what actually helps.

Come ready to talk.

Bio

Jim Hirschauer is a growth-focused technology executive and category builder currently with Xurrent (formerly 4me). Based in Austin, Texas, he is focused on shaping the ITxM category through strategic messaging, market development, and industry engagement. With a background rooted in technology and business development, Jim combines sales leadership with a strong understanding of IT service management and enterprise solutions.

Abstract

The industry is currently racing to integrate AI agents into systems originally designed for human intervention, where reliability still hinges on "human glue"—tribal knowledge, outdated runbooks, and fragmented dashboards. This session posits that achieving trustworthy production autonomy requires a fundamental shift: a new operating layer for SRE. We will explore the concept of an Agentic OS grounded in four essential bodies of truth: code, infrastructure state, runtime signals, and operational knowledge. By moving beyond disconnected artifacts like Git repos, Terraform plans, and traces, we can create a live context graph that agents can query, update, and audit in real time.

We will examine how an AI-native operations layer can be embedded directly into the delivery and runtime path. By continuously ingesting data from CI/CD pipelines, infrastructure drift, and SLO violations, this system produces durable decision traces rather than simple one-off automations. Grounded in real-world architectures and failure scenarios, this session focuses on the practical requirements for transitioning from manual scripts and alerts to truly trustworthy, autonomous SRE systems that provide a clear "why" behind every automated action.

Bio

John Jamie is part of StackGen, an Autonomous Infrastructure Platform (AIP) company based in the San Francisco Bay Area. He studied at the University of Pennsylvania’s Wharton School and works at the intersection of infrastructure automation and platform engineering.

Abstract

I gave Claude Code full Kubernetes cluster access and told it to fix a networking issue. It escalated through troubleshooting sessions, force-overrode etcd, and deleted netplan configurations across all control plane nodes. The cluster was gone. Forty minutes. No gate stopped it anywhere in the chain. This talk is the full incident: the actual command sequence, why the AI thought each escalation was reasonable, the moment I realized what was happening, and why the obvious fix (put a human back in the loop) is the wrong lesson. The whole point of AI agents in operations is autonomous speed. If you slow them down with manual approval on every action, you've just built an expensive autocomplete. The real question is: how do you let an agent operate fast inside a boundary it can't break out of? I spent the next six months answering that question. The result is an Eight Guardrails Framework enforced across multiple layers of the stack. I'll show you what those layers are, how they interact, where each one catches failures the others miss, and why the most important guardrail is the one most teams skip entirely. If your team is experimenting with AI agents in infrastructure, you're going to hit this wall. The question is whether you hit it in production or in this talk.

Bio

Principal Training Architect with 30 years of infrastructure experience across federal, Fortune 50, and startup environments. Has personally taught over 100,000 engineers platform engineering and AI/ML infrastructure. Workshop ranked third most-selected at KCD Texas 2026. Speaker at KubeCon EU Cloud Native University and KubeAuto AI Day Europe, Amsterdam. The cluster deletion incident described in this talk actually happened.

Abstract

On-call exists to improve system reliability. But over time, many teams find the opposite happening: more pages, slower recovery, and engineers who are technically capable but increasingly reactive under pressure.

This is a feedback loop, not just a workload problem.

In this talk, I’ll introduce a pattern I call The On-Call Trap, a system dynamic where repeated incident response gradually shifts teams from proactive to reactive modes of operation. As load increases, attention narrows, decision-making speeds up but degrades in quality, and teams unintentionally reinforce the very conditions that generate more incidents.

We’ll break down how this loop forms, why common fixes (more tooling, more alerts, more process) often make it worse, and what actually interrupts the cycle.

You’ll leave with a mental model for recognizing when your team is entering this pattern, along with practical ways to restore capacity for proactive reliability work without sacrificing responsiveness.

Bio

Leila Anderson studies failure in human systems.

As a therapist and Clinical AI Prompt Engineer at Upheal, she works at the intersection of mental health, product design, and operational performance, with a focus on how high-performing individuals and teams break down under sustained pressure. Her work centers on identifying hidden feedback loops that drive reactivity, reduce adaptability, and quietly degrade reliability over time.

Abstract

Observability data isn't homogeneous. Security logs require needle-in-haystack searches with multi-year compliance retention. Kernel logs are uncompressible text. Structured logs enable fast aggregations, while semi-structured logs explode cardinality. Traces demand different access patterns entirely.

Modern requirements compound this. Observability must join with other data sources. Agentic AI systems generate massive volumes of unstructured and semi-structured logs and traces. Big data platforms have emerged as popular storage alternatives.

Forcing everything into one system creates impossible tradeoffs: slow queries, runaway costs, frustrated users.

At Airbnb and Slack, operating thousands of tenants across hundreds of clusters, we built a polystore architecture routing workloads to specialized engines, unified behind a single query interface. This required changes across the entire stack: instrumentation, collection, storage, and query layers.

This talk shares routing criteria, backend tradeoffs, and techniques for unified querying. Attendees will learn to optimize observability for better performance and lower costs.

Bio

Suman Karumuri is a systems and infrastructure engineer focused on observability and distributed systems. He is the founder of KalDB, a serverless observability platform for agentic workloads. Previously, he was a Principal Engineer at Airbnb, where he led observability and reliability efforts, and held engineering roles at Slack, Pinterest, and Twitter, building large-scale logging, metrics, and tracing systems.

Abstract

With the rapid evolution of information technology, particularly the integration of new technologies and systems with cloud computing, the software development process has advanced significantly. This integration has resulted in enhancements in software quality and performance. However, the continuous introduction of new technologies and tools means that software engineers must continually acquire new skills, leading to potential delays in product launches and impacting business revenue. In this talk, I will present the following issues: Introducing Kusion - first-ever open-source project which included in both the CNCF SandBox and the Platform Tooling Landscape: An intent-driven Platform Orchestrator, that sits at the core of an Internal Developer Platform (IDP). With Kusion you can enable app-centric development, your developers only need to write a single application specification. It helps app developers who are responsible for creating applications and the platform engineers responsible for maintaining the infrastructure the applications run on. Internal Developer Platform (IDP) building solution to optimize the software development process with Cloud Native/Platform tools and integrate with cloud resources of all cloud providers with Kusion (Platform Orchestrator).

Bio

Steven Nguyen works as a Platform Engineer, responsible for developing solutions for cloud platform services (Kubernetes Engine, Cloud Observability, and Internal Developer Platform) on the Public Cloud, and also serves as a maintainer of the KusionStack Community.

Abstract

Are your AI agents generating untrusted code, forcing you to spin up slow, expensive Docker containers or microVMs just to safely execute it? Have you looked at your AWS compute bill and realized that scaling agentic coding loops in the cloud is financially unsustainable? At LILO, we bypassed the cloud tax entirely by building a zero-cost execution engine using WebAssembly. In this talk, we will pop the hood on this architecture, showing you how to push compute to the edge for microsecond cold starts, mathematically proven memory isolation, and a zero-dollar infrastructure bill.

Bio

Maxwell Myers is the CEO and Co-Founder of Pathion, an EdTech startup powered by a proprietary WebAssembly Execution-as-a-Service infrastructure, and a Software Engineer on the Microsoft Edge team. Drawing on his expertise in browser infrastructure and developer-facing APIs, he built Pathion's zero-cost, zero-latency edge execution environments. He specializes in cloud architecture, telemetry, and scaling secure, on-device sandboxes.

Abstract

Platform engineers provide capabilities to internal developers, and they build interfaces to those capabilities that meet developers where they are already working, be it web portal, CLI, or API. But lately, "where developers are already working" is alongside their AI coding assistant. Developers want to be able to ask the platform natural language questions like "Why won't my application deploy?" and "What types of databases are available to me?," and receive helpful answers. Developers want their coding assistant to investigate the platform's underlying Kubernetes cluster, surface the problem, and then apply fixes or recommend capabilities. This session is a live demo of exactly that: an AI agent that a coding assistant can use to interface with an internal platform on the developer's behalf. It is built from scratch with LangGraph, a vector database, and OpenTelemetry instrumentation. It is available to the coding assistant via MCP and CLI interfaces. LangGraph handles the Kubernetes cluster investigation tools. Then the vector database makes the cluster's capabilities searchable by natural language query. Finally, the traces help platform engineers understand how developers are using the agent: every LLM call, every tool execution, every reasoning step visible in an observability backend. This talk will show you why custom AI agents are wildly useful as a platform interface, and how to start building one at your organization.

Bio

Whitney Lee is a creator and systems thinker who explores how observability, AI, and platform engineering connect across the cloud native ecosystem. She brings humor, depth, and clarity to complex technologies while building original frameworks that help others understand how systems fit together. She runs a vibrant YouTube channel, hosts Datadog Illuminated and Software Defined Interviews, has delivered two KubeCon keynotes and countless breakout talks, and combines storytelling and technical rigor to illuminate the human side of cloud native engineering.

Abstract

Time to clarity is the real incident bottleneck, and hidden downstream failures are a major reason why."

Modern systems rarely fail at the point where the real problem begins. A seemingly healthy service can silently degrade another system downstream, causing incidents that surface far from the original fault and much later in time.

In this talk, i will introduce the concept of hidden downstream failures - failures that propagate quietly through dependencies and delay detection, diagnosis and recovery. I will present a simple mental model for recognizing these patterns and share practical signals SREs can use to reach clarity faster during incidents.

Attendees will leave with a new way to reason about failure propagation and a few concrete ideas they can apply immediately to reduce time spent debugging the wrong thing.

Bio

Shaalmali Raychaudhury is a Site Reliability Engineer at PayPal, specializing in system reliability, analytics, and operational excellence. With expertise in tools like Splunk, SQL, and Linux, she brings a strong background in production support and technology leadership across large-scale enterprise environments.

Abstract

My kids brought home spelling lists every week, but memorizing words wasn't improving their legibility or accuracy. So I built Bee Hunter... an app that uses computer vision to evaluate handwriting directly from a photo and provide real-time feedback. Building it meant applying the same reliability thinking used in production systems, but with a very different user base. When your users are in elementary school, you can't afford high latency or an outage. Here's what I learned designing for reliability when your error budget is a kid's attention span: * Why a spelling app taught me more about feedback loop latency than most production systems I've run * The observability patterns that helped me understand what was actually degrading the experience * What it looks like to define an SLO when your user can't file a ticket... they just quit * The edge cases I had to engineer around: varying lighting, backwards letters, kitchen table chaos I'll walk through the architecture decisions and the tradeoffs I made to keep it reliable under real-world conditions. You'll see what a reliability mindset looks like in practice... and how the lessons translate directly back to the systems you're running today. Sometimes the best reliability engineering happens outside the datacenter, with your kids by your side.

Bio

Aaron is a Principal Developer Advocate at AWS based in Frisco, TX. With over 15 years of experience spanning system administration, networking, and training, he brings more than a decade of cloud expertise to help Engineers, Developers, Builders, and tech enthusiasts master AWS technologies. His philosophy is simple: always be learning something new, and have fun while doing it! Aaron shares his knowledge through workshops, online courses, mentoring, and live streaming – making complex cloud concepts accessible and enjoyable. When he's not building in the cloud, you'll find him exploring craft beer scenes in new cities or teaming up with friends in Marvel Rivals on his PlayStation, because even superheroes need good teammates!

Abstract

Deterministic infrastructure testing and probabilistic models are incongruent, yet must be reconciled. Model evaluations are the answer to this question, yet do not behave as unit tests or smoke tests because they require a large body of data that represents the phenomena being modeled. To make systems reliable with unwieldy, ever-changing data distributions, product-scope evaluations of machine learning systems, beyond the individual models, are a must.

Bio

Jack Sullivan is a machine learning engineer with GetReal Security in Austin, with a focus on enhancing identity verification for all. His experience spans startups, consulting, and large, federally-funded scientific organizations in machine learning and applied physics research, as well as platform and DevOps engineering.

Abstract

Site Reliability Engineering was never meant to be about firefighting, yet too many teams find themselves stuck in an endless cycle of pages, postmortems, and quick fixes. Why? Because SRE is full of hidden traps — patterns that look like best practices on the surface but slowly erode reliability, burn out engineers, and stall progress.

In this talk, we’ll expose the 7 Deadly Traps of SRE, from the obsession with chasing “five nines,” to the cult of on-call heroism, to the false comfort of tooling and checklists. For each trap, we’ll unpack why it’s so seductive, how it quietly sabotages your team, and what to do instead.

You’ll walk away with a clearer lens on the pitfalls holding SRE organizations back, and a practical playbook to help your team escape firefighting mode and reclaim the true purpose of SRE: building systems - and cultures - that are resilient, scalable, and human-friendly.

Bio

Miko Pawlikowski is an SRE Author and a platform engineer at Quadrature. He has led large-scale infrastructure and SRE initiatives at Citadel and Bloomberg, with deep expertise in Kubernetes, cloud computing, and chaos engineering. Passionate about building resilient systems and communities, he brings together engineers worldwide through conferences and media projects.

Abstract

On-call incidents don’t fail because teams lack dashboards. They fail because observability systems slow down under real investigative load.

As telemetry volumes grow and retention windows expand, SRE teams are being asked to run deeper, broader investigations—often under time pressure—on platforms that were designed for steady-state monitoring, not bursty incident response. Tightly coupled observability stacks bind storage, compute, and query together, forcing teams to overprovision infrastructure, limit retention, or accept degraded performance during incidents.

In this talk, we’ll explore why decoupling observability architectures is becoming essential for SRE teams operating at scale. Using a real incident investigation workflow, we’ll break down how separating data storage, compute, and interaction layers allows teams to keep fast, reliable monitoring while elastically scaling investigations when incidents occur.

We’ll connect these patterns to lessons learned in other data-intensive systems, but stay grounded in the day-to-day realities of on-call life: faster root cause analysis, fewer tradeoffs during incidents, and observability systems that hold up when you need them most.

Bio

Eric is Chief Architect at Imply and a driving force behind Imply Lumi, an Observability Warehouse. His work focuses on keeping more data searchable at a lower cost while accelerating investigations with no workflow disruptions. Eric is one of the original authors of the open source Apache Druid® project. Eric's expertise spans his roles as a Fellow at Splunk, Distinguished Engineer at Yahoo Inc, member of the founding team at Tidepool, among other roles.