Building Workflow Autonomy III: Why Your AI Agent Gets Stuck — And How to Read Its “Diary” to Fix It

Generated us Nano Banana, Prompted by Author

In the last instalment, we cracked open the Agent Harness — the operational scaffolding that turns a clever-but-clueless language model into something resembling a serious business tool. We talked about conveyor belts, locked cabinets, and the compliance officer sitting quietly in the corner. If you came away from that piece understanding that the model is the engine but the harness is the car, then you’re exactly where you need to be.

But knowing the parts of a car is not the same as knowing how it runs. So today, we lift the bonnet and look at how the bits work together. Here’s the uncomfortable truth that nobody selling you an “autonomous AI solution” wants to dwell on: your agent will get stuck. Not occasionally. Routinely. And when it does, the difference between a five-minute fix and a £400 weekend disaster comes down to one humble, unglamorous skill — the ability to read its diary.

The Mystery of the Frozen Agent

Let me paint a scene you may recognise… or may soon.

You’ve deployed your first agent. It’s reconciling some invoices, or triaging some emails, or pulling figures from a handful of reports. You’re watching the dashboard with the cautious pride of someone who has just let a teenager borrow the car for the first time. The little status light says Running. The token counter is ticking upward. Costs are accruing.

And nothing is happening.

No output. No completion. No error message you can actually understand. Just that maddening Running… Running… Running… while the cost meter climbs like a taxi stuck in traffic. After ten minutes of this, most people do the only thing that feels rational: they panic and kill the process. Pull the plug. Walk away muttering something about how the technology “isn’t ready yet.”

But the agent wasn’t frozen. It was thinking — or rather, it was doing the mathematical equivalent of thinking, over and over, trapped in a loop it couldn’t escape. And the maddening part is this: if you’d known where to look, you could have read exactly what it was struggling with, in plain English, and fixed it in minutes.

That black box you’re afraid of? It keeps a diary. Let me teach you how to read it.

The ReAct Loop: What Actually Happens Inside

Almost every modern AI agent runs on a deceptively simple cycle. It was formalised in a now-widely-cited 2022 research paper by Yao and colleagues at Princeton and Google, who called it ReAct — a contraction of Reason and Act (Yao et al., 2022).

The idea is that an agent doesn’t solve a multi-step problem in one heroic leap. It nibbles at it, one bite at a time, repeating the same three-stage cycle until the job is done — or until something stops it. You don’t need a maths degree to follow it. You just need to know the three steps.

Step 1 — Context Evaluation (the “Thought”). The agent looks at its goal and everything that has happened so far, then decides what it needs to do next. Not the whole plan — just the next move. Think of it as a contractor glancing at the job sheet and muttering, “Right, first I need to find the pricing file.”

Step 2 — Tool Execution (the “Action”). Having decided, the agent reaches for one of the tools in its registry — a search function, a database query, an email drafter — and generates the specific command to use it. “Search the shared drive for ‘Q3 Pricing.’”

Step 3 — Log Integration (the “Observation”). The harness runs that command and feeds the result back to the agent — and crucially, it does this whether the result is success or failure. “Found the file.” Or: “Error 404, file not found.” That result gets written into the running history, and then the whole cycle begins again.

Thought, Action, Observation. Thought, Action, Observation. Round and round, each loop building on the last, until the goal is reached or a boundary halts it. That’s it. That’s the engine. The terrifying autonomy you’ve read about in breathless headlines is, at the mechanical level, just this little three-step waltz repeated a few dozen times.

A Necessary Word: “Thought” Is Maths, Not Mind

Now, I want to pause here because the vocabulary is about to trip you up if I let it.

We call that first step a “Thought.” The agent itself often labels it that way in its logs — literally writing out Thought: I should check the customer record first. And the moment you read a machine narrating its own reasoning in the first person, something primal in the human brain whispers: it’s alive, it understands, it’s one of us.

It isn’t. And believing otherwise is not a charming quirk; it is the single most common root cause of governance failure I see.

What’s actually happening in that “Thought” step is statistical prediction. The model is calculating, based on its instructions and the current state of the task, the highest-probability sequence of words that should come next. There is no awareness behind it. No intent. No little homunculus weighing the options and deciding. It is doing very sophisticated maths that produces text which looks like deliberation — and the fact that it looks like deliberation is precisely why it’s so useful and so dangerous in equal measure.

Why does this matter to you, sitting in a decision-making chair rather than a coding one? Because anthropomorphism breeds over-trust. The moment you start thinking of your agent as a colleague who “knows what it’s doing,” you stop supervising it like the probabilistic tool it is. You give it the benefit of the doubt. And an autonomous system that has been granted the benefit of the doubt is an unsupervised liability waiting to happen. Respect the agent’s capability. Do not credit it with a mind.

The Anatomy of a Run Log

Here’s where theory becomes a skill you can actually use. Every cycle of that ReAct loop gets written down. This record — the run log, or execution transcript — is the agent’s diary. And once you know the three labels to look for, you can read it as easily as a recipe.

Let me show you two of them, side by side. First, a healthy run:

