Your Agent Failed in Prod. Good Luck Reproducing It. - Tisha Chawla & Susheem Koul, Microsoft

Imagine something your agent didn't prod was wrong. Coil the wrong tool, it wrote the wrong thing, and now suddenly your team is on coil rotation to figure out what actually went wrong. Pretty common, right? Now, as for the standard engineering response, your gut will tell you to pull the raw prompt from the telemetry logs, pass it to the same model, using the same prompt and run it locally to isolate the bug. which we'll all do. And surprisingly, it will work as well. Run it again, it will work again. You run it 10 more times, it will be just perfect every time. But now let's talk about that one run which costed you and that will be gone. You can reproduce it. And if you can reproduce it, you can debug it. And if you can debug it, you can promise it won't happen to your next customer or user, right? Now I am Tisha. I have Sushin with me as my co-presenter. We both run agents against real production backends. You know, the kind of place where a bad write isn't. Oh well, run it again. It's you on a call with a customer explaining where the data actually went. This whole talk is going to be about that one thing to lose the second an agent goes hay buy-in production, which is being able to reproduce it. That will be a not start for the next 10 minutes to follow. Now let's look at how this actually blows up. You've got an agent hooked to a broker API, which is the scenario I'm taking. The user says, hey, sell $1,000 of stock. Now comes the interesting part. Instead of doing the math, the agent sells the raw number 1000 and dumps it straight into the quantity field. Guess what? It shares 1,000 shares instead. Now at 190 bucks a share, $1,000 in 10 will become how much? $190,000 disaster, right? And the very side part is that the API on my infrared returned a clean 200 okay in 30 milliseconds. We got zero exceptions, zero alerts. If you see the trade, it's completely wrong. But your dashboards are sitting there perfectly green, perfectly flawless. Then such a scenario as we last discussed comes up. What's the first thing which you will do to try and fix this? The reflex here is to, you know, just turn the model temperature down to absolute zero. Assuming greedy decoding will make everything deterministic, right? But that's a complete misconception. Setting the temperature to zero. doesn't fix a broken reasoning path it just means the model is going to make the exact same logical error the exact same day at the exact same time and honestly even worse than that back up the scenario we just discussed look at the engineering threads on reddit and hacker news the hard data shows that temperature zero isn't even truly deterministic on a hardware level Running the same prompt a thousand times can still return dozens of completely different responses just due to the underlying GPU non-determinism and the MOE architectures which are there. So to understand why this actually happens, we'll have to look at it from first principles. It comes down to four simple things. One, sampling determinism is in system determinism. always take the argmax but it doesn't guarantee that the underlying scores stay identical run to run two floating point math isn't associative the order you add your decimal matters right but a tiny shift in matrix operation alters the final logic and which in turn will flip the winning token three it's not a concurrency issue Rank the same matrix multiplication alone on a GPU a thousand times and I'll guarantee you'll get this exact same bits. So the real culprit is batch invariance here because the request gets grouped with whatever else hits the server that millisecond. Four, mixture of experts routing has the exact same bottleneck. Experts have strict capacity limits. If a batch overflows a specific subnetwork, tokens get rerouted. Whether the token makes the cut depends entirely on the graphic you got batched with. So the ultimate takeaway here is that chasing text output is a losing battle completely. We don't need a model to return the exact same token back every time. We just need our system to execute the exact same state transition, which means we've been asking the wrong question on a long, right? The wrong question is, how do I make the model deterministic? And I've seen teams burning weeks on that and walk away deciding the systems just unknowable. The right question is, how do I debug and retest a run I can't reproduce? Because determinism was never the north star, debugging was. Two words we keep mixing up, which I'll talk about now, is bitwise determinism and replayability. Bitwise determinism is... same input same output that's controllability you're not getting it from a hosted api and you don't actually want it because the randomness is what makes the model good like once the model explodes more you'll get more creative answers the other one is replayability which is rebuilt a run that already happened well enough to debug it that's observability you don't need the model deterministic you need to run recorded and you don't freeze the model to capture what it did. Now the question which we are all thinking about is where do you record? First you are not at the network layer because half your agent will never touch the network. The local retrieval, the in-process tools, the memory and the parts that do not shred under streaming and ASIC. Record at the boundary instead because you'll need to capture what enters each note and what leaves it, the meaning of each step and not the packets. What Replay adds here is a deterministic CI where you stop the model, you'll rerun the exact failure offline with zero model calls. Let's talk about the loop end-to-end now. It starts with annotation, recording, visualization, understanding, fixing. then the part we're working on which is replaying and finally verify. Let's now see how to bring the workflow we just discussed into action. We've established that replayability is a core tenet of productionizing any AI agent. But how do we build this in code? As a proof of concept for this, what we have done is we have built something called Chronicle. At the heart of Chronicle lies the concept of a boundary. Think of a boundary as a bounding box around any node in your agentic workflow. A node can be a tool call, it can be a call to an LLM, or a retrieval from a rack. It doesn't matter. As long as it's a method, it can be annotated with the boundary annotation. Now what does this annotation do? It ensures that anything that goes into the method and comes out of the method gets recorded. So any input and output pair will get recorded. On top of that, you can define parameters like your model version or the version of the code that is running. so that the entire state during which the agent run happened gets frozen and saved as a trace. Now, let's see this in action. We've been talking about this stock selling agent, which went haywire in production. This is a representation of the same. You have your initial planning step, which takes into account the user input. It can use the place order tool to do the actual selling and buying of the stocks. And then finally, it delegates to the finalize agent, which generates a succinct response for the end user. We have annotated all three of these methods with the boundary annotation. The first one is a tool and the second and the third one is an LLM. Let's run this. So here's what happened. You gave a user request to sell about $1,000 worth of ACME stocks. You have the three nodes. You have the input and the output recorded for every one of them. You can see that the LLM mistook the thousand as the quantity and generated a tool call of place order with the symbol ACME and quantity thousand. The place order tool obviously executed this input and sold thousand dollars or thousand units of Acme stock at $190 per piece. This is where the problem started. Now you have a trace for it, but is this all you can see? No. We record much more details than this. So you can go and see the hyper detail JSON for each of the nodes that the call went into or went out of. You can see the metadata like the model version, sampling versions that was there in the LLM call. you can see the input and the output. For example, this is for the place order tool. You can see the input went in as a cell of 1000 quantity on ACME and the output was obviously that it sold that quantity. And if you go one step back, you can see the agent1 node creating that tool call that caused this entire problem. It created a tool called the place order with the symbol ACME and quantity 1000. Now, this is all good. You have a recording, you have a trace, you figure out what the problem is. Now, what do you do with it? You figured out that the problem is the LLM created a wrong tool call. You cannot control the LLM. That's what this entire discussion is about. You cannot enforce bitwise determinism. What you can do is you can put guardrails on your tools to enforce some level of credibility on your production agent. But how do you test this? Once you have built the guardrails, how do you test it? That is another tenet that Boundary offers. Since the Boundary annotation is already providing a bounding box around your methods, it can be used to stub your methods during testing. So think of it like this. You have a run which is recorded. That run recorded every input and output for every node. Now you have fixed your code at, let's say, the tool level, but you want the rest of the nodes to be stubbed so that the entire exact stack trace remains the same. How do you do it? You run a test suite with the same trace that was recorded earlier. You stub every node other than the node that you changed. and you let boundary handle the rest. So let's see this one in action. This is your test case. You have loaded the trace and you have enabled the replay mode on boundary, which allows boundary to stub every node that you want. So for example, in this case, you want to stub the first agent call, which generated the tool output, but you want the tool to be run live so that you can test out your code changes. Once you do this, you run your agent. Now, another good thing about boundary is that since it's already capturing the output of your tool as well, you can use it to run assertions. So you can take the output and assert that this time around the tool call got blocked. So let's run this once. Perfect. So you can see that agent 1, which was the LLM, was stubbed. You can see the same input output as the recorded trace, but the tool and the LLM ran live. And you can see that for the tool, this time the output is blocked. and your assertion on the tool has passed because the author has blocked. So this is the power of merging your replayability traces with auto-generated testing and stubbing and assertions. So we just saw how Chronicle not only records your agent accessions, but it also uses those recordings as test cases. Now, when we talk about testing in AI agents, I want to draw a very clear distinction here. There are two ways of testing AI agents, and both of them are equally important. There's the deterministic testing and then the behavioral testing. The deterministic testing applies to obviously the deterministic nodes of your agent graph. This could be your guardrails or your tool calls. Now this is exactly where Chronicle shines because as we just saw, Chronicle freezes the entire agent run as a context. So you can use the LLM nodes context to stub the LLM outputs. This essentially kicks the probability out of the window and your entire agent run can become a test case. This is rerunable and since it never calls the model, it is free. On the behavioral side of things, you measure things like the tone of the agent or whether the trajectory it took was right. This is more subjective and this is where techniques like LLM as a judge are better off. Now at this point, I want to talk about the key takeaways. First, stop chasing bitwise determinism through the API. The fundamental principles on which the APIs are built today do not make this possible. Second, Know what are variables for your session, for example your LLM version or your build ID or your rag chunks and make sure that you are logging these. Third, capture the full envelope. Don't focus on just the prompt. There are a lot more ingredients that go into that final response. Fourth, use the replays to debug. Make sure that you find the issues, fix the failures and then finally use the same trace as a test case. Fifth and final, keep the generation time variation alive. Don't try to pin the temperature to zero. After all, that is what brings the agency into your agent. So the QR on your screen, you can scan that to get access to the code for Chronicle and a bunch of nicely written articles. And finally, thanks again for your time. And we hope that the traces that you put today in your agent make sure that your on-call cycle tomorrow is much better. Thank you.

