What your agent did last night

An agent runs overnight. In the morning, a customer asks what it did with their data. You open your logs and find a request id, a duration, and a token count.

That gap, between what you logged and what you were asked, is the reason agent observability is a different problem from application observability.

Three things ordinary logs miss#

Standard instrumentation was designed for code you wrote. An agent's interesting behaviour happens in the space between your code and the model.

Which tools actually ran#

You know which tools you registered. Whether the model chose to call them, in what order, with which arguments, and what came back: that lives in the message transcript, not in your handlers.

Where it went#

A tool that fetches a URL is a network egress path. If the URL came from model output, the destination was chosen at runtime by something you do not control.

What crossed the boundary#

The payload you sent and the payload you received both potentially contain regulated data. Recording that a call happened is not the same as recording what was in it, or better, recording that a field was redacted before it left.

Reconstruct the session, not the request#

The useful unit is the session: an ordered record of every model call, every tool invocation and result, every destination reached, and every policy decision taken along the way.

// One session, reconstructed at the boundary.
{
  session: 'ses_8f21',
  events: [
    { t: 0,    kind: 'completion', model: 'gpt-5', redacted: ['email'] },
    { t: 240,  kind: 'tool',       name: 'lookup_patient', verdict: 'allow' },
    { t: 610,  kind: 'egress',     host: 'api.myapp.com', verdict: 'allow' },
    { t: 780,  kind: 'tool',       name: 'send_email',     verdict: 'block' },
  ],
}

Once the session is the unit, the customer's question has an answer with a timestamp on it. That is the whole point.