Abstract

Production AI agents often fail because they receive either too little operational context to act reliably or too much sensitive context to operate safely. This talk presents Secure Context Cache, an open-source framework and runtime gateway that measures, selects, reuses, and verifies identity- and policy-scoped context before a model call. In a deterministic prototype benchmark of 24 developer-agent tasks, the approach reduced average context tokens by 75.3% relative to full-context release while preserving 95.8% task success; infrastructure-review and incident-response examples will show how freshness checks, provenance, audit evidence, and human approval limit stale-context and prompt-injection risk. Attendees will leave with an architecture pattern, failure-mode checklist, and rollout metrics for operating AI agents with SRE discipline.

Bio

Krishna Reddy is an experienced Cloud and Data Platform Engineer serving as Senior Platform Engineer at HedgeServ. With a deep background in the financial, insurance, and retail industries, he specializes in building resilient cloud ecosystems using AWS, Python, Kubernetes, Spark, and serverless architectures. Krishna holds an M.S. in Computer Science from Wright State University.

Abstract

Infrastructure teams can review a Terraform change and still have little evidence of how the resulting system will behave under traffic or failure. In this session, we’ll take a proposed cloud change, test it at a stated 500 requests per second, and examine what the model suggests about cost, capacity, performance, and reliability before deployment. We’ll also look at where the test’s assumptions limit the conclusion, especially when 300 RPS does not represent the team’s actual workload. Attendees will leave with a practical way to define a scenario, interpret its results, and ask better questions during an infrastructure PR review.

Bio

Kevin Brown is the founder of Canvas Cloud Technologies, where he is building Cloud World Model, a platform for simulating cloud infrastructure changes before deployment. He spent more than 21 years at Oracle in content management consulting and cloud engineering roles, including DevOps and CI/CD work. His current focus is helping engineers and AI agents evaluate the cost, performance, and reliability implications of proposed cloud changes.

Abstract

Good incident management comes down to three interlocking layers: detection (monitoring and dashboards that surface issues, balanced against alert fatigue and log-level tuning), tracking (ticketing systems, queue structures, staffing, and the documentation that speeds up resolution), and notification (getting the right alert to the right person fast). Drawing on hands-on experience across LTI Mindtree/Marriott, Hitachi/Verizon, and Check Point, spanning tools like Dynatrace, Splunk, ServiceNow, Salesforce, Jira, and Teams, I’ll walk through what breaks down when one layer is neglected, and what a well-balanced incident management process actually looks like across a support organization. 3. Bio: Jerry Scott’s path into incident management started as a Data Engineer at LTI Mindtree, supporting Marriott’s revenue management system across 8,000+ properties, before moving into Site Reliability/Production Support at Hitachi Digital Services on Verizon’s FedRAMP High AWS GovCloud infrastructure. He’s now a Technical Support Engineer at Check Point Software Technologies, troubleshooting and resolving incidents on Check Point’s Security Management System (SMS), the platform that manages security gateways protecting organizations from cyberattacks. Across every role, the throughline has been the same: detecting, tracking, and resolving incidents, just under different titles and different tools. He holds an MS in Cybersecurity, a BS in Sociology, and an AA in Social Work, and has a deep interest in technology and problem-solving that pulled him into this field.

Bio

Jerry Scott’s path into incident management started as a Data Engineer at LTI Mindtree, supporting Marriott’s revenue management system across 8,000+ properties, before moving into Site Reliability/Production Support at Hitachi Digital Services on Verizon’s FedRAMP High AWS GovCloud infrastructure. He’s now a Technical Support Engineer at Check Point Software Technologies, troubleshooting and resolving incidents on Check Point’s Security Management System (SMS), the platform that manages security gateways protecting organizations from cyberattacks. Across every role, the throughline has been the same: detecting, tracking, and resolving incidents, just under different titles and different tools. He holds an MS in Cybersecurity, a BS in Sociology, and an AA in Social Work, and has a deep interest in technology and problem-solving that pulled him into this field.

Abstract

Most observability today is reactive by design. We instrument our systems, wire up dashboards, and then wait. More often than not, it's a customer hitting an error, a support ticket, or a 3am page that tells us something has already broken. By then the damage is done. This talk argues that treating observability as a break-then-fix process is a choice, not a law of nature, and that the next era of reliability engineering is proactive: surfacing degradation, anomalous patterns, and emerging risk before they ever reach a customer. Drawing on lessons from building Traceway, it covers what a proactive observability model looks like in practice: the signals worth watching, how to close the loop from detection to action, and where teams get stuck making the shift. You leave with a concrete framework for getting ahead of failure instead of chasing it.

Bio

Dusan fell in love with coding in 2012 and joined Silicon Valley startup Craftable as a founding engineer just two years later. Over the next decade he helped grow Craftable from the ground up, scaling the team and the architecture and eventually stepping into the role of VP of Engineering, leading a 30+ person engineering organization within a 100-person company. In 2025, ready for a new challenge, he founded a startup that grew to a self-sufficient team of 10 within a year. Now he's channeling everything he's learned about building and scaling software into Traceway, an observability platform focused on making software reliability effortless.

Abstract

Agentic AI doesn’t always require SOTA LLMs in the cloud. Local, open-weight LLMs can enable private, domain-specific multi-agent workflows across mobile devices, laptops, and on-premise servers. But operating these systems in production introduces new SRE challenges around orchestration, observability, reliability, resource management, model lifecycle, and failure handling. This talk explores how to build a production-ready orchestration environment for multi-agent workflows across heterogeneous infrastructure, and the engineering practices needed to keep distributed AI systems reliable at scale.

Bio

Michael Liubchenko brings extensive experience delivering agentic products and services to Fortune 100 enterprises. He serves as a CompTIA AI/ML Cybersecurity Subject Matter Expert and has led major AI/ML platform rollouts, including solutions for Jio Mobile reaching over 500 million subscribers and the Jio Platforms Smart Home initiative serving 170+ million homes. His firmware developments power millions of Android phones and Linux 5G hotspots globally, earning US certifications from Verizon and AT&T. A frequent conference speaker, technology evangelist, and active researcher, he shares insights on emerging technology, research projects, and security integrations through his blog at spartanshield.ai.

Abstract

A monitoring stack that fires a thousand alerts a day does not have a monitoring problem. It has a reading problem. Nearly all of it is benign and repeats the same twenty shapes - and somewhere in there is a real incident that looks exactly like the rest until someone digs. The obvious fix is to point an agent at the queue and let it triage. We tried that. It is confidently wrong, and the confidence is the dangerous part: it returns a fluent, well-argued verdict on every alert at the same level of certainty, whether it pulled real evidence or just pattern-matched the title. At a thousand a day, even a small confidently-wrong rate is dozens of silent misfilings - and the ones it buries are the unfamiliar ones, which is exactly where the real incidents live. I am a Principal Engineer in Microsoft Fabric, where I am the tech lead and architect for capacity management. What finally worked was refusing to let one agent do both jobs. Triage got cut back until routing is all it can do. It groups by signature and hands off. It is not allowed to conclude, to close, or to declare anything benign - that is the judgement it is worst at and the one with the worst downside. Investigation was then split across dedicated agents, one per failure domain. Each knows only its own telemetry, its own known-benign patterns, and its own escalation bar. That narrow hypothesis space is what makes "I could not find evidence for this" an answer the agent will actually give, instead of a plausible story. It also means each one can be tested on its own against past incidents, which a single generalist triager never can be. The metric that matters is recall on the rare real incident, not how much of the queue got closed. I will go through the routing design, how the investigation agents are kept honest, what is escalated to a human on purpose, and the real problems we only caught because a specialist refused to answer.

Bio

Girish Konda is a Principal Software Engineer at Microsoft with over eight years of experience building scalable distributed systems and machine learning platforms. He has led large scale engineering projects and backend teams, with previous experience at Amazon and AWS.

Abstract

The SRE role is quietly splitting into two different jobs. One path is using AI agents to operate more systems with fewer humans; shifting the SRE from first responder to the engineer who provides judgment, oversight, and the final override. The other is building, tuning, and governing the AI systems themselves: becoming the engineer responsible for the reliability of the thing operating the infrastructure. Neither path is optional, and neither requires abandoning the reliability mindset that got us here. In fact, the skills that made great SREs, understanding failure, managing blast radius, demanding observability, designing for rollback, and distrusting systems that haven't earned trust, has become more valuable than ever. This talk explores what the split looks like, why it is happening now, and how SREs can start preparing for both paths today. We'll look at practical examples of AI-assisted operations, the emerging discipline of AI reliability engineering, and what happens when we give an AI agent real operational authority. The future of SRE isn't fewer engineers. It's engineers operating at a dramatically different level of abstraction. Takeaway: The toil was never the job. It was just in the way.

Bio

Kevin Inman is a technology executive and cloud, AI, and SRE leader with more than 20 years of experience building and operating systems at scale. His career has spanned Apple, AWS, eBay/PayPal, AppDynamics, and Fannie Mae, including architecting iCloud from inception, leading the response to eBay/PayPal's 190-million-user credential reset, and building SRE organizations from the ground up. Today, Kevin leads enterprise AI and platform transformations across regulated financial and federal environments while building AI-native systems of his own. His focus is increasingly on the intersection of reliability engineering and autonomous systems, and what happens when the thing operating our infrastructure starts making decisions of its own.

Abstract

