Dashboard

Why Your AI Agent Did Nothing: A Diagnostic Order

Your AI agent did nothing and reported success. Five causes, in the order worth checking, and the one-line test that separates each from the next.

Steve Jefferson
Steve Jefferson
Developer Advocate
5 October 20261 min read

An agent that fails loudly is easy. You read the error and fix it.

The hard case is the agent that runs for four minutes, produces a confident summary of what it accomplished, and changed nothing at all. No error, no warning, no diff. When an AI agent did nothing but says otherwise, you are debugging silence, and silence has at least five distinct causes that look identical from the outside.

Here they are in the order worth checking, cheapest first.

1. It refused, politely

Some agents decline a task and then summarise the task back to you in a way that reads like completion. "I have reviewed the authentication flow and identified the changes needed" is not a statement that changes were made, but it scans like one on a quick read.

**The test:** read the final message for a verb in the past tense that describes an action rather than an analysis. "Reviewed", "identified", "analysed" and "considered" are not "edited", "created" or "deleted".

**The fix:** ask what it did, not what it found. If the answer is a plan, you got a plan.

2. It had no tools to do the job

An agent without file write access cannot write files. This sounds too obvious to check, and it is the single most common cause in practice, because tool availability is configured somewhere other than where you are working: a permission mode, a sandbox setting, a config file, an allowlist that was tightened last week for a different reason.

What makes it confusing is that a model asked to edit a file it cannot edit will often describe the edit in detail rather than report the failure, because describing is the only action available to it.

**The test:** ask it to create a throwaway file with one word in it. If that fails, nothing else matters.

**The fix:** check the permission or sandbox configuration before touching the prompt.

3. The plan was a no-op

The agent understood the task, had the tools, formed a plan, and the plan was to do nothing, because it concluded the work was already done.

This happens most on tasks phrased as outcomes rather than changes. "Make sure the export handles empty rows" is satisfied by an agent deciding that the export already handles empty rows. It is not wrong to conclude that. It is wrong to conclude it without evidence, which is what usually happened.

**The test:** ask what evidence it used. If the answer is a reading of the code rather than a run of the code, the conclusion is a guess.

**The fix:** phrase the task as a verifiable condition. "Add a test that feeds an empty row to the export and make it pass" cannot be satisfied by an opinion.

4. It thought it was finished

Multi-step tasks fail in the middle more often than at the start. An agent completes step one, something about the result reads as terminal, and it stops and reports success on the whole task.

The giveaway is partial work: some files changed, some not, and the ones left alone are the later steps.

**The test:** compare what changed against your list of steps. A clean prefix of completed work followed by nothing is this failure.

**The fix:** number the steps explicitly and ask for a per-step report. An agent asked to confirm each step individually is much less likely to collapse the list.

5. It ran out of room

Long tasks exhaust the context window. What follows depends on the harness: some compact, some truncate, some quietly lose the original instruction. In each case the agent continues working from a degraded picture, and "degraded" sometimes means "no longer knows what it was asked to do".

**The test:** length and timing. If the session was long and the output thinned out toward the end, suspect this before anything else.

**The fix:** shorter tasks with clean handoffs. What to do when your agent runs out of context covers the recovery, and how long to let an agent run unattended covers the prevention.

When your AI agent did nothing: the order, condensed

Check

Takes

Rules out

Past-tense action verbs in the summary

10 seconds

Polite refusal

Write a throwaway file

30 seconds

Missing tools

Ask what evidence it used

1 minute

No-op plan

Diff against your step list

2 minutes

Premature completion

Session length and output tail

2 minutes

Context exhaustion

Work it top to bottom. People reliably start at the bottom, rewriting prompts to fix what turns out to be a permissions setting.

The structural fix

Stop trusting the summary. An agent's report of its own work is generated text, subject to exactly the same failure modes as the rest of its output, and it is generated by the component least able to verify itself.

Trust the diff, the test run, and the file timestamps. If you are checking manually every time, that is a signal to make the check automatic: a task that ends with a test run has an answer that does not depend on anyone's description of it.

For the adjacent failure where the agent does too much rather than too little, when AI keeps rewriting working code is the other half of this problem. The coding agent primer covers the vocabulary if any of this is new.

Sources: the OWASP Top 10 for LLM applications documents the broader category of unverified model output being trusted downstream.

How did this land?

About the author

Steve Jefferson
Steve Jefferson

Developer Advocate

Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.

Share

Get the next post in your inbox

One email a month. Product updates, engineering posts, and the best of Built with Swarmz.

I agree to receive emails about AI building tips and Swarmz product news. Unsubscribe any time.