Agent Debugging on AIBussin — AI applications, systems and books

The Action Boundary

Sat, 08 Aug 2026 15:46:00 +0100

The previous chapter ended with a division of responsibility:

The model proposes. The runtime decides what may execute. The environment supplies observations about what happened.

This chapter takes the first clause seriously. What does it actually mean for a model to propose an action?

Suppose the model emits the sentence “Search the documentation for the latest PyTorch optimizer API.” A human reads that and understands the intention immediately. A runtime cannot act on it at all, because it needs answers to six questions the sentence does not contain: which action, which arguments, whether those arguments are well formed, whether their values are meaningful, whether this action is permitted in this run, and whether its execution preconditions currently hold.

Candidate Generation and Selection

Sat, 08 Aug 2026 15:54:00 +0100

The previous chapter built a boundary that stops arbitrary model output from acquiring execution authority without explicit checks. It made one class of failure inspectable and enforceable, and it is silent about another.

Suppose the model is asked to solve a coding problem. One run produces the right patch. The next produces a plausible but incomplete one. A third produces something better again. Nothing is malformed, nothing violates the action schema, and every one of them would pass the boundary we just built. Validity and quality are different properties. A proposal can be completely valid and still be a poor choice, which relocates the uncertainty rather than removing it:

Critique, Revision, and Acceptance

Sat, 08 Aug 2026 16:23:00 +0100

Selection can only choose among the candidates it is given. A strong evaluator may recognize that every available candidate is poor, but it cannot select a correct answer that the generator never produced.

That limitation becomes practical because the candidates usually come from one model answering one prompt, and such samples correlate. When four candidates share the same misreading of the evidence, ranking them can still produce a confident winner while leaving the shared defect untouched.

Planning and Execution

Sat, 08 Aug 2026 16:35:00 +0100

The critique loop works on one thing at a time. It assumes the task already exists as a candidate we can hold, inspect and improve.

Some tasks have no draft to hold.

Inspect a project, reproduce the failing test, find the cause, patch the code, rerun the relevant tests, and report what changed.

No single narrow action responsibly completes that goal, and the actions constrain each other. Patching before diagnosis is guesswork wearing the costume of work, and reporting success before observing a passing test is a claim about the world that nothing in the run supports. Worse, if execution reveals that an assumption was wrong, the rest of the route may be wrong too. A runtime choosing each action independently can react to the new observation, but without an explicit representation of the intended route it has nothing concrete to compare the changed world against.

Runtime State, Progress, and Termination

Sat, 08 Aug 2026 16:56:00 +0100

A plan is a claim about the future. It says that reproducing the failure, then diagnosing it, then patching, then testing, is a route from here to a working system. Making that claim explicit was worth the machinery. But it is written before any of the work happens, and execution may invalidate one of its assumptions almost immediately.

Execution produces something else entirely: a trajectory. Actions went out, observations came back, and some of what came back may contradict the intended route. The patch step failed because a dependency is missing. The test step is not merely late; it is unreachable.

Capabilities and Routing

Sat, 08 Aug 2026 17:09:00 +0100

Every mechanism built so far has taken the action set as given. The action boundary validates a proposal against a fixed list of permitted action types. Candidate generation samples several proposals from the same list. The runtime-state chapter watches what happens after execution and decides whether to continue. All of them assume that somebody, somewhere, already decided which capabilities the policy could choose from.

So far we have treated that decision as an input. This chapter makes it explicit, because the capability surface changes the decision problem the policy has to solve and therefore belongs inside the agent architecture itself.

Trajectory Search

Sat, 08 Aug 2026 17:26:00 +0100

An agent can make every local decision look reasonable and still lose the task.

A coding agent sees that test_checkout_redirect is failing, concludes there is an implementation bug in checkout.py, and then behaves impeccably for twenty steps: it reads the file, edits it, runs the tests, repairs the new failures its edit introduced, rewrites the patch, and runs the tests again. Every one of those steps is defensible given the step before it.

Agents From First Principles 08: AI Agent Picks the First Solution? Add Search Instead of One-Shot Generation

Sat, 08 Aug 2026 17:26:00 +0100

An AI agent often fails for a surprisingly ordinary reason:

it commits too early.

It finds one plausible next action, follows it, and then spends the rest of the run trying to make that first choice work.

That can look intelligent because the agent keeps reasoning, calling tools, revising plans, and explaining itself.

But underneath, the trajectory may be almost completely determined by an early mistake.

A coding agent chooses the wrong implementation strategy and spends twenty tool calls repairing it.

Agents From First Principles 05: AI Agent Gets Stuck in a Loop? Add State, Feedback and Stopping Conditions

Sat, 08 Aug 2026 16:56:00 +0100

An AI agent that keeps calling the same tool, revisiting the same page, rewriting the same file, or repeatedly saying “I’ll try again” is not displaying persistence.

It is displaying a control-flow bug.

This is one of the most common failure modes in agent software because the basic loop is deceptively simple:

observe
 ↓
decide
 ↓
act
 ↓
observe
 ↓
repeat

The problem is hidden inside the final word.

Agents From First Principles 04: AI Agent Fails on Multi-Step Tasks? Separate Planning From Execution

Sat, 08 Aug 2026 16:35:00 +0100

A surprising number of agent failures are not really model failures.

The model may be perfectly capable of writing each individual step. The failure happens because the system tries to decide what to do and do it at the same time.

That works for simple tasks:

question
 ↓
model
 ↓
answer

It becomes fragile when success depends on several ordered actions:

goal
 ↓
step 1
 ↓
step 2
 ↓
step 3
 ↓
verification

A useful next step in agent design is therefore to separate two jobs:

Agents From First Principles 03: AI Agent Keeps Making the Same Mistake? Add a Critique-and-Revision Loop

Sat, 08 Aug 2026 16:23:00 +0100

An AI agent can fail in a particularly frustrating way: it produces an answer that is almost right, you ask it to improve the answer, and it produces another answer with the same underlying defect.

Sometimes the wording changes. Sometimes it adds more explanation. Sometimes it becomes longer and more confident. But the important mistake survives.

That usually means the system is doing this:

prompt
 ↓
model
 ↓
answer

or this:

Agents From First Principles 02: AI Agent Gives Inconsistent Answers? Generate Multiple Candidates and Rank Them

Sat, 08 Aug 2026 15:54:00 +0100

One of the first things you notice when you build anything around a large language model is that the same prompt does not always produce the same quality of answer.

Sometimes the first response is excellent.

Sometimes it is merely acceptable.

Sometimes it misses the point entirely.

That creates a very common agent-engineering question:

If the model is inconsistent, should the agent trust the first answer it gets?

Often, no.

AI Agent Returning Invalid Tool Calls? How to Validate LLM Actions

Sat, 08 Aug 2026 15:46:00 +0100

If your agent sometimes invents a tool name, omits a required argument, returns malformed JSON, or produces an action that looks plausible but cannot actually be executed, the problem is usually not “the agent is dumb.”

The problem is that raw language-model output has been allowed to cross directly into execution.

That boundary is too weak.

The simplest useful agent architecture is not:

prompt
 ↓
model
 ↓
execute whatever came back

It is: