Agent Levers: A Plan-Do-Check-Act Loop That Makes Coding Agents Finish What They Start

A coding agent is only as useful as the spec you give it. That sentence sounds like a truism until you watch it play out for an afternoon.

Type too little — “add password sign-in” — and the agent improvises. It picks a JWT library you don’t use, skips rate-limiting, ships a flow that works on the happy path and fails the moment you blow on it. Type too much — every constraint, every test name, every file path — and you’ve done the agent’s homework. You are the bottleneck, not the multiplier.

I have been trying to find the shape of the work between those two extremes for months. I built agent-levers — a small set of Agent Skills that give the agent a structured plan → do → check → act loop on disk — to do the structuring work I kept doing by hand.

This is the third post in a thread about the shared .agents/ ground, after supagents (one subagent source, many targets) and agent-docs (a curated, local doc reference). Same bet, different layer: this one is about the workflow an agent runs inside a non-trivial task.

Agent Lever: Multiply the agent’s force, divide the human’s effort — https://github.com/fmind/agent-levers

The two failure modes of unguided agents

After enough sessions, I started noticing the same two failure patterns, no matter which coding agent I drove.

The agent claims success it didn’t verify. It says “I implemented the rate limiter,” shows a diff, and moves on. You ask “did the test pass?” and discover it never ran, or it ran in an ad-hoc shell, or — the meanest version — it passed in the agent’s session and fails the moment you re-run it from a clean terminal. The status report isn’t lying. It’s just not grounded in a verifier.

The agent runs away. The first test fails. The second attempt fails. The third attempt fails. Forty minutes later, the diff is twice as large as the original task, and nothing is green. There is no internal “I should stop and ask” trigger because the agent is doing what it was told: keep trying until the test passes.

Both failure modes have the same root cause: the loop is implicit. The agent makes up the loop on the fly. Each session improvises a new plan, a new sense of done, a new sense of when to give up.

The fix I kept reaching for, before I built this, was structure I imposed by hand: a numbered checklist in the prompt, an explicit “run this command after each change,” a polite “stop and ask if you’ve failed three times in a row.” It worked. It also lasted exactly one session, because the next task started from a blank prompt.

Agent Levers is that structure, externalized. Once.

The lever metaphor

The name is the bet. A lever multiplies force on one end while reducing effort on the other. The human pushes on the short side — a one-line brief, plus answers to a handful of clarifying questions — and the agent lifts the long side: investigation, planning, execution, verification, learning.

The shape of the work is the Deming cycle, borrowed from process engineering and applied to a different kind of factory: plan → do → check → act. Every non-trivial coding task already follows that shape; it just usually lives in the agent’s head, where you can’t audit it. The point of the framework is to push the loop onto disk, where each step is an artifact that can be reviewed, paused, resumed, and continued by a different session.

Relationship between Coding Agents and Agent Levers

Four commands, one folder

The whole surface area is four slash commands, three of them user-facing and one of them an internal dispatcher you mostly forget exists.

• /lever-init — bootstraps the framework on a fresh repo.
• /lever-new