A successful run

Thought: I need to locate the Q3 pricing file to validate the invoice total.

Action: Search_Directory(“Q3 Pricing”)

Observation: File found: /finance/Q3_pricing.csv

Thought: I have the file. Now I’ll extract the unit price for SKU 4471.

Action: Read_File(“/finance/Q3_pricing.csv”)

Observation: SKU 4471 = £12.50 per unit

Thought: Invoice total matches. Task complete.

Action: Finish(“Invoice validated successfully.”)

Notice the rhythm. Each Thought leads to a different Action. Each Observation feeds something new into the next Thought. The agent is progressing — every loop moves the work forward. This is what a job well done looks like in transcript form.

Now look at the one that got you that frozen dashboard:

A failed run

Thought: I need to locate the Q3 pricing file to validate the invoice total.

Action: Search_Directory(“Q3 Pricing”)

Observation: Error 404: file not found.

Thought: I need to locate the Q3 pricing file to validate the invoice total.

Action: Search_Directory(“Q3 Pricing”)

Observation: Error 404: file not found.

Thought: I need to locate the Q3 pricing file to validate the invoice total.

Action: Search_Directory(“Q3 Pricing”)

Observation: Error 404: file not found.

There it is. There’s your “frozen” agent. It wasn’t frozen at all; it was trying, frantically, the same doomed move on repeat, burning a few pennies of tokens with every lap. The file that was promised doesn’t exist where it was told to look, and the agent has no way of working that out. So it does the only thing its maths permits: it tries again. And again. And again, until your iteration limit or your patience runs out.

Two Failures, Two Very Different Conversations

This is the diagnostic literacy that turns you from a passive recipient of post-mortems into someone who can actually contribute to an incident review. Because once you can read the log, you can spot which of two fundamentally different problems you’re looking at.

A Tool Failure is when something the agent relies on simply breaks. You’ll see it in the Observation line as a hard error: a 404 (something wasn’t found), a timeout (something took too long to respond), a permission denied (the agent reached for a door it isn’t allowed through). HTTP status codes like these are a long-established web standard, and you don’t need to memorise them — you just need to recognise that a numbered error is the infrastructure failing, not the agent’s reasoning (Mozilla, n.d). A one-off tool failure is a plumbing problem. It’s a conversation with IT: fix the connection, restore the permission, correct the file path.

A Logic Failure is subtler and, frankly, more interesting. This is when the tools all work fine, but the agent’s reasoning has gone in circles. The tell-tale sign is repetition: the same Action firing over and over, or the agent “hallucinating” a piece of data to paper over a gap it can’t otherwise fill. In our failed transcript above, the tool worked perfectly — it correctly reported that the file wasn’t there. The logic failed because the agent couldn’t interpret that absence and adapt. A logic failure is not a plumbing problem. It’s a design problem — a sign that your instructions, your data, or your error-handling rules need rethinking.

Here is the rule worth tattooing on the inside of your eyelids: if an error leads straight back to the same action, you’re watching a logic failure. If an error appears once and the agent moves on, you’ve caught a tool failure.

One you escalate to your technical team to fix the pipes. The other you fix by redesigning how the agent thinks about the job. Knowing which is which means you stop wasting your IT team’s time and your own.

Where This Takes Us Next

You can now read the diary. You can watch the engine turn, spot when it seizes, and tell a broken pipe from a circular thought. That’s no small thing; it’s the difference between a leader who governs their AI and one who merely hopes for the best.

But there’s a deeper question lurking underneath those failed runs, and we’ll tackle it next time. When the agent searched for that pricing file, where did it think it was looking? What does an agent actually “know,” and what is it only pretending to know? In the next instalment, we’ll dismantle one of the most dangerous myths in this whole field — the idea that your AI “remembers” anything at all — and I’ll show you why confusing the agent’s desk with its archive is how organisations leak data and breach compliance without ever realising it.

Your Action This Week

Here’s a small, concrete task that will teach you more than any whitepaper.

Ask your IT team or your vendor for a redacted execution transcript from a recent agent run, successful or failed; it doesn’t matter. Open it up, or better yet, print it out and grab three highlighters.

• Yellow every Thought (the agent’s stated reasoning).
• Blue every Action (the tool it chose).
• Red every Observation result, especially the errors.

Then look at the pattern. Does a Red lead straight back to the exact same Blue? You’ve found a logic failure. Is there a single Red with an error code, after which the colours keep changing? That’s a tool failure.

Whichever you find, take it to your technical lead and ask one simple question: “Which of these two failure modes is more common in our environment?” Their answer will tell you whether your real problem is your plumbing or your design — and that single insight is worth more than a dozen vendor demos.

If this helped you see inside the black box, share it with the colleague who’s currently afraid to deploy anything. Reading the diary is a skill anyone can learn — and the more people in your organisation who can, the safer your automation becomes.

Further Reading

Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K. and Cao, Y., 2022. React: Synergizing reasoning and acting in language models. arXiv preprint arXiv:2210.03629. Available at: https://arxiv.org/abs/2210.03629