AI Agent Observability: Debug Logs, Tool-Call Traces, and Evidence in the PR

When a coding agent hands you a pull request, you face a question a human PR rarely raises so sharply: what did it actually do, and why should I trust it? Agent observability is the answer — the logs, traces and evidence that let you reconstruct the agent's work instead of taking a plausible-looking diff on faith. Two recent additions show where the tooling is heading: GitHub's Copilot CLI debug and tracing features, and Cursor's security agents that attach evidence to their findings.

Debug logs: a chronological record of what happened

Per GitHub's June 2026 changelog, Copilot CLI added an Agent Debug Log panel (public preview) that "shows a chronological event log of agent interactions during a Copilot CLI session." GitHub calls it "especially useful when debugging custom agents and orchestrated sub-agent workflows" — exactly the case where a single summary hides what went wrong inside a multi-agent run. You enable it under Settings → Tools → GitHub Copilot → Chat → Enable Agent debug File Logging (with admin enablement required for Business/Enterprise).

A chronological event log is the floor of observability: when an agent produces a wrong result, you need to see the sequence of steps it took, not just the outcome, to find where it went off the rails.

Tool-call traces: how it did it, not just what it said

The next layer is tool-call visibility — seeing the actual operations the agent ran. The same Copilot CLI release ships "support for multiple isolation modes, live session progress, and tool call visibility." Each tool call (a file read, a shell command, an MCP tool) is a discrete, auditable action. Without this, an agent is a black box that emits a diff; with it, you can see that it ran the test suite, queried the database, or — the thing you actually want to catch — touched a file it had no business touching.

Copilot CLI also adds session-analysis commands that turn the log into something usable:

• /chronicle standup — "generates a short report summarizing what you worked on in your recent CLI sessions."
• /chronicle improve — "analyzes your session history to identify patterns where Copilot may have misunderstood your intent or where there was a lot of back-and-forth."
• /chronicle tips and /chronicle search — personalized recommendations and history search.
• /compact — manually compress session context to keep long runs manageable.

Evidence in the PR: making the result auditable

The strongest form of observability is evidence attached to the change itself, so a reviewer can verify the agent's claim without re-running the work. The Claude Code best-practices docs frame this as a habit: have the agent "show evidence rather than asserting success: the test output, the command it ran and what it returned, or a screenshot of the result," because "reviewing evidence is faster than re-running the verification yourself, and it works for sessions you weren't watching."

Cursor's security agents show what this looks like at scale. Per Cursor's blog, its dependency-patching agent Anybump "runs reachability analysis to narrow vulnerabilities to those that are actually impactful, then traces through the relevant code paths, runs tests, checks for breakage, and opens a PR once tests pass." Every step in that chain is evidence: the reachability analysis justifies why a fix matters, the test run proves it does not break things, and the PR is only opened after the tests pass. Cursor reports its security agents are "reviewing 3,000+ internal PRs each week, catching 200+ vulnerabilities."

Should you trust it? The gates that come with the evidence

Observability is necessary but not sufficient — you also need gates that decide what happens with the agent's output. Cursor's rollout is a useful template. Its Agentic Security Review staged trust deliberately: findings first went to "a private Slack channel monitored by our security team," then "we turned on PR commenting, then implemented a blocking gate check." It also guards against noise — a classifier "powered by Gemini Flash 2.5 that determines when two semantically distinct findings describe the same problem" deduplicates reports — and adds a final safety net, where "Cursor's canary deployment pipeline provides a final safety gate" post-merge.

How to read an agent PR

1. Skim the trace, not just the diff. Confirm the agent only touched files in scope. A tool-call trace that shows an edit outside the task is a red flag regardless of how clean the diff looks.
2. Demand evidence. Tests run and passed? A screenshot for a UI change? Reachability analysis for a security fix? If the agent asserts success without evidence, treat it as unverified.
3. Check the gate. Know whether this PR went through a human channel, a comment, or a blocking check — and never let unattended agents skip straight to merge.

This is the operational complement to auditing AI-generated code before it ships: observability is what makes that audit fast instead of a from-scratch re-review.

FAQ

What is AI agent observability?

The ability to see what a coding agent did and why — through debug logs (a chronological record), tool-call traces (each action it ran), and evidence attached to its output (tests, screenshots, analysis) — so you can verify the result instead of trusting the diff.

What does Copilot CLI expose?

A public-preview Agent Debug Log panel with a chronological event log, tool-call visibility, isolation modes, live session progress, and /chronicle commands that summarize and analyze your session history.

How do agents prove their work in a PR?

By attaching evidence: test output, the commands they ran and returned, screenshots, or analysis like Cursor's reachability check that opens a PR only after tests pass.

Does observability mean I can trust the agent automatically?

No. Observability lets you verify; gates decide what happens. Stage trust — route findings to review, then PR comments, then a blocking check — and keep a human between the agent and production.

Bottom line

Trusting an agent's PR is a function of how much you can see. Debug logs tell you what happened, tool-call traces tell you how, and evidence — tests, screenshots, reachability analysis — lets you verify the result without redoing it. Copilot CLI's debug panel and Cursor's security agents show the pattern: make the work auditable, then stage trust through gates. Read agent PRs by the trace and the evidence, not the diff alone, and never let an unattended agent skip the gate.

Sources and further reading