What agentc instruments out of the box and why it matters in production.
agentc agents are instrumented out of the box. Every run, graph step, model call, and tool execution produces structured logs and traces without any code on your part. Observability is configured entirely through environment variables at startup, so you turn it on per deployment without changing the manifest or recompiling.
An agent emits several kinds of operational signal, each answering a different question.
Logs answer "what happened." The agent writes structured JSON logs to standard output at a configurable level, which is the first place to look when you want a running narrative of a process.
Traces answer "where did the time go, and what led to what." Every significant operation produces a span. Model spans include rendered system instructions, ordered input, completed output, and token usage when the provider reports it. Local tool spans include arguments and successful results. Spans are nested, so you can follow the full causal chain of a run and see exactly which tool call or model request dominated a slow response.
Metrics answer "how much, and how often." Aggregated measurements such as request counts, durations, and token usage are recorded so you can chart throughput, latency, and cost over time rather than reasoning from individual runs.
Errors answer "what broke, and where." Optional error reporting captures unhandled errors and panics and sends them to an error-tracking service, tagged with the agent version and environment.
Logs, traces, and metrics are all exported using OpenTelemetry over OTLP, the OpenTelemetry line protocol. You point the agent at a single OTLP endpoint and all three signals flow there. The natural target is an OpenTelemetry Collector, which receives the telemetry and routes each signal onward to whatever backends you use, for example Jaeger or Grafana Tempo for traces, Prometheus for metrics, and a log store for logs. Any OTLP-compatible backend works, so you can also send directly to a vendor such as Honeycomb or Datadog without a collector in between.
When OTLP export is enabled, model and tool content is included in exported traces. Prompts, messages, media, tool arguments, and tool results may contain secrets or personally identifiable information. Multimodal input and long contexts can also increase trace volume substantially.
The invoke_agent span includes two views of the run. The portable view contains the input messages
and final completed response using the OpenTelemetry GenAI message schema. The exact agentc view
contains the complete graph input and terminal outcome, including the resulting state for completed,
interrupted, and cancelled runs. Exact state can contain model configuration, capability overrides,
context variables, tool definitions, arbitrary context, and conversation history, so it can be larger
and more sensitive than the portable message view.
Production deployments should account for backend retention, access control, trace volume, and cost. An OpenTelemetry Collector can remove content attributes before traces leave your infrastructure.
An agent in production is a long-running system that calls out to models and tools you do not control. When a run is slow, loops, or fails, prose logs alone rarely tell you why. Nested traces show the shape of a run at a glance, token counts make cost and context growth visible, and error reports surface the failures that would otherwise be buried in log volume. Because all of this is on by default and driven by environment variables, a production deployment gets it for free and a local run stays quiet until you ask for more.
© 2026 pogue.dev. All rights reserved.
CC BY 4.0Search the agentc documentation