I was building Agora, a concept around multi-agentic reasoning. One afternoon I’d kicked off a debate, wandered off to make coffee, and returned to discover something had gone wrong. I couldn’t tell you what went wrong because, at that point, neither could the app. Somewhere, one of the models had produced an output it shouldn’t have. Another component had interpreted that output, then a retry had happened, or hadn’t happened, or maybe happened twice?
So I did what every developer does:
I opened the logs.
Then the database.
Then the browser console.
Then network requests.
Then another log.
Then another terminal.
Then the source code.
Then back to the database because I’d forgotten what I was looking for.
Twenty minutes later I’d painstakingly reconstructed maybe three hundred milliseconds of execution. And somewhere between opening yet another tab and scrolling through more JSON, I realised how completely bonkers this whole process was.
Fragments
Imagine watching the World Cup Final only to discover nobody had recorded the match. Instead, somebody hands you a folder with possession stats, completed passes, yellow cards, and the final score, then cheerfully informs you that if you’d like to know whether the winning goal was an offside, you’ll need to reconstruct ninety minutes of football from those numbers.
We’d laugh them out of the room. Yet we’ve somehow convinced ourselves that’s a perfectly reasonable way to build software.
Every observability tool gives us another clue. One might record logs, another exceptions, another latency. They’re all useful in isolation, much the same way knowing England had 61% possession is useful when discussing a match. The possession stat isn’t the match. The exception isn’t the execution.
We’ve somehow ended up treating software like a rare animal living somewhere deep inside a forest. We stand outside with increasingly sophisticated cameras pointing in different directions, photographing database queries and network traffic and memory usage, then, when something goes wrong, we pin all the photos to a wall with bits of string and congratulate ourselves on having “observability.”
What we’re really doing is guessing.
But the computer knows exactly what happened.
Just ask the computer
The computer doesn’t need to infer anything because it experienced everything. It executed every function, prompt, file, and database query, and caught every exception in precisely the order those things occurred.
Then it throws almost all that knowledge away and leaves us, the people who weren’t present for any of it, trying to reconstruct the sequence afterwards from whatever crumbs happened to survive.
That seemed inefficient when I was writing software myself, but it becomes almost absurd once AI starts writing code for you.
Everyone talks about how AI has made software development faster, and they’re right. A competent coding model will happily scaffold thousands of lines of code before you’ve finished explaining the feature. Entire applications now appear in the time it once took to write a PRD.
The surface area for failure has exploded accordingly.
Confused agents
Every new function is another place something can break. Every agent now carries out runs. Tool invocations, prompts, retries, or database writes become branches in an ever-growing chain.
And when that chain eventually breaks, because it always does, the AI begins debugging exactly the way we do:
It opens files.
Reads logs.
Searches for exceptions.
Inspects database queries.
Looks at network requests.
Reads more code.
Builds a theory.
Tests it.
Gets it wrong.
Builds another.
It’s not reasoning from perfect knowledge, but investigating a crime scene. Which means we’ve managed to create the slightly ridiculous situation where the same AI that generated the code now spends thousands of tokens trying to infer what that code just did because neither of us bothered to record the execution while it was happening.
Which feels backwards.
In a world where software is increasingly written by AI, understanding execution becomes more valuable than generating code. Code is cheap now; every frontier model can produce plenty of it. The expensive part is the hour afterwards, when production throws its first punch and suddenly five different agents are burning context windows, tokens, and your patience trying to work out why a DB query failed.
Mike Tyson famously said everybody has a plan until they get punched in the mouth. Software is much the same: everybody has code until they press Run.
ActionTrace.start()
These thoughts eventually became TraceAct.
I call it x-ray vision for code. It’s not another dashboard or graph or collection of clues, but an execution record: a complete account of what happened while it was happening, following one action from beginning to end, recording every function, resource touched, prompt, API call, database operation, child action, retry, and output so no human or AI has to spend two hours reconstructing three hundred milliseconds of history.
Because if the computer already knows what happened, we might as well just ask it.
Play with TraceAct here.