AI agents need incident trails, not just better prompts.
OpenAI recently announced a framework for regularly disclosing unexpected or unauthorized model behavior, including several previously observed cases.
What's interesting here is the shift in thinking:
We're moving from
"How do we prevent every unexpected behavior?"
toward
"How do we detect, investigate and understand what happened?"
For agent systems, that naturally raises another question:
Can we trace the action itself?
That's one reason we're pushing Aegisora toward runtime evidence in 3.0.
A decision should not disappear after execution.
There should be a relationship between the request, the decision, the execution and the resulting evidence.
Aegisora GitHub
Clear and practical, thanks. Did anything surprise you along the way?
For anyone curious about the practical side of this, Aegisora 3.0 is now open to try.
You can run it, look through how request → decision → execution → evidence is connected, and tell us what you think from your own agent workloads.
https://github.com/aegisora-ai/aegisora/releases/tag/v3.0.0
Issues, feedback and PRs are very welcome. And if it turns out to be useful for you, leaving a star or passing it on to another agent builder is always appreciated.
Curious how others are handling this today.
When an AI agent takes an unexpected action, can your team reliably reconstruct what happened from the request all the way to the final result?
Would love to hear how you're approaching runtime evidence, incident investigation, or auditability in your own agent systems.
Thanks for writing this up. Bookmarking it for later.
Thanks! The execution-to-evidence link is the part we’re most focused on making practical.
How did you decide this was worth building in the first place?
We kept seeing the same gap: teams could review model output, but had much less visibility into what an agent actually did at runtime.
Helpful post. How did you get your first bit of traction?
Mostly by sharing the problem openly and talking to people building agent systems. The strongest conversations came from teams already dealing with runtime visibility gaps.
Makes sense. Are you planning to charge for it, or keep it free for now?
The core is open source. We’re building enterprise capabilities around governance, audit and runtime control.
Great breakdown. What feedback have you had from early users?
The recurring feedback is that the execution trail is valuable because it makes debugging and incident review much more concrete.
Appreciate the honesty here, most people only share the wins.
Thanks. We’ve found the unresolved parts are often where the most useful product lessons come from.
Nice work shipping it. What has been the biggest challenge since launch?
Making the evidence chain reliable without turning the runtime into a heavy observability layer. That balance has been tricky.
Interesting approach. What was the hardest part to get right?
Binding the decision, execution and evidence together consistently. The trail has to remain useful even when something goes wrong.
Nice progress. What is the next thing you are focusing on?
Right now, strengthening the runtime evidence and enterprise audit path in 3.0, especially around investigation and traceability.
Nice work shipping it. What has been the biggest challenge since launch?
The same core challenge: making runtime evidence complete enough for real incident investigation without adding unnecessary friction.
Nice work shipping it. What has been the biggest challenge since launch?
Definitely the execution boundary. Capturing what happened at the right level of detail, while keeping the runtime predictable.
Have early users identified incident investigation as an urgent recurring problem, or is demand for runtime evidence still primarily driven by teams designing agent infrastructure?
We’re seeing both, but incident investigation makes the need especially clear. Infrastructure teams care about the evidence from day one; security teams care when they need to reconstruct what actually happened.
The execution boundary is the key insight. Prompt quality is hard to audit after the fact, but a durable trail lets you replay the request, decision, tool call, and result. That makes incident review useful instead of guesswork.
Exactly. That’s the direction we’re taking: make the execution trail a durable relationship between request, decision, action and evidence—not just another log line.
Nice work shipping it. What has been the biggest challenge since launch?
Keeping the evidence trustworthy across the full execution path has been the biggest one. It’s easy to log events; it’s harder to preserve their relationship.
Nice work shipping it. What has been the biggest challenge since launch?
This is great work — what's the biggest thing you'd do differently if you started over?
I’d define the execution boundary earlier. We initially focused more on model behavior; the bigger challenge turned out to be controlling what happens after the model decides to act.
This is great work — reminds me of some of the calls I've had to make building Xstream4K. What would you do differently if you started over?
I’d design the evidence trail from day one. Retrofitting observability later is painful — keeping request → decision → execution connected from the start makes a huge difference.
This resonates a lot — how long did it take before you saw any real signal on it?