You already observe your applications. Agent observability is the same stack, reaching new signals and giving you a new way to investigate.
You get paged at 2am and work backward from a symptom: which service is erroring, what changed, which log line explains it. That loop is familiar, and your OpenTelemetry stack already feeds it. What is new is that the application now includes agents that reason, call tools, and chain steps, so the same page can turn on what an agent retrieved, which tool call stalled, or why it looped. Amazon OpenSearch Service and its observability stack cover both the agent's execution and the application's behavior in one place, so that investigation stays a single thread instead of splitting across tools. Here is how that comes together.
The signal extends
Consider what changes when the thing you are debugging is an agent. You are no longer only asking which service failed. You are asking what the agent retrieved, which tool call stalled, why it looped, and how that cascaded into the application work it triggered. That is new territory for a 2am investigation. It sits on top of the old territory rather than replacing it. The applications you already run do not go away; they gain a new kind of participant whose decisions you now have to see.
Start with what you are now collecting. Agents do not just emit logs. A single agent request can carry repeated prompts, retrieved context, tool arguments, and results across several iterations, and multi-agent or ReAct workflows push that further still, generating many times the data of a simple application trace. To see what happened inside one, you need the full execution chain: every model call, every tool invocation, every reasoning step. That is agent tracing, and the first thing to understand about it is that it extends what you already collect rather than replacing it.
The extension is mechanical, not conceptual. Agent traces arrive as OpenTelemetry spans, the same shape as the application spans you already ingest, so they land in the same store and join the same investigation. That shared landing place is the whole reason this works, because an agent's outcome usually cannot be explained from the agent trace by itself. The reason a task failed often surfaces in a downstream service, an application log, or an infrastructure metric that the agent never sees.
Picture the 2am page again. The agent returned a wrong answer, and its trace shows a tool call that took four seconds and then a retry. On its own that is a shrug. Joined to the downstream spans it triggered, the HTTP call to a search service and the database query behind it, through the identifiers propagated across all of them, the four seconds resolves into a specific slow query on a specific shard. One investigation, not two tools and a spreadsheet of timestamps. Tracing is only the entry point, too: evaluating whether the agent's answers were any good, and analyzing its behavior across sessions, read from this same execution data once it is flowing.
The economics tighten
Cost control is not new and not unique to agents; any team ingesting logs and traces at volume already decides what to keep hot, what to tier, and what to drop. What agents change is the scale, because their loops repeat system prompts, tool schemas, retrieved context, and prior results on every pass, and the volume climbs fast enough that a loose retention design turns expensive in a hurry. The architecture that answers this is the one you want for all of your observability data anyway. Incident triage needs full-text search across prompts, tool results, and logs, a grep for the one line that explains a failure. Fleet analysis needs columnar aggregation over latency, token spend, and error rates across handoffs. Both run on the same retained data, and intelligent tiering moves older data to cheaper storage on its own. It is the same unified retrieval idea that lets an agent read text, vectors, and time series through one interface, turned toward operations, so you hold one copy of the truth instead of two systems whose versions drift apart.
The actor changed
The deepest shift is who is asking. Investigation agents are becoming first-line consumers of operational data, and that is the part that upgrades the stack rather than merely extending it. An agent is good at inferring causes, but only from signals it can trust, and that puts a new demand on the interface it queries: results and their status have to be unambiguous. An empty result has to mean the query completed and found nothing, distinct from a timeout, a partial scan, a stale handle, or a permission denial. A human reads a half-empty chart and senses something is off; an agent takes the bytes at face value, so if the store conflates those cases the agent reasons confidently from a false premise. That status has to travel with the result through every step, because a wrong signal early becomes a confident wrong conclusion later.
This takes nothing away from how you work today. You keep investigating visually when that is the fastest path, and the agent works the same data through an interface built for a machine reader. Teams run many observability tools, so some data will always live outside any single store. The investigation has to cross those sources without copying everything into one system first. What you add is additive: the same OpenTelemetry data you already trust, now also legible to an agent that can act on it.
Standing it up
Putting this in place is mostly a matter of pointing instrumentation you already run at stores built for it. OpenSearch observability ingests OpenTelemetry natively. Logs and traces land in Amazon OpenSearch Service as the store for full-text search and correlation, while metrics go to Amazon Managed Service for Prometheus as the store for time-series analysis, and OpenSearch UI visualizes both together so a metric spike and the traces behind it sit on one screen. The stack correlates an agent step to the application work it triggered and tiers data by age so retention stays affordable. Because the ingestion path is OpenTelemetry, reaching from application observability to agent observability means sending the new spans, not re-platforming: you keep your query languages, your dashboards, and your pipelines, and the agent signal joins them.
Bringing it together
Put the three shifts together and the picture is simple. The signal extends, because agent traces are OpenTelemetry spans that land beside the application telemetry you already keep. The economics stay the ones you already manage, made more urgent by the volume an agent loop generates. And the investigator can now be an agent, which is what turns a bigger haystack into faster answers instead of slower ones. None of that asks you to replace your observability practice. It asks you to point the instrumentation you already run at a store built to hold all of it, and to let an agent read what it finds.
That is the foundation the next step builds on. Once application and agent telemetry live together and an agent can query them and trust the results, a chat interface can sit over the whole thing and the investigation moves into a conversation. See Implement Agent Observability: Extend Your OpenTelemetry Stack on Amazon OpenSearch Service on Medium for a fuller treatment, with a deep dive to come.
Top comments (0)