← All Blog

Agent work should be inspectable

Baz Sessions now trace Planner, Merger, Spec Reviewer, and full repo security scans, not just PR reviews.

BlogShaked EdriJune 30, 20264 min read
sessionsobservability
Agent work should be inspectable

Agents are easy to trust when they produce a clean, correct answer. They are much harder to trust the moment something goes wrong, or the moment someone with governance or security responsibility asks a simple question: what did the agent actually do, and how did it get there. If the honest answer is "we do not fully know," the agent has a ceiling on how much autonomy it will ever be given.

That is the core problem with most agent output today. A comment on a pull request, a plan, a merged branch, or a security finding is a result, not an explanation. It tells you what the agent concluded, not the path it took to get there: which files it looked at, which tools it called, what context it pulled in, and why it stopped where it did. Engineering managers rolling agents out to a team need that trail to build confidence. Platform teams need it to debug when a run misbehaves. Security and AI governance owners need it because an unauditable agent is not one they can sign off on, no matter how good its output looks on a good day.

We built Sessions to close that gap, and we have been expanding what it covers.

From one flow to every flow

Sessions started as a way to see how a PR review was produced: which reviewers ran, what they analyzed, and how findings moved from draft to published comment. That was useful, but it only covered one type of agent run. Baz now runs several kinds of agent work, and each one deserves the same level of transparency.

Sessions now cover:

  • PR review sessions, the original flow: enriched diff, findings, reflection, and comment merge.
  • Planner sessions, which trace how a plan was generated, from the initial invocation through every tool call the agent made, to the final plan, plus the events and stats for the run.
  • Merger sessions, which trace how changes were merged and what happened along the way.
  • Spec Reviewer sessions, which trace how a change was checked against product requirements, including the context the agent pulled in to make that judgment.
  • Advanced Security Scan sessions, which run against a full repository instead of a single pull request, and trace the scan from invocation through tool calls to findings.

That last one matters on its own. Most of what an agent does happens in the context of a PR, where the blast radius is a single change. A full codebase scan has no such boundary. It is reading and reasoning across an entire repository, so the case for a traceable record is even stronger, not weaker.

What "inspectable" actually means

Across all of these run types, a session gives you the same three things: a timeline of stages, the tool calls made at each stage, and the outcome the run produced. You can see whether a Planner session is still investigating or has already produced a plan. You can see which tools a Spec Reviewer used to pull in requirements before it made a call. You can see whether a repo-wide security scan is queued, running, or finished, and what it found.

This is not raw log output. It is a structured, product-level record designed to answer the questions a team actually asks after the fact: did this run do what we expected, where did it spend its time, and can we reconstruct why it reached this conclusion. That structure is what turns an agent from a black box you either trust or do not into a system you can actually audit.

Why this belongs to more than engineers

An eng manager rolling out agent-driven review or planning wants to know the tool is doing sound work before scaling it to more repos. A platform team wants a place to debug a run that failed silently instead of reverse-engineering it from partial output. A security or governance owner needs a record that survives the question "how do we know this agent didn't miss something, or do something it shouldn't have." Sessions is built to answer all three from the same underlying data, regardless of which agent ran.

As we add more agent capabilities, the run type will keep changing, but the expectation should not: every agent action Baz takes, whether on a pull request or an entire repository, should leave behind a record you can open, read, and trust. Take a look at how your recent Planner, Merger, Spec Reviewer, and security scan runs show up in Sessions today.

Ready to see Baz in action?

Dive into Baz and see how it helps teams review plans before code is written.