30 Days of AIDay 27 of 30 · Week 4: Enterprise Workflows
Course outline▾

Week 4 · Enterprise Workflows

  1. Day 22Autonomous Agents — From Passive LLMs to Goal-Driven Execution
  2. Day 23Tool Use and Function Calling — Connecting LLMs to APIs, Databases and Shells
  3. Day 24Multi-Agent Orchestration — Supervisor, Worker and Evaluator Patterns
  4. Day 25Automated CI/CD — Automating the Software Lifecycle for AI Models
  5. Day 26Zero-Trust Security for AI — Sandboxing Ephemeral Execution and Model Egress
  6. Day 27Observability and Tracing for Agentic Systems — Telemetry, Logs and Metrics
  7. Day 28Human-in-the-Loop Architecture: Machine Second, Human First in PracticeComing soon · 2026-10-28 · 7 PM IST
  8. Day 29Managing Technical Debt, Drift, and Model Governance in Enterprise ITComing soon · 2026-10-29 · 7 PM IST
  9. Day 30The 10-Year Horizon: Architecting IT Strategy for the AI-Native EnterpriseComing soon · 2026-10-30 · 7 PM IST
Open the course page →

Day 27: Observability and Tracing for Agentic Systems — Telemetry, Logs and Metrics

2026-10-27 · 7 min read

Standard monitoring watches status codes, latency and memory. Those numbers can look perfect while an agent is failing. It can return HTTP 200 OK with a completely made-up answer, or burn through forty planning steps going in circles. To debug an agent you need to see its decisions, not only its servers.

In plain terms: A flight tracker that only shows "plane is in the air" tells you nothing about whether it is heading to the right city. You need the flight path.

HTTP 200 does not mean it worked Classic monitoring seesStatus: 200 OKLatency: 1.2 sMemory: normalLooks healthyWhat actually happenedAnswer was hallucinatedOr the agent looped onplanning for 40 stepsInvisible to metricsAgents need traces of their decisions.Not only server health.
An agent can return HTTP 200 with normal latency while giving a hallucinated answer or looping on planning. Standard server health metrics cannot see that, so agent systems need traces that record their decisions.

The three pillars of agent observability

  • Traces capture the end-to-end path of a run. Every model call, retrieval and tool call becomes a nested span with its time, input tokens and output tokens, plus enough prompt context to reproduce the step.
  • Metrics track the cost and health of the system: token use, cache hit ratio, context-window utilisation and cost per transaction, by team or workflow.
  • Logs record structured state changes in a multi-agent graph, so you can find the step where the reasoning diverged from what you expected.
One request as a trace agent.run4.8 splan (llm call)1.1 s · 820 in / 140 out tokretrieve (vector db)0.4 stool: run_sql0.9 sanswer (llm call)1.8 s · 1,950 in / 310 out tokEach step is a nested span with its prompt context, tokens and time.Span names and numbers are illustrative.
A trace records every step of an agent run as nested spans: planning, retrieval, tool calls and answer generation, each with its latency and its input and output token counts. The span names and numbers are illustrative.
Three kinds of telemetry Tracesthe path of one runevery tool call,retrieval and modelcall as a spanMetricscost and performancetokens, cachehits, context use,cost pertransactionLogsstate changeswhere thereasoning divergedfrom expectedbehaviourTogether they turn debugging from guesswork into analysis.
Agent observability uses three kinds of data. Traces show the path of one run, metrics track tokens, cache hits, context use and cost, and logs record state changes so you can find where reasoning diverged.

Standards: OpenTelemetry and correlation IDs

  • Vendor-neutral instrumentation. Using OpenTelemetry (OTel) means your telemetry can flow into Prometheus, Grafana, Jaeger or a commercial backend without locking you to one vendor. OpenTelemetry also has emerging conventions for generative AI attributes, which are still evolving, so check the current names.
  • Correlation IDs. Give each incoming request a unique trace ID that follows it through the gateway, application, vector database and agent workers. Search that ID and you see one user interaction end to end.
One ID follows the request GatewayAppVector DBAgent workerLLMtrace_id = 7f3a9c… on every hopSearch the ID and see the whole user interaction.OpenTelemetry carries it across services for you.
A unique trace or correlation ID attached to each incoming request travels through the gateway, application, vector database and agent workers, so operators can follow one user interaction end to end. OpenTelemetry propagates it across services.

Here is a minimal Python example. It assumes you have installed opentelemetry-sdk and opentelemetry-exporter-otlp, and that a collector or a recent Jaeger is listening for OTLP on port 4317. The llm and run_tool functions stand in for your own.

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

provider = TracerProvider()
provider.add_span_processor(BatchSpanProcessor(OTLPSpanExporter(endpoint="localhost:4317", insecure=True)))
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("support-agent")

def handle(question: str, request_id: str):
    with tracer.start_as_current_span("agent.run") as run:
        run.set_attribute("app.request_id", request_id)

        with tracer.start_as_current_span("llm.plan") as span:
            plan = llm(question)                                  # your model call
            span.set_attribute("gen_ai.usage.input_tokens", plan.input_tokens)
            span.set_attribute("gen_ai.usage.output_tokens", plan.output_tokens)

        with tracer.start_as_current_span("tool.run_sql") as span:
            span.set_attribute("tool.name", "run_sql")
            rows = run_tool("run_sql", plan.sql)
            span.set_attribute("tool.rows_returned", len(rows))   # 0 rows is a useful signal
        return rows

One caution: prompts can contain customer or internal data, so redact sensitive fields before they go into spans or logs. With tracing in place, agent debugging moves from guesswork to something you can inspect, replay and audit.

Coming Up Next

Day 28: Human-in-the-loop architecture: machine second, human first in practice.

#Observability #OpenTelemetry #DistributedTracing #MLOps #SRE