Why do enterprise implementations of SLOs fail? The failure is rarely a cancellation or a reversal in direction. It usually masquerades as something more sinister — lip service and minimal effort, where outcomes get sacrificed for the sake of output, and the difference that could have been made for our teams and customers quietly never arrives. What makes it hard to catch is that the early part goes well. Dashboards appear, percentages get published, coverage gets reported, and none of it is fake. Then the program never lifts off the runway, or it does and it's carrying nothing. This session walks through several failure patterns I've seen first hand, and what each one costs you. Some are corrosive. Some just leave a better outcome on the table in exchange for something expedient. All of them are avoidable once you can see them for what they are. These aren't hypotheticals — they come from multiple years driving SRE adoption, culture, and practice across different organizations, and I've been in the middle of every one of them. Before we can fix something we first have to be able to recognize it for what it is and then articulate why it's a pattern to be avoided. If you see yourself, your team, or your organization in any of this — good. You're not alone.

Bio

With over a quarter-century spent in the trenches of production systems, Jason has navigated everything from network engineering and cloud architecture to large-scale SRE programs and teams. He has spent years driving reliability and resiliency for mission-critical infrastructure within Fortune 500 landscapes, leading engineering efforts across both the U.S. and globally. His focus spans all three domains of reliability success: People, Processes, and Platforms. One driving truth: the cultural layer is just as critical as the compute layer.

Abstract

Everyone's connecting MCP servers to their AI agents right now. What almost nobody's doing is checking the bill. Every tool you register and every server you connect quietly pads your token count... often before the model does anything useful. This talk digs into the real tokenomics of MCP: why tool schemas are a fixed tax on every request, how that overhead compounds into serious cost and latency at scale, and what you can actually do about it. You'll see how to measure the token cost your MCP setup adds, using live examples, plus practical ways to trim it without losing the tools you rely on. If you're running AI agents in production, or about to be, this is the cost conversation worth having before your invoice has it for you.

Bio

Aaron Hunter 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

Moving a live application to AWS meant taking responsibility for more than a new infrastructure diagram. This talk follows the migration of a production application with live users, from building its AWS environment with Terraform, ECS, and RDS through the cutover and its first operational surprises. I’ll share three assumptions the move exposed: a database restore that reported success without moving the expected data, scheduled jobs that ran twice when the application scaled beyond one container, and competing owners for the ECS task definition. Attendees will leave with practical ways to verify a migration against its source, identify behavior that assumes a single instance, and make deployment ownership explicit.

Bio

Isaac Rowaiye is a Dallas-based software and platform engineer and founder of IR Technical Solutions LLC. A former software development engineer at Amazon (AWS), he works across application development, AI integrations, AWS infrastructure, and DevOps. He focuses on building and operating reliable production systems, from cloud migrations and infrastructure as code to deployment pipelines and automation.

Abstract

I have never run a Kubernetes cluster. Yes, I said it.

Are you still with me? Cool!

Over the past last five years I talked to thousands of SREs and platform engineers at the conferences I run with my team: SREday, LLMday, PLATFORMday and Conf42.

The same story keeps coming back. Before the first container hits production you step into the world of Kubernetes, and then you need to build a whole team just to keep it running. A kolljoy for many smaller teams. We started talking with my brother, Miko Pawlikowski, how we could help the community ease some of these pains.

Miko has been running platform teams on Kubernetes for 10+ years, leading him to start writing Reliaburger: one Rust binary with the scheduler, gossip, Raft, eBPF service discovery, ingress, mTLS, registry, metrics, logs, GitOps and chaos testing inside, driven by TOML. An app with health checks, ingress and autoscaling is twelve lines. He wrote the software. I am here to hand it to the community and see what you do with it.

This is a hands-on session, so bring a laptop (macOS on Apple silicon or Linux; Windows is not supported yet).

In 30 minutes you will:

1. Install Reliaburger with one command and start a node on your laptop. No container runtime, no root, no VMs: the built-in process runtime runs plain binaries.
2. Deploy an app from a twelve-line TOML file and watch it in the terminal dashboard and the web UI.
3. Ship a deliberately sick version and watch the health checker restart it, then roll back with one command.
4. Break it on purpose with the built-in fault injector: kill an instance, freeze another, and let relish wtf explain what just happened.
5. Read the manual and the source code from inside the binary, so you can keep going after the session.
6. Tell us what broke and what you liked.

Reliaburger is free and open source (Apache 2.0), and it is version 0.1.0, so it will break. That is where you come in. We are looking for helpers, burger ambassadors and contributors: people who will run it, break it, file the issues, write the docs and tell their teams. There are millions of practitioners running parts of Kubernetes they do not need, with more people than they should need to run it. We want this to become a community-driven project, just as our conferences are.

Help us build something awesome!

Bio

Mark Pawlikowski runs SREday, LLMday and PLATFORMday, in-person conferences for the people who keep production up, and Conf42 online. He is not an engineer. He has spent the last five years listening to SREs and platform engineers describe what their work is actually like, and now brings Reliaburger, his brother Miko's batteries-included container orchestrator, to that community to play with, break and build on.