Maxxwell by Rindler
Writing

Measuring agent throughput: herded vs unmanaged

2026-09-29

Past a couple of coding agents, your bottleneck stops being tokens and starts being you. You’re answering questions, tracking stalls, and cleaning up rework.

Past a couple of coding agents, your bottleneck stops being tokens and starts being you. You’re answering questions, tracking stalls, and cleaning up rework.

This piece is about turning that into numbers: comparing unmanaged agents (tabs and terminals) against herded agents (through Maxxwell) using concrete metrics.

What “herded vs unmanaged” actually means

"Unmanaged" here is the setup most of us have today:

"Herded" means putting the same agents under Maxxwell:

Same agents, same repo, different control layer. The question is: does herding them change throughput and pain in a way that shows up in metrics?

The three metrics that matter: cycle time, interventions, rework

You don’t need a full DORA implementation to measure agent throughput. Three numbers give you a solid read:

  1. Cycle time - how long a unit of work takes from “brief written” to “merged”.
  2. Intervention count - how many times you had to step in to keep agents moving.
  3. Rework rate - how much of what agents shipped had to be reworked before it was really done.

Each can be logged with trivial tooling and compared across herded vs unmanaged runs on the same project.

Metric 1: Cycle time for agent-driven tasks

Cycle time is the top-line metric: how fast work flows from idea to merged change.

For agents, define it as:

You want this per-task, not per-repo.

How to measure cycle time unmanaged

In a pure-tab setup, the easiest path is git plus an issue tracker:

Example workflow:

# Create task
# In issue tracker: ISSUE-123 "Add bulk export API"

# Start work (log manually or with a script)
ISSUE_ID=ISSUE-123
START_TS=$(date -Iseconds)

# Later, on merge
END_TS=$(date -Iseconds)

echo "$ISSUE_ID,$START_TS,$END_TS" >> agent_cycle_time.csv

You're relying on discipline. The data is good enough if you log consistently for a week.

How to measure cycle time herded with Maxxwell

Maxxwell already has the notion of a briefed orchestrator seat and distinct worker sessions per task. You can align cycle time with that:

For example, you can use a simple wrapper script around git merge to log:

TASK_ID=TASK-42
START_TS=$(grep "$TASK_ID" my-task-notes.log | head -1 | cut -d ' ' -f1)
END_TS=$(date -Iseconds)

echo "$TASK_ID,$START_TS,$END_TS,herded" >> agent_cycle_time.csv

The point isn’t pixel-perfect timestamps; it’s comparable data. Same project, same task shape, two modes.

Metric 2: Intervention count - how often you bail agents out

AI coding tools save time - Atlassian’s 2025 DevEx report has 99% of surveyed devs reporting time savings and 68% saving more than 10 hours per week. But a lot of that time gets burned in supervision.

An intervention is "you had to stop what you were doing and fix or unblock an agent":

You count these per task.

How to track interventions unmanaged

In an unmanaged setup, interventions are invisible unless you log them explicitly. A lightweight way:

alias agent_intervene='echo "$(date -Iseconds),unmanaged" >> agent_interventions.log'

Whenever you:

…hit agent_intervene first. It’s crude but consistent.

How Maxxwell changes intervention visibility

Maxxwell surfaces states that unmanaged tabs hide:

From an orchestration seat you can ask, in natural language, "which workers are waiting on me?" and get a clear list.

Even with that help, you still log human interventions manually. One straightforward pattern:

alias agent_intervene_herded='echo "$(date -Iseconds),herded" >> agent_interventions.log'

Because Maxxwell surfaces which workers are waiting on you versus still working, you can correlate interventions with actual output.

Metric 3: Rework rate - how much agent output you redo

For coding agents, rework is where a lot of the pain lives.

Define rework rate per task as:

You can get fancy with diff metrics later. Start with commits; they’re discrete.

Measuring rework unmanaged

In the unmanaged world, agents often push straight to your working branch via Cursor or a local copilot. You can still track rework:

Example using git:

TASK_BRANCH=feature/bulk-export

INITIAL_COMMITS=$(git log --oneline main..$TASK_BRANCH | wc -l)
# After review/changes
FINAL_COMMITS=$(git log --oneline main..$TASK_BRANCH | wc -l)

REWORK_COMMITS=$((FINAL_COMMITS - INITIAL_COMMITS))
echo "$TASK_BRANCH,$INITIAL_COMMITS,$REWORK_COMMITS,unmanaged" >> agent_rework.csv

