Definition
Agent telemetry is evidence about an execution. What it can answer depends on which events, fields, relationships, and boundaries were captured; interpretation still requires domain judgment.
Telemetry is often described by volume: more logs, more events, more retention. Volume is not the same as answerability.
A small structured record may answer a question exactly. A million unlinked text lines may never answer it at all. The difference is whether the evidence the question depends on was preserved.
Remove the fields
Turn fields off — then try to earn the answers back.
You have 40 GB of logs. Can they answer the question?
The agent read the same file twice at turn 7. Was that repeat real work, or waste?
Answering that takes specific evidence: the tool identity and arguments (was it the same call?), a result fingerprint (did the result change?), and the invocation that issued it. Some questions have that evidence. One does not.
How many retries happened before capture started?
Every chip is a capture decision someone made before the session ran. Tap one to un-make it.
Telemetry questions depend on captured fields
“Did the agent repeat the same call?” sounds like a simple query. It requires at least a tool identity and comparable arguments. A normalized argument hash makes the comparison reliable across records.
“Did the repeated call return the same information?” has another dependency: comparable results or a result fingerprint. Without it, identical arguments do not establish identical outcomes because the underlying file, API, or environment may have changed.
Each question has its own minimum evidence set.
| Question | Minimum useful evidence | What absence means |
|---|---|---|
| What failed? | tool status + linked result | Failure count is unknown |
| Was this repeated? | tool name + normalized arguments | Calls cannot be compared reliably |
| Did the result change between two identical calls? | result content or fingerprint | Result equality is unknown |
| What did the tree cost? | parent linkage + per-session usage | Descendants cannot be attributed |
| What happened after the last edit? | artifact markers + event order | The boundary cannot be located |
A missing field means unknown, not zero
If artifact_change is absent, the correct answer to “were there calls after the last change?” is unknown, not no. If parent linkage is absent, the correct child cost is unknown, not zero.
This distinction prevents a thin record from producing confident but unsupported conclusions.
Missing telemetry does not always produce a worse estimate. Sometimes it removes the possibility of an answer.
More logging volume can’t repair a missing relationship
Suppose the parent and child sessions both have complete transcripts and token ledgers but no parent identifier. Their timestamps overlap. Their titles look related. A human might infer that they belong together.
That inference can be useful for investigation, but it is not equivalent to captured linkage. Adding more message text does not turn a guess into a durable relationship. The same is true for tool calls and results: without a stable call identifier, proximity is only a heuristic.
Structure determines which records can be joined. Content determines what those records say.
What agent telemetry can answer: descriptive boundaries
Telemetry is strongest when answering descriptive questions:
- what request was made
- what result came back
- when an event occurred
- which session spawned another
- how many tokens were reported
- which artifact-changing event happened last
These facts can establish a boundary for analysis. They do not automatically explain whether the behavior was good.
What agent telemetry can’t answer: intent and value
The specimen spends money after the test first passes. An artifact marker can locate that verification tail. It cannot decide whether the tail was prudent verification or wasteful wheel-spinning.
A repeated file read may be redundant. It may also confirm that an edit landed, recover from a compacted context, or protect against concurrent changes. A high-cost child may be unnecessary, or it may have prevented a much longer failure.
Telemetry describes the execution. Whether a result was correct, valuable, or evidence that the agent learned something is an evaluation question, and evaluation needs task context, expectations, and judgment.
A six-dimension model for agent telemetry fidelity
“High fidelity” is not one switch. This is the model Paper Compute uses to reason about whether a session record can answer an operational question, and a record can be strong in one dimension while weak in another:
- content: were inputs and outputs preserved?
- sequence: is event order trustworthy?
- identity: can calls, results, turns, and sessions be joined?
- usage: are token categories and costs attached to invocations?
- topology: are parent and child sessions linked?
- effects: are artifact or environment changes represented?
A field checklist should begin with the questions you need to answer, then work backward to these dependencies. Capturing everything without a query model creates an archive. Capturing the right relationships creates evidence.
The mental model: telemetry answers only what it captured
Telemetry answers questions only when it preserved the necessary evidence at capture time. When a dependency is missing, say unknown. When the facts are present but intent is ambiguous, say requires interpretation.
That vocabulary is more honest—and more useful—than treating every blank as zero or every pattern as a verdict.
Why relationships and boundaries decide what telemetry can answer
Volume is easy to add; answerability is harder. When data is captured without the relationships and measurement boundaries a question depends on:
- incident analysis turns into inference
- optimization rests on guesses about what happened
- evaluation lacks the evidence to judge an outcome
The remedy is structural: capture the identity, links, and boundaries a question needs before the run. More logs alone will not add them. See agent observability.
Continue from Foundations: capture, telemetry, and analysis
You now know what an execution contains, where its cost comes from, how sessions relate, and what evidence telemetry needs to preserve. That is the shared mental model the rest of the Concepts library builds on.
From here the path runs in one direction: record the session, turn that capture into a behavioral record, then ask operational questions of it. Capture, then telemetry, then analysis is the order the next concepts follow.
What can your agent infrastructure answer today?
Five questions drawn from the four lenses. Answer honestly; the point is what the answers reveal, not the number.
0 / 5 answered.