What Did Claude Do While I Was Gone? Reviewing Agent Work After the Fact

One of the best things about Claude Code is that you can give it a task and walk away. Go get coffee. Take a meeting. Let it work.

One of the worst things about Claude Code is coming back and having no idea what just happened.

Your terminal has 400 lines of output. Claude asked three questions you never answered, so it made assumptions. It edited 12 files. Maybe it did exactly what you wanted. Maybe it went sideways. You have to piece it together from scrollback, git diff, and hope.

The “what happened” problem

Agentic coding introduces a review problem that doesn’t exist in normal development. When you write code, you have full context because you were there. When an agent writes code, you need to reconstruct the narrative after the fact.

This matters most when:

  • Claude hit an approval prompt and you weren’t there. Depending on your approval mode, it either waited (blocking progress) or auto-approved (and you need to verify what it did).
  • The task was ambiguous. Claude made reasonable choices, but you need to understand what those choices were before you commit.
  • Something broke. Tests fail, the build is red, and you need to trace back through Claude’s steps to find where it went wrong.

In a standard terminal, reviewing agent work means scrolling through raw output, trying to separate Claude’s reasoning from tool calls from your own earlier input. It’s doable, but it’s slow and error-prone.

What a good review workflow looks like

When you come back to a session, you need to answer a few questions quickly:

  1. Did Claude finish the task or is it waiting on me?
  2. What did it change? (files modified, created, deleted)
  3. Were there any decision points? (approval prompts, questions, ambiguous choices)
  4. Does the reasoning make sense? (not just the output, but the approach)

The faster you can answer these, the faster you get back to productive work.

How Crystl makes reviewing agent work practical

Crystl was built around the assumption that you won’t always be watching Claude work. Several features are designed specifically for the review-after-the-fact workflow.

Notifications that tell you what’s happening

Notifications alert you when a shard needs attention — when Claude is waiting for approval, when a session errors out, or when a task completes. You don’t have to keep checking. Crystl will tell you when it’s time to come back.

Persistent, structured session history

Every shard preserves its full conversation history. When you return, you’re not parsing raw terminal output. You’re reading a structured conversation: your prompts, Claude’s responses, code blocks, and tool invocations — all rendered cleanly and scrollable.

If Claude asked a question and waited, you’ll see exactly where the conversation paused. If it auto-approved operations, the approval trail is visible in the session.

Approval modes that match your trust level

Approval modes let you decide up front how much autonomy Claude gets. If you’re stepping away for a quick break, you might let it auto-approve file writes. If you’re leaving for an hour, you might want it to pause on anything destructive. When you come back, the approval decisions (or pending prompts) are part of the session record.

Split view for code and conversation

Split view lets you see the conversation alongside the terminal output. When you’re reviewing what Claude did, you can read its reasoning in one pane while looking at the actual changes in another.

A practical review pattern

My review workflow when I come back to a session:

  1. Check notifications. If Crystl flagged something, I start there.
  2. Open the shard and scroll to where I left off. The conversation history makes it easy to find the boundary between “things I saw” and “things that happened while I was away.”
  3. Read Claude’s reasoning. Not just the final output — the intermediate steps. Did it consider alternatives? Did it hit any issues?
  4. Check the diff. I use git diff or the built-in view to see exactly what changed in the codebase.
  5. Commit or course-correct. If the work looks good, I commit. If not, I continue the conversation with Claude, pointing at specific decisions I want to revisit.

Running multiple agents while you’re away

This review workflow becomes even more important when you’re running parallel sessions. If you have two or three shards working on different tasks in the same gem, you need to review each one when you come back. Crystl’s Crystal Rail makes it easy to jump between sessions and review them one by one.

For tasks where the agents might touch overlapping files, isolated shards give each agent its own git worktree. When you return, you review each shard’s work independently and merge the branches when you’re satisfied.

The goal is simple: you should be able to step away from Claude Code with confidence, and come back to clarity instead of chaos.

Get started at crystl.dev/login.