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.... Read more

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.... Read more

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.... Read more

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.... Read more

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.... Read more

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.... Read more

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.... Read more

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.... Read more

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.... Read more

Every team has finished its part—but is the whole system ready? This talk explores closing the gaps between design, delivery, and operations so what gets built is ready for the people who run it. Drawing on real-world infrastructure and commissioning examples, I’ll discuss agreeing on what “ready” means, verifying dependencies between teams and systems, and clarifying who makes the call when issues remain. Attendees will leave with three practical questions to bring into their next project or readiness review.... Read more