Maxxwell by Rindler
Writing

How to tell which coding agent is stuck

2026-09-09

Past two or three coding agents, you stop being limited by model quality and start being limited by your own attention. You have more terminals than you can.

Past two or three coding agents, you stop being limited by model quality and start being limited by your own attention. You have more terminals than you can read, and the real problem is: which agent is stuck, which is waiting on you, and which is quietly building the wrong thing?

This piece sits alongside the broader pillar "AI coding agent orchestration: the complete guide for multi-agent development" and focuses on one narrow slice: stall detection and supervision.

The three ways a coding agent gets stuck

Most stalls fall into a few repeatable patterns:

Heartbeat, a small watchdog plugin for CLI agents, already uses these signals: it looks for repeated edits, repeated failing commands, and idle gaps. That's a good mental model: when you watch multi-agent systems, behavior beats semantics.

If you're trying to tell "which agent is stuck?", you're really asking:

Fixed one-shot prompting: simple, fast, brittle

Static prompting, a single big instruction, maybe with a checklist, still has a place. GitHub and McKinsey both report big gains (up to 35-45% faster code-gen; 20-30% faster refactors) when the task is well-bounded.

Static prompting works best when:

Examples where one-shot is fine:

In these cases, "stuck" is usually obvious:

You don't need orchestration here; you just need to read the output and rerun.

Static prompting breaks down when:

That's when you need something more like "dynamic goal-driven loops".

Dynamic goal-driven loops: add supervision, not magic

Dynamic orchestration is about keeping the loop healthy:

  1. Plan.
  2. Edit.
  3. Run tools (tests, commands, web requests).
  4. Observe.
  5. Repair.
  6. Update status.

OpenAI's long-run Codex experiment ran this loop for about 25 hours, 13M tokens and ~30k LOC. Anthropic's C compiler work did something similar at larger scale: 16 agents, ~2,000 Claude Code sessions, ~$20,000 in API cost, ~100k lines of C able to compile Linux 6.9.

You don't need that scale to hit the same problems. You see smaller versions any time you have:

The key shift is:

Signals that matter in dynamic loops:

When those disappear, the agent is effectively stuck, even if it's still emitting tokens.

What an agent health dashboard needs to show

Once you have more than one agent at a time, a health dashboard stops being nice-to-have and starts being infrastructure. OpenAI, Anthropic, GitHub and newer desktop tools all converge on the same product pattern: command centers, worktrees, approvals, and explicit state.

At minimum, you want per-session:

CommandSlate, Herd, and similar desktop tools surface subsets of this. GitHub's agentic workflows push it into YAML: triggers, permissions, safe outputs, firewalled containers, read-only tokens. OpenAI's sandbox docs call out run state and audit logs explicitly.

Maxxwell takes the same idea and applies it specifically to coding agents you already use. It puts every session in one window and marks them as:

...with a "possibly stalled" overlay when context pressure and activity patterns suggest trouble.

The opinionated part: when Maxxwell cannot confirm a state, it says "not heard from" instead of guessing "working". A dashboard that is confidently wrong is worse than one that admits a gap.

DIY monitoring vs purpose-built orchestration tools

If you're reading this, there is a good chance you already have a tmux layout and some shell glue. It's worth being explicit about the comparison, because DIY is often the default.

Typical DIY stack:

What DIY gives you:

What you still lack:

Tools in the orchestration space:

For pure server-side automation, GitHub and OpenAI's frameworks are strong. For local development where your agents already live in Cursor, Claude, Codex, or your own CLI harnesses, the desktop style (including Maxxwell) fits better.

How Maxxwell approaches stuck detection and orchestration

Maxxwell is not another copilot. It is an agent-of-agents that manages Claude, Codex, Cursor-agent and whatever you already run, without wrapping or replacing them.

Mechanically:

On top of that you get:

You talk to the orchestrator instead of twelve terminals. It in turn talks to your workers, then reports:

One deliberate property: Maxxwell's fleet controls draft rather than act. Any control that would change the fleet writes a fully formed, unsent sentence into the composer and stops. You are always the one who presses enter.

That matters for stall handling:

You keep control, but you don't have to manually watch every log.

When dynamic orchestration actually helps

Dynamic orchestration adds overhead. You want it only when the coordination cost is already visible.

Based on Anthropic's and OpenAI's long-run experiments, plus mainstream adoption data (Stack Overflow reports 51% of pros using AI tools daily, with sentiment cooling as complexity rises), orchestration pays for itself when:

Concrete cases:

In these situations, static prompting still generates code fast. But without orchestration you:

Dynamic loops, plus a dashboard, solve the visibility problem. Tools like Maxxwell solve the "human bottleneck" problem by putting the review seat in one place.

Where static approaches remain the right choice

You don't need orchestration for:

If you rarely have more than one agent alive at a time, adding a command center will just be another app. Spending an extra 30 seconds reading the output is cheaper than wiring up dashboards and orchestrators.

As METR's time-horizon report shows, the duration of tasks frontier agents can complete with a given success rate is doubling roughly every seven months. You will feel the need for orchestration the moment your tasks cross that line from "finish in one sitting" to "spans several days and windows".

Quick comparison: tools for telling which agent is stuck

Here's a simple summary based on typical use:

For the most common case this article is about, a developer with 4-12 coding agents alive across a day, already using Claude Code, Codex, Cursor or similar, a local orchestrator like Maxxwell is the practical recommendation. You keep your agent stack, gain a supervisor, and stop being the single thread trying to remember which pane is stuck.

FAQ: detecting stuck agents in multi-agent systems

How do I tell if an AI coding agent is stuck?

Look for behavior, not just text. Signals include repeated edits to the same file section, repeated failing tool commands (tests, builds, API calls), and long idle gaps with no new tool activity. A healthy agent should be cycling through plan, edit, run, observe; if that loop stops, the agent is stuck.

What's the difference between fixed one-shot prompts and dynamic goal-driven loops?

Fixed prompts define the whole task up front and expect a single completion. Dynamic goal-driven loops keep a running goal, adjust plans as work lands, and focus on maintaining a healthy plan-edit-run-observe cycle over time. One-shot is simpler and works well for bounded tasks; dynamic loops matter when tasks are open-ended or long-running.

When should I adopt orchestration instead of just better prompts?

Once you're running more than a couple of agents in parallel and tasks span hours or days, orchestration beats prompt tuning. You need visibility into which sessions are working, blocked, or waiting on you, and you need someone, or something, to maintain the global view and route work.

Do I need auto-recovery or can I just supervise manually?

Auto-recovery is useful for pure backend agents, but for coding agents touching real repos, human-in-the-loop supervision is safer. Tools like Maxxwell focus on visibility and drafting controls, leaving the actual "press enter" decision to you. That avoids silent build-breaking automation while still cutting the cost of supervision.

How does Maxxwell help me see which session needs my attention?

Maxxwell maintains a live status window for every agent session: working, idle, waiting on you, not started, needs sign-in, blocked, done, dead or not heard from, plus stall hints. An orchestrator agent sits on top, reports what landed vs what needs your call, and drafts fleet changes as unsent messages so you stay the one in control.