Girish Konda
Principal Software Engineer at Microsoft
Seattle, Washington, United States
Actions
Girish is a Principal Software Engineer at Microsoft. He is the tech lead and architect for Capacity Management in Microsoft Fabric. Before that he worked on enterprise security for Fabric platform, including customer-managed keys and private links. Most of his work is on multi-tenant cloud platforms: how they scale, how they meter, and how they hold up under load. For the past year he has been using AI agents on the operational side of that job, and finding out where they help and where they quietly mislead.
Area of Expertise
Topics
SREday Dallas 2026 Q4
Title - A Thousand Alerts a Day, and One Real Incident Hiding In Them
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.
Conf42 Feature Flags 2026
Title - Your Agent Is Confidently Wrong: Guardrails for Agentic AI in Real Engineering Work
Abstract:
Most agentic AI talks show the demo that worked. This one shows the ones that didn’t, and what I changed after. I am a Principal Engineer in Microsoft Fabric, where I am the tech lead and architect for capacity management. For the past year I have run AI agents against my actual job: incident triage, digging through telemetry, code review, and multi-step operational runbooks on a live multi-tenant platform. This talk is what I learned about trusting what they give back. The capability is real. The failure modes are too, and they are not the ones the demos prepare you for. An agent hands you a number with no source and it reads like arithmetic. It cites documents that do not exist. One wrong fact spreads into every artifact it touches, and then it argues with you when you challenge it. Long sessions drift away from the facts. None of it looks like an error. It looks like a confident, well-formatted answer, and that is exactly what makes it expensive to catch. This talk is about the discipline that makes agents safe to keep using. Force sources inline, so a claim with no source cannot survive. Verify before recommending, not after. Make the agent write its corrections down where you can see them. Keep “submitted” and “confirmed” as separate states in anything an agent tracks, because an agent will collapse them. I will go through what I ended up with, the guardrails that held up, and the ones I dropped. You will leave knowing how to tell whether your agent is working or just sounds like it is.
SREday San Francisco 2026 Q4
Title - A Thousand Alerts a Day, and One Real Incident Hiding In Them
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.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top