Visualization tends to get treated as the afterthought of the observability stack. I'd half agree with that, except that the visualization is also what people seemed to like most about my last post.
So here's a condensed version of that blogpost, focused on the pictures only. The question I actually want answered mid-run is a boring one: what is this thing doing right now, and can I trust the bit it just finished? There are a few different layers that claim to answer it. One layer is formed of the pipeline source, the inputs, the outputs. LLM-call observability gives you the prompts, the tool calls, the spans, the token counts - all very useful, but still leaving a gap. Code execution observability is the third thing: mapping the code as it runs and tracing artifacts and their lineage deterministically, without manual instrumentation (a bit like extreme auto-logging). What comes out is intermediate data states, models, agent states, each traced back to the function that produced/transformed it; this would amount to what the executed code actually did, which intermediate step fed which result, and potentially (paired with a few other elements) where an error entered the workflow.
Below is the visualization of a code execution graph for a agent: the agent is moving back and forth through the graph, resolving nodes. At the start, the job has issues throughout every section:
Then, as the agent (in this case codex) works through the graph nested function by nested function, some of them start clearing:
You can open a node if you want more information:
The visualization can be vastly improved, but hopefully it paints a picture. It can help with debugging and understanding what happened afterwards, but also, for any regulated sector, it is pretty useful as a deterministic account of what was executed by your agent.