When an autonomous agent fails in production and corrupts an enterprise data record, it rarely repeats the exact same execution trajectory twice. Standard application logs reveal what broke but completely fail to explain why, leaving platform teams unable to reproduce non-deterministic failures on demand. While durable execution engines excel at keeping an agent loop alive through state recovery, durability is fundamentally distinct from debuggability. State recovery reconstructs the present; it does not allow an engineer to re-enter the precise historical run that caused an erratic state mutation.

This session introduces the record and replay pattern for autonomous workflows, bringing the core engineering philosophy behind low level systems tools like Mozilla rr straight into the agent loop. By capturing every model invocation, tool execution payload, memory boundary read, and intermediate state transition into an append only event log, engineers can deterministically replay a failed execution trace for true postmortem root cause analysis. This architectural pattern moves entirely beyond basic API mocking or simple response caching. Attendees will leave this session knowing how to architect a framework agnostic recording layer, identify the exact state mutations required to guarantee replay determinism, understand where this approach complements durable execution architectures, and learn how to transform an unreproducible production anomaly into an execution path they can step through line by line.

Speakers:
- Tisha Chawla (Microsoft): Tisha Chawla is a Software Engineer at Microsoft working within the Commerce and Ecosystem Data Platform team, where she builds agentic systems designed to hold up against real production data. Her technical work spans core internal platform initiatives across Spec Driven Development, SRE Agent adoption, and enterprise SWE Agents, focusing on deterministic execution frameworks and agentic software development lifecycles. Alongside her infrastructure work, Tisha is a published researcher with peer reviewed papers in applied machine learning at venues including APNET SIGCOMM and ASONAM. She frequently delivers technical sessions to large engineering audiences across Microsoft, sharing high signal insights on deploying durable, production grade agentic workflows.
  LinkedIn: https://www.linkedin.com/in/tisha-chawla/
  GitHub: https://github.com/tishachawla-jg
- Susheem Koul (Microsoft): ​Susheem Koul is a Software Engineer at Microsoft with over 7 years of experience in product development. Currently, his work is focused on the design and implementation of intelligent, agentic systems. Beyond his professional focus on agentic workflows and multi-agent coordination, he explores the philosophy of learning and software architecture through his Substack
  LinkedIn: https://www.linkedin.com/in/susheemkoul/
  GitHub: https://github.com/susheem-k