It’s not perfect - some "rework" is just polish - but over a week you’ll see patterns.

Measuring rework with Maxxwell in the loop

Most orchestration tools, including CommandSlate, Orca, Herd and co, push you toward worktree-per-agent and PR-based review. Maxxwell doesn’t impose a branching model, but it does:

That makes it easy to define "initial output" as "first PR or patch the orchestrator considers landed". Then you count how many follow-up commits were needed:

TASK_BRANCH=feature/bulk-export
INITIAL_COMMITS=$(git log --oneline main..$TASK_BRANCH | head -n 1 | wc -l) # often 1
FINAL_COMMITS=$(git log --oneline main..$TASK_BRANCH | wc -l)

REWORK_COMMITS=$((FINAL_COMMITS - INITIAL_COMMITS))
echo "$TASK_BRANCH,$INITIAL_COMMITS,$REWORK_COMMITS,herded" >> agent_rework.csv

You can refine "initial" vs "rework" by marking the first merge candidate explicitly in your orchestrator notes. The key is consistency across herded vs unmanaged runs.

Designing a fair herded vs unmanaged experiment

There isn’t a public apples-to-apples benchmark for "Maxxwell-managed vs unmanaged" agent sessions. So you run your own. DORA’s guidance is: baseline, hypothesis, measure.

A practical setup for a single repo:

  1. Pick a time window - e.g. two weeks
  2. Define task units - tickets with clear acceptance criteria
  3. Split the window - first week unmanaged, second week herded (or vice versa)
  4. Keep everything else fixed - same models, same review rules, same test expectations
  5. Log the three metrics - cycle time, interventions, rework per task

At the end, build a small summary table for yourself:

That’s enough to decide if herding is worth the overhead on your project.

This simple three-metric view - cycle time, interventions, and rework - gives a fast visual read on whether herding with Maxxwell improves agent throughput over unmanaged sessions.

Where Maxxwell fits among orchestration tools

Agent orchestration is now a category, not a weird tmux hobby. You have options:

For this specific measurement problem (herded vs unmanaged throughput on a single machine), Maxxwell’s properties matter:

If you want a deeper workflow-level comparison of Maxxwell vs other orchestration patterns, this is covered in more detail in this broader guide on herding coding agents without adding more noise.

Reading the results without fooling yourself

When you look at your three metrics, a few patterns are worth calling out:

The research backs this up. DORA’s 2025 report calls AI an "amplifier" of existing strengths and weaknesses: if you have solid version control and small batch sizes, more agents plus Maxxwell tend to help; if your process is already chaotic, herding mainly makes the chaos visible.

Use the numbers to decide where to tighten your loop:

Maxxwell gives you a control surface where those changes are easy to apply without rewriting your actual agent stack.

FAQ: measuring herded vs unmanaged agents

How many tasks do I need for a meaningful comparison?

You don’t need months of data. For a typical repo, 15-30 tasks per mode (herded vs unmanaged) is enough to see real differences in cycle time and rework trends. The important part is keeping task size and difficulty roughly comparable across the two windows.

Does Maxxwell itself improve model quality?

No. Maxxwell doesn’t replace Claude, Codex, Cursor or any other coding agent; it manages them. Any change in output quality comes from better orchestration: clearer briefs, visible stalls, and earlier interventions - not from different model weights.

What about context pressure and long-running sessions?

Maxxwell exposes a live context-pressure readout with tiered warnings and a one-click compact, so you can see when a worker’s window is getting cramped and trim it intentionally. It does not automatically recycle context or restart work. If a long-running experiment is at risk, you get the signal and choose the fix.

Can Maxxwell automatically correct drift or re-run stuck tasks?

No. By design, Maxxwell’s conducting is real but its autopilot is not. It doesn’t auto-detect drift, doesn’t re-aim a session, doesn’t restart stopped work, and doesn’t run goal checks on a schedule. Any fleet change is drafted and waits for you to press enter.

How does this work for teams instead of individuals?

The metrics are the same - cycle time, intervention count, rework - but you add a dimension: who intervened. On multi-dev teams, you can log user IDs alongside interventions and rework to see where supervision load is landing. Maxxwell is free for individuals and paid for teams, and it stays local with your own key either way, so you can run the same experiment across a group.