AI Agents need Telemetry too

We’re now in a world where it’s almost impossible to go a day without hearing those two letters: AI.

Everyone and their grandmother wants to use AI or to build an AI agent these days.

Friend : “Abhiram, I’m building an agent that will book your movie tickets automatically for you.”

Me: “I will book it myself. Thanks”

Friend : “Abhiram, I’m almost done. Tell me which movie, which seat and what price are you willing to pay”

Me: “The Odyssey. Best seat in the house. I can go as high as 400 INR”

<Langgraph whirring>

Friend : “It’s done……..
….

…. Slight problem.”

Thanks to the agent, I am now going to be watching Dhamaal 4 from a seat in the first row but in a Luxe theater for 800 INR.

Ridiculous, perhaps. But definitely not an impossible scenario when dealing with agents and LLM-driven workflows.

For this seemingly simple task, the agent had to get several things right. Different things need to accurately deliver a result favorable to the ask :

a) The movie “Odyssey” has to be rightly captured
b) The interpretation of “best seat” has to be made clearly
c) The nuances w.r.t calling the correct theater API have to be executed correctly
c) The satisfiability of the price constraint has to be verified and communicated back to the user if not met

And if you’ve spent even some time building LLM-powered agents, you’ve probably seen some version of this.

Not necessarily a wrong movie. But possibly:

• the wrong tool was called

• stale information was retrieved

• constraints were ignored

• the LLM confidently filled in missing details

• an API silently timed out and the agent continued anyway

At best, the agent acknowledges its mistake or lack of ability to fulfil the task - based on proper instructions and correct tooling. For example - “I couldn't complete the task because no seats matched your budget.”

But at worst, despite the underlying errors, we might possibly see -

“Ticket booked. Enjoy your movie!”

So, how do we remedy this?? We already know how to debug traditional software.

Who run the world? LOGS! (Okay, Logs, traces And metrics)

A traditional application follows a fairly deterministic path. A request comes in, some business logic executes, a database is queried and a response is returned.

An AI agent is different. It plans, retrieves context, chooses tools, reasons about intermediate results, retries when necessary and often changes course based on what it discovers.

But how do we debug an agent? Agents, along with executing code, are also given the responsibility of making decisions.

This is where Telemetry for agents comes in. We don’t think about it much but given that I’m planning to watch Odyssey, the word “Telemetry” comes from the Greek words “Tele”, meaning remote and “Metron”, meaning to measure.

So, when we think about telemetry today, we naturally think about measuring things like request latency , CPU utilization, memory consumption, error rates etc.

These are still important. But they tell us very little about whether the agent actually behaved intelligently.

For an AI agent, we need an entirely new category of telemetry.

Now imagine the same interaction, but this time, the agent leaves behind a trail explaining why it made every decision.

Now let’s say every agent execution emitted events like these -

{
  "trace_id": "movie-booking-8af2",
  "intent": "Book 'The Odyssey'",
  "planner": {
    "selected_tools": [
      "movie_search",
      "theater_search"
    ]
  },
  "constraints": {
    "budget": 400,
    "status": "NOT_SATISFIED"
  },
  "tool_calls": [
    {
      "tool": "movie_search",
      "latency_ms": 180,
      "status": "SUCCESS"
    },
    {
      "tool": "theater_search",
      "latency_ms": 420,
      "status": "SUCCESS"
    }
  ],
  "decision": "ASK_USER_FOR_HIGHER_BUDGET",
  "outcome": "WAITING_FOR_USER"
}

Without telemetry, all we knew was:

Ticket booked.

With telemetry, we now know:

• the budget constraint was actually evaluated

• the correct tools were invoked

• the APIs succeeded

• no valid booking existed within the user’s budget

• the agent chose to pause instead of hallucinating a solution

BUT One question I had in my mind was :

The rationale here is that, while the tracking of “tools_used”, “constraints_met” etc. is not strictly MEASUREMENT, it’s still tracking vital information that is telling us the behaviour of the agent and therefore, it can be categorized as telemetry.

Now debugging feels like software engineering again , rather than just guesswork as to where my agent could have gone wrong.

In traditional OpenTelemetry, every HTTP request can become a trace¹ and every database query can become a span².

Similarly now in my agent, mapping back to OTel, every movie booking query is a trace and every action within it can be measured as a span.

Microservices are now robust because they’re observable. Agents deserve the same treatment.

Now obviously, this tiny look at observing an agent is only one part of the puzzle in making them reliable. There’s another vast part of the picture called Evaluations (/Evals). But that’s a topic for another day.

---

Notes :

1. A trace is meant to represent an entire journey.

2. A span is an individual leg of a trace

For example, if a trip from Bangalore to Mysore is a trace, the individual parts - from home to the petrol bunk, petrol bunk to the coconut stall on the way, from there to home in Mysore - these are all individual spans.

---

Thanks for reading this edition of Everything Python! Subscribe for free to receive new posts and support my work.

Also check out my Youtube channel and Subscribe. I hope to create more videos on all things Engineering - From coding in Python to Databases and GenAI !