The Agent Identity Crisis: AI Agents, Collectors, and Agent Observability

Two weeks ago, I was prepping for a call with a large utility company. The account notes were unambiguous: they’re against “anything agentic.” So we planned around it. Dial back the AI conversation, lead with something else.

Then, during our own prep call before the meeting, somebody asked whether that’s actually what they meant. It wasn’t. They weren’t objecting to AI. They don’t install collector agents on their hosts. A deployment policy, not an AI philosophy.

Nobody was sloppy here. They wrote down what they meant, we read what it said, and to top it off, this was the third time in a month I’ve seen a similar scenario play out. That’s what makes this worse than ordinary jargon confusion: both sides think they’ve been clear, and you can get a long way into the wrong conversation before anyone notices you are talking about different things.

Before Agentic AI, “Agents” Meant Collection

Ask anyone in monitoring about agents in 2016, and you were asking about collection. Do I have to install something? On every host or just some of them? What’s the footprint? What breaks when I patch the OS? Who owns the change ticket?

Those were operational questions, and they were good ones. The answer shaped the deployment plan, the security review, and about six weeks of somebody’s calendar.

For plenty of shops, they were never really questions. That utility company requires agentless collection — not a preference they’d trade away for a good-enough product, but a requirement. Which is exactly why “anything agentic” landed in their notes in the first place. Nobody there was taking a position on AI. They were restating a rule they’ve had for years, in the vocabulary they’ve always used for it.

The industry mostly solved this in the open. The OpenTelemetry Collector, Grafana Alloy, the general drift away from proprietary binaries toward open standards: all of that happened because nobody enjoyed maintaining a vendor’s software on ten thousand machines. OTel deserves most of the credit for how much better this has gotten.

What is an AI agent?

An AI agent is an orchestrator. It runs a multi-step process, using models, tools, and skills, to accomplish a task.

That’s the definition we use, and the useful word in it is orchestrator. An agent isn’t a model call. It’s the thing coordinating a sequence of them, along with whatever tools and data it needs, until a task is finished.

I’d also be a little suspicious of anyone with a cleaner definition, because the interesting variable isn’t what an agent is. It’s how much it’s allowed to do. An agent that summarizes your alert queue and an agent that reconfigures your load balancer are both, accurately, AI agents. They are not the same risk profile or the same conversation with your security team. “Yes, we have agents” is a nearly meaningless answer on its own.

But whatever the answer turns out to be, none of it touches collection. A collector agent’s job is to collect data. An AI agent’s job is to observe, reason, and act on that data. One is a sensor, the other is a decision-maker. Same five letters, unrelated jobs.

So “do you have agents?” is now three questions

When somebody asks it today, they’re asking one of these. It’s worth finding out which before you answer.

“Do you have AI agents?” A capability question. Can the platform do something, not just show me a chart?

“Can you monitor AI agents?” Increasingly common, and genuinely hard. My agent calls a model, the model calls three tools, one of those tools is somebody else’s API. When it’s slow, where do I even look?

“What do I have to install?” The old deployment question. Do I need to install a collector agent? Or is it agentless collection?

Three answers, and they have nothing to do with each other. Agentless is a deployment answer. Agentic AI and Agent Observability are capability answers. They aren’t on the same axis. A platform can be entirely agentless in how it collects, observes AI agents, and be heavily agentic in what it does with the data, and there’s no contradiction in that at all.

Virtana’s Approach to AI Agents, Agent Observability, and Agentless Collection

“Do we have AI agents?”

Yes, six in production, with more being deployed every quarter. Virtana’s agents do root cause analysis. They run interactive troubleshooting sessions. They answer natural-language questions against alert and telemetry data. They write event correlation and enrichment policies. They write automated response policies, and they answer documentation and how-to questions, so nobody has to dig up the PDF.

Notice the pattern. Most of them produce something a human then reviews: a remediation script, an analysis, a policy, an answer. That’s deliberate, and it’s what customers tell us when we ask. An agent finds the problem, names the fix, then waits for the human-in-the-loop to approve. Nobody with revenue on the line wants an autonomous remediation loop they didn’t approve. This was true before AI agents with scripted remediations and is even more true now with non-deterministic LLMs. What that buys you isn’t magic; it’s the compression of investigative work and mean time to resolution (MTTR) that vendors have been trying to automate for a decade, and it ships with the Virtana platform rather than as a separate thing to buy or install.

“Can we monitor AI agents?”

Yes – this is the one I’d argue is the most important. We build agents, which means we’ve had to think hard about how to watch them when they misbehave. The first thing you learn is that the unit you care about isn’t the service. Take a service called “medical writer.” Inside it are two agents, one summarizing conditions and one summarizing treatment, both hitting the same model. To the topology, that’s one service. To anyone debugging it, those are two completely different things that fail in completely different ways. If your tooling stops at the service boundary, you’re averaging two agents together and wondering why the numbers don’t explain anything.

That’s the same problem I’ve spent years arguing about with trace paths, which is why we handle it the same way. We track who’s calling whom — service to agent, and agent to agent — and break out performance and errors for each of those routes separately. Then we highlight the paths that are degrading instead of making you go find them. Underneath that sits the infrastructure layer: GPUs (which can run in the cloud or On-Prem), the orchestration containers the agents run in, and the storage and network the whole pipeline depends on. It’s early. Agent observability is a young discipline, and I expect it to evolve rapidly as more organizations deploy agents in production. But the shape of the problem is deeply familiar; the failure is rarely inside the thing you’re looking at. That’s been true of hybrid application & infrastructure for over a decade. Agents just added a layer.

“What do you have to install?”

Virtana is the deepest & broadest agentic observability platform, collecting 20,000+ metrics across on-premise and cloud infrastructure. This is primarily agentless collection, with customers deploying a lightweight Virtana Data Collector to collect metrics via SSH and API.

And where an agent genuinely is the right tool, such as for collecting specific GPU metrics to monitor AI Factories, we’ll take the open-source one. If you’re already running the OTel Collector, we ingest it. We’re not going to ask you to rip out working instrumentation to install ours.

AI Agents vs. Collectors: Where Observability Terminology Is Headed

Here’s my prediction: the collection side eventually gives up the word, and we just say collectors. Part of the industry has already done it: OpenTelemetry calls it the Collector, not the agent, and Alloy is a distribution of that Collector. The naming has been sitting right there for years. What’s kept “agent” alive on the collection side is the agent-versus-agentless distinction. There are legitimate reasons to prefer one or the other for a given use case, but I suspect this won’t survive the AI meaning becoming the dominant one.

We’re not there yet. Nothing is standardized, plenty of vendors still ship something called an agent that installs on a host, and I’d expect a couple of confusing years before the language settles. But if you’re writing documentation, naming a product, or building an RFP template right now, bias toward “collector.” It costs you nothing today and saves you a rename later.

Until then, that utility company and my team wanted exactly the same conversation, and we were an hour from having a different one. All it took to catch it was somebody asking whether we’d read the note right.

That question is free. Ask it more.