Reading the Output: Thinking, Tools, and Results

Tier 0 · Total Beginner 8 min read

A Claude Code session is not just a chat — it’s a running log of an agent working. The scrolling text isn’t filler; it’s the agent narrating its plan, the tools it’s calling, and what came back. Once you can read it, you can supervise the agent instead of just hoping it lands. This page teaches you to read that stream.

The four things you’ll see

Strip away the formatting and a session is made of four kinds of output, usually in this order, looping until the task is done.

1. The agent’s reasoning / plan

Before acting, the agent often states what it’s going to do — “I’ll look for the config file, then update the timeout value.” This is your earliest chance to catch a misunderstanding. If its plan doesn’t match what you wanted, interrupt now, before it spends effort going the wrong way.

2. A tool call

This is the agent reaching for one of its hands. You’ll see it about to read a file, search the code, write or edit a file, or run a terminal command. For the actions that change things, this is where the permission prompt appears. The tool call tells you what the agent is trying to do and to what — which file, which command.

3. The result of that tool call

After a tool runs, its output comes back: the contents of the file it read, the lines its search matched, the success message from an edit, or the output (and errors) from a command. The result is the most information-dense part of the stream — it’s the ground truth the agent now reacts to. If a command failed, the error shows up here.

4. The next step — or the final answer

The agent reads the result and decides what to do next: call another tool, or, if the task is done, give you a final summary of what it accomplished. Then it stops and waits for you.

A worked example

Say you asked: “The site won’t build — figure out why and fix it.” A healthy session reads like a detective working a case:

Plan: “I’ll run the build to see the error first.”
Tool call: runs the build command.
Result: an error — a missing import on line 12 of a particular file.
Plan: “The error points at a typo’d import. I’ll open that file.”
Tool call: reads the file.
Result: confirms the typo.
Tool call: proposes an edit fixing the import (permission prompt — you approve).
Tool call: re-runs the build to confirm.
Result: build succeeds.
Final summary: “Fixed a typo in the import on line 12; the build now passes.”

Notice the pattern: act, look at the result, decide, repeat. Each step is driven by what the last result actually said, not by guessing. That’s the loop working well.

How to tell when the agent is stuck

Most of the time it just works. But you should be able to spot trouble so you can step in rather than let it spin. Watch for:

Looping. The same tool call and the same failed result, two or three times in a row, with no new idea between tries. The agent is trying the same thing and expecting a different outcome.
Drifting off-task. It starts editing files or chasing a problem you didn’t ask about. Often this traces back to a vague request — it filled the ambiguity with its own goal.
“I can’t find / I don’t have access.” It’s hitting a wall — a missing file, a tool it doesn’t have, a permission it needs. This is usually a context gap, not a dead end.
Confident but wrong. It announces success, but when you check the result, the thing isn’t actually fixed. This is why you verify (the next section).

What to do when it’s stuck

Stuck is recoverable. You have good moves:

Add the missing context. Point it at the right file, paste the real error, tell it the thing it couldn’t find. Most “stuck” is “didn’t know,” and a sentence of context unblocks it.
Narrow the task. If it’s drifting, re-state the goal tightly: “Just fix the failing test in auth.js — don’t touch anything else.”
Interrupt and redirect. You don’t have to wait for it to finish a bad path. Stop it and steer.
Verify its claims. When it says “done,” check — read the file back, re-run the test yourself. Trust, then verify.

The supervisor’s mindset

Reading the output well turns you from a passenger into a supervisor. You’re not writing the code or running the commands — the agent is. Your job is to read the plan, sanity-check the tool calls, glance at the results, and verify the outcome. Do that and you’ll catch the rare wrong turn early, when it’s cheap to fix.

Next: You’ve finished the absolute basics. Where to Go Next maps the rest of this site as a sequenced path — from here to building and running your own agents.