Agents will make your telemetry explode. You are not ready.

I have operated systems at scale long enough to know that the scariest failures are not the ones that blow up immediately. They are the ones that accumulate quietly, in the background, until the night you realize you cannot see what is happening anymore.

Agents are going to do that to your observability stack.

Vercel published a number recently that I keep coming back to: 30% of their deployments are now agent-initiated, up 1000% in six months. Claude Code accounts for 75% of those. That is not a forecast. That is already happening, on a platform that processes millions of deployments. The agents are shipping. The code is landing in production. And most teams are monitoring it with the same stack they built for the old world, where humans decided when to deploy.

The old world had a natural throttle. A human had to write the code, open the PR, wait for review, merge, wait for CI. Each of those steps was friction, and friction was the thing that gave your telemetry pipeline time to breathe. Agents remove the friction. That is the whole point. But when the friction disappears, the signals multiply — and most telemetry systems are not built for that.

With 4 data fields you have 15 possible combinations. With 50 fields you have 1.1 quadrillion.

That is Charity Majors, making the combinatorial argument for why context-rich telemetry is not a nice-to-have. It is the architecture. When an agent ships three PRs in the time it used to take a human to write one, you do not just get more events — you get more combinations of state that can go wrong. Your three-pillars setup (metrics, logs, traces in separate silos) was already struggling with this at human velocity. At agent velocity it collapses.

The three-pillars model has a structural problem that most teams hit but few name: context gets destroyed at write time. Metrics aggregate away the request-level detail. Logs strip the distributed trace. You end up with three buckets of data that individually tell you something went wrong but collectively cannot tell you why.

This is not inevitable. With OpenTelemetry used properly — and I mean properly, not just dumping spans into a collector and calling it done — you can correlate across all three signals through a shared trace context. The W3C trace context propagation that OTel standardizes is exactly the bridge between the “point in time” abstraction of a metric and the full request lifecycle. A counter that spikes means nothing in isolation; tied to a trace ID that connects it back to an agent tool call three deploys ago, it becomes actionable.

Most teams do not get there. They install the OTel SDK, get some auto-instrumentation running, and stop. The result is signals that look correlated but are not — trace IDs that die at service boundaries, metrics that have no trace context, logs that live in a separate system with no join key. Charity is right that the three-pillars framing is partly a vendor construct. But the technical path out of it exists. This is work I help teams do, and the agent era makes it urgent in a way it was not two years ago.

I remember the feeling when I realized the SaaS I was operating had crossed 5000 EC2 instances. The dashboard that had been fine at 500 instances was suddenly lying to me — not because the numbers were wrong, but because the aggregations were hiding the failures inside the averages. Agents will do the same thing to teams that are not paying attention. You will look at your p99 latency, see it is fine, and have no idea that one agent-initiated deploy is quietly hammering a dependency every thirty seconds.

The original sin of AI integration is bolting it onto bad foundations without fixing the foundations. The same applies to observability. Every PR an agent ships is new surface area that can break at 3am. If your telemetry is not built to handle that volume with context intact, you are flying blind at 10x speed.

What does it actually look like when an agent ships code that breaks something? In the old model you had a human author, a PR, a review, a deployment. The trace from incident back to cause was a straight line. With agents you have none of that by default. You have a commit from a model with a generated message. You have no record of which prompt produced it, which tool calls it made, which files it read before deciding to change what it changed. The agent’s decision path is invisible unless you explicitly instrument it.

That is the gap. Not the volume, although the volume is real. The gap is that the agent’s reasoning is not first-class telemetry. When a human makes a bad decision in production you can ask them what they were thinking. When an agent does it you are looking at a black box — unless you built the observability in before the agent shipped anything.

The teams that will handle this well treat agent traces the same way they treat service traces: as something that needs to be designed, not bolted on. Structured logging of tool calls, traces that connect the agent’s action to the downstream effect, context propagation that survives from the agent’s decision point to the production incident.

I am going to write more about what that instrumentation actually looks like in practice. But first I wanted the problem named clearly.

Agents make telemetry explode. Most stacks are not ready. If yours is not, let’s talk.