Which layer broke your agent? Environment, loop, topology

The 30-minute debug limit says stop and escalate. It's a good rule and I use it constantly.

It has a gap, though, and I kept falling through it. It tells you when to stop. It doesn't tell you what to stop and look at — so the default is to reach for whatever you touched most recently, which is almost always the instructions.

I've rewritten a prompt for 20 minutes when the actual problem was an expired token. I've redesigned a whole workflow when the actual problem was that nothing in it ever said what "finished" meant. Both times the fix was cheap and 40 minutes away, because I was working at the wrong altitude.

So there's a question that belongs in the limit, before the escalation: which layer owns this failure?

Stop and escalate — but escalate what?

Three failures look nearly identical from where you sit. The agent isn't producing what you wanted, and it's been a while.

They have completely different fixes, and the symptom that separates them is available in about 30 seconds if you know what to look for:

Name the layer, then escalate into that layer. Most stalled sessions I've watched — mine and other people's — get debugged one layer away from where the problem lives.

Cannot operate: the environment

Start here, always, because it's the cheapest to rule out and the most embarrassing to miss.

The tell is output that's confidently wrong in a way that suggests the agent never actually saw the thing it's describing. It reports a file's contents that don't match the file. It says a command succeeded when nothing ran. It reasons beautifully about a database it couldn't connect to.

That isn't a thinking failure. The agent couldn't reach something and produced its best guess instead, because producing a plausible answer is always available to it.

What to check:

• Tool access. Can it actually run the command, read that path, hit that endpoint? Not "is it configured" — has it done it, and did you see the output?
• Stale state. Expired credentials, a cached value, a branch it checked out yesterday, a server that isn't running.
• Permissions. Read where it needs write. Sandboxed away from the thing it's been told to change.
• Visibility. Can you see what it did? If a run produces no log you can inspect, you're debugging by seance.

Environment mismatches are a solved problem in ordinary software — the dev/prod parity discipline exists because differences between where you built and where it runs cause exactly this class of confident failure. Agents inherit all of it and add a new twist: they'll narrate right past the gap rather than crashing at it.

Stuart Leo

An agent that can't reach something doesn't stop. It writes a sentence about what would probably be there.

Almost works but unreliable: the loop

Second layer. The agent can operate — it's reaching everything, the tools fire, you can see the output. It's just not reliably finishing.

The tells: it gets 80% there and stops. It succeeds on Tuesday and fails on Wednesday with the same input. It reports completion and the work isn't done. It retries forever, or gives up after one attempt, with no apparent logic to either.

That's the loop — the repeated cycle of act, check, adjust — and the part that's usually missing is the stop rule. If nothing in the loop defines what finished looks like in terms the agent can check, then "finished" collapses into "produced a plausible final message", which it can always do.

The fix is an anchor: a signal it can't produce by asserting it. A test that ran. A query that returned rows. A deploy that resolved. "The agent says it's done" is a report about the work, not the work. Don't loop on confidence — loop on evidence.

This is also the layer where instruction quality genuinely matters, and it's the only one of the three where rewriting the prompt is the right first move. Which is why the default reflex isn't stupid — it's just applied to all three.

The process itself is complex: the topology

Third layer, and the rarest. The environment is fine. The loop has a stop rule and honours it. It still doesn't work, and the failure looks like dropping things.

The tells: the job has several genuinely different specialisms in it and each pass does some well and some badly. There's an approval or a branch in the middle that one pass can't represent. Coverage is inconsistent in a way that isn't random — the same kinds of things get missed.

That's a shape problem. The job was too big for one node, and no amount of instruction-rewriting fixes a job that needed splitting. The move is to break it into bounded jobs with contracts, decide which of them are actually independent, and put something at the end that merges the results.

A caution though, because this layer is where the current enthusiasm points: it's the least likely answer. Most stalls are environment or loop. Reaching for a redesign first produces an elaborate structure around a problem that was one expired token, and now you have two problems.

Running the triage in practice

At 30 minutes, before touching anything:

1. Can it operate? Look at one piece of raw output — a real command result, a real file read. Not the agent's summary of it. If you can't find one, that's your answer.
2. Does it know what done means? Look for the anchor. If nothing in the job can be checked without asking the agent, fix that before anything else.
3. Is one pass the wrong shape? Only if the first two are clean. And if you can't name two parts of the job that don't depend on each other, it isn't a topology problem either.

Then escalate into that layer — fresh context, a reframe, a stronger model, or your own eyes, as the debug limit already prescribes. The triage doesn't replace the escalation. It aims it.

One thing this is not: these three layers describe what broke. They're a diagnostic. They are not the same as C²'s stack of what you build — prompt inside context inside harness, where each layer contains the one before it and C² sits at the harness level. Different question, different three. Keep them apart, because collapsing them produces a conversation where nobody can tell whether "harness" means the machine you built or the thing that just broke.

Aim before you escalate

The limit was always right that more attempts don't help. What it was missing is that the right next move depends on which layer failed, and the three look alike from outside.

Check whether it could operate. Check whether it knew what done meant. Only then ask whether the job was the wrong shape. Cheapest first, rarest last.

Name the layer that owns the failure before you touch anything — most stalls get debugged at the wrong one.

Start here: see the 30-minute debug limit, how to run agents overnight safely, or read the method.