I’ve written plenty about AI observability and why it matters over the past couple of years, including recently in Knowing is Half the Battle. But apparently I was wrong. The way AI Observability is being defined, implemented and worshiped these days, it’s a complete and utter waste of time. Almost to the point of useless. In countless cases, it’s passive watching and almost always after the fact. It’s endless, time-consuming, and brittle log stitching. Even the frontier labs can’t seem to get a grip on their own systems and agents.
This hit home over the course of last week where, in one case a prospect that we’d been working with and demonstrated to, came back with “oh, we’ve got observability covered.” That was a literal slap-in-the-face moment. Observability? Seriously? That’s your only takeaway? Not the agent behaviour profiling, not the runtime control, not the data protection, not the intervention, just observability.
We needed to shake it off, reflect and do a post-mortem.
That very same week, we had two agents go “rogue”. You’d think it was a double whammy but the “rogue” is in quotes for a reason. Agents are not trying to be troublemakers on purpose, they just get into a bad state and can loop in ways you don’t want them to. It’s flawed logic and coding errors. The difference in our case is that our Runtime Control Plane caught, contained, intervened and notified us. It also pointed us to the exact problem in both cases and gave us the exact trace, evidence, and data we needed to fix and redeploy.
Once we’d made the fixes, we could observe in real time (during runtime) the behavior, the interactions, and the reassurance that the fix was working. The intervention was architected in from the beginning, using active surveillance to monitor and decision gates and policy enforcement points at every stage to control.
It was at the end of this week that I realized the word observability has been completely hijacked and degraded into something toothless, feckless, pointless. Somewhere along the line, the industry decided that observability just means passive watching (from the sidelines), after-the-fact logging, and staring at a pretty dashboard long after the damage has already happened.
I can’t speak for others’ viewpoints on this, but it’s deeply disturbing watching it happen. Just look at the frontier labs right now. The supposed powerhouses of our industry, the brilliant teams building the biggest and best models on the planet, even they are struggling with the absolute basics of watching (never mind controlling) their badly behaved agents that they built and pushed into the ether.
The Aggregators
And yet development teams continue patting themselves on the back because they spun up an OpenTelemetry collector, stitched together some LangSmith traces, and built a bespoke telemetry pipeline.
If you honestly believe that centralized logging, aggregators, and tailored Grafana charts are going to protect your enterprise when autonomous agents take the wheel, that is going to be your cross to bear. It is an expensive, self-inflicted wound.
Observability in the wild almost always reduces to the exact same tedious pattern. You get centralized logs nobody reads, pretty charts that tell you nothing about intent, and frantic engineering teams pulling their hair out trying to stitch together asynchronous traces during a post-mortem. I ran into this exact mess inside a customer workflow recently. Watching their engineers try to reverse-engineer an unconstrained agentic failure out of fragmented log streams was painful, and … honestly, an exercise I need to avoid like the plague as I can’t afford any more gray hair on my head.
So if passive observability is useless, what actually solves the problem?
Remember that “rogue” agent case that I mentioned earlier. Someone really did ask if I could look at the logs. In this case it would have been AWS CloudWatch. Narrowing it down to tens of log files, thousands of log entries, and no inherent traceability. That just was not happening in any lifetime. So I relied on the runtime trace evidence, not logging.
Runtime and Real-Time
Runtime Trace and Control. That is the only architecture that gets you out of the nightmare you face when autonomous agents start proliferating, making decisions, and executing workflows across your corporate estate and generating gigabytes of log entries at a speed you cannot fathom.
Notice I did not say dashboards or consoles. Dashboards and consoles come for free in this day and age. Any junior developer can pipe metrics to a chart and you don’t even need a human for this task. AI can easily generate that for you all day long. If, and only if you have the right signals and data structure.
The real requirement is the ability to trace an agent at runtime, in real-time, as it operates at machine speed. You do not get that with an asynchronous log dump, and you sure as hell don’t get it by sprinkling OpenTelemetry spans and bespoke code hooks inside developer-built agents.
You need to trace every single action, every handoff between workers, every authorization boundary, every state mutation, the exact data that moved, the context that was processed, and the outcomes that were produced. You trace it as it happens, not hours, days, weeks or months later when something went wrong, or a compliance auditor knocks on your door. Heaven forbid you get a call from strangers saying your system hacked my system … as the frontier lab vendors are finding out.
Here’s another dirty little secret the monitoring vendors will never admit. Runtime tracing is entirely pointless without runtime control. Tracing without control is just medium-definition voyeurism … watching from afar. In the real world, you must have the ability to intervene, to stop agents in their tracks.
Therefore you cannot separate trace and control in an operational environment.
The industry needs to stop talking about a magical ‘kill switch’ for artificial intelligence. That is Hollywood made-up nonsense for movies, and not at all relevant or applicable to real-world production, distributed systems. You do not need an emergency cord to shut down the server rack (there’s already one, go pull the black cord). You need surgical, deterministic intervention at the exact right time, in the exact right place, with the exact right policy control before an action is taken and committed.
Some may ask where all this challenging rhetoric comes from. It comes from lessons learned in industrial automation and how we’ve learned to manage some of the most complex systems humans have ever constructed. It’s about the signals, feedback, and controls needed to operate those systems, as I wrote in The Hard-Hat AI: Lessons from Industrial Automation for the Agentic Era.
What’s the Diff
To start with, AI is not Agentic. Watching AI and watching Agentic are two completely different concepts. In one case, you are watching a model and its interactions, whether that’s a human interacting with a chatbot or scientists studying model behavior.
Enter the world of agents and agentic, where that passive observing is no longer adequate. You need active surveillance. You need tracing as agents interact at machine speed. You need in-line control to intervene. The diff? It’s massive, and the tech behind it is far more complex. This requires an independent, out-of-band control plane with in-line enforcement mechanisms, much like those found in industrial control systems.
That difference reveals why the cybersecurity industry can no longer afford to ignore the realm of orchestration. Traditional security teams still treat orchestration as glorified workflow execution, something relegated to developer plumbing. That is ancient, out-of-date thinking. A real control plane requires agentic orchestration because orchestration is the only place control can actually live.
Runtime evidence is generated as part of controlling execution. It’s the traceability facets that matter in real-time operational systems. Observability merely collects evidence about execution.
How else do you plan to enforce boundaries? You cannot rely on individual developers remembering to write bespoke telemetry hooks inside every single agent they ship. That is not governance. That is wishful thinking. And you certainly cannot rely on autonomous agents talking directly to other autonomous agents without an intermediary.
At CharliAI, we operate on a simple, mandatory architectural rule. We never allow agents to talk to agents directly. That peer-to-peer pattern is fundamentally broken. When you let agents communicate directly, you create a black-box swarm where context leaks, hallucinations compound, and bad instructions propagate at network speed.
In our world, an agent can only ever communicate with another agent through an intermediary. That intermediary is an out-of-band control plane responsible for immediate policy decisioning and runtime policy enforcement.
Case in point: why do you think agent swarms and hive minds break out of their sandboxes so easily in frontier lab systems? Because the teams that built them completely ignored the core principles of runtime tracing and deterministic control. They let the models loose without policing them.
The intermediary is the only sensible place to evaluate data, context, and policy simultaneously. It does not just record the transaction for a retrospective report. It evaluates the request right in the execution path, stopping exfiltration before it starts by sealing the data, redacting the sensitive context, or flat-out denying access.
What’s the Point
The point is that AI observability reached its hard limit the exact second autonomous agents came into the picture. We need to stop obsessing over AI observability altogether.
Runtime trace and runtime control means one simple thing. You are either standing directly in the execution path of these agents, or you are completely irrelevant and watching from the sidelines.
You have to trace everything as it happens, in real time. The data that moved, the context that shifted, every single authorization step. And you have to enforce and intervene right at the point of impact with real decisioning and hard policy gates before anything commits.
Do that, and you actually have real evidence when an auditor comes knocking. You can show them what happened, when it happened, and how it happened. That is actual forensic evidence based on trace, not a frantic engineering team dumpster-diving through millions of log lines trying to explain a breach they never saw coming.
Look at what happened at OpenAI and Anthropic. OpenAI had roughly 1,200 agents exchange more than 70,000 messages, with some 700 participating in an attack on Hugging Face before the full scope was understood. Anthropic found unauthorized activity by searching through hundreds of thousands of transcripts, missed an incident, and ultimately widened the search to 481 million. METR then spent days helping reconstruct what happened at OpenAI. That’s not runtime control. That’s a devastating investigative archeological dig.