NewAgent Observability is live.
Back to directory

Stage 3 of 5 · Production observability

AI agents for production observability

Infrastructure, APM, logs, traces, profiling and incident response, with an agent as the reader.

This is stage 3 of 5 in a guide to monitoring when AI coding agents do the engineering work. This page covers production observability: what changes, what to measure, where your team is on three levels, and which tools cover it.

What changes when agents do this work

Every team already has a tool for production monitoring, which is exactly why this stage is the one that quietly breaks. The telemetry has not changed. The reader has.

There are three directions to keep straight. Observability from agents is the telemetry your agent-written code emits. Observability of agents is watching the agents themselves, which the agent observability stage covers. The third is observability for agents: increasingly the thing reading your telemetry is not a person, and that changes what the data has to look like.

Every default in this category was tuned for a human who already knows roughly what they are looking for, scopes the query before running it, and clicks show more when they need the next page. An agent is a different kind of user on all three counts, and the limits that were invisible become the binding constraint.

What to measure

Result caps, and whether they truncate or error

A cap that returns HTTP 400 is survivable, because the agent knows it failed. A cap that silently truncates is worse, because the agent reasons over a partial answer and reports it confidently.

Whether pagination exists at all

Several connectors return a first page and offer no way to ask for the second, which makes results 20 through 40 unreachable within a session.

What sampling and adaptive retention have already dropped

Adaptive features share one rule: keep what has been queried before. For dashboards that is right, because a dashboard asks the same question daily. An investigation asks a question nobody has asked yet, which is precisely the data these features drop.

Your own client's output limits

The limit chain includes the agent. A query that passes the backend's caps can still come back truncated because the client refused the payload size.

Three levels, from doing it by hand to letting the system do it

Find the level your team is at today. The next one is the step to take.

  1. 01Manual

    Dashboards and a human on call

    Signals are collected and rendered. Someone reads them during an incident. Everything here works, and none of it is reachable by an agent.

  2. 02Instrumented

    The agent can query the data

    A connector is wired up and the agent can ask questions in English. This is the step where the documented limits start to matter, because the first question an agent asks across every host at once is usually the one that hits the cap.

  3. 03Autonomous

    The agent investigates and hands you a conclusion

    Automated investigations, correlation across signals, and a root-cause narrative rather than a dashboard. This only works if the raw history is still there, which is why sampling policy is a production observability decision and not a cost decision.

Tools that cover this stage

These are the tools that cover this stage. Each label says whether the tool has an MCP server of its own. The ones with a directory page link to it.