Tracking AI agent progress: built vs accepted

Tracking AI agent progress: built vs accepted means keeping at least three numbers apart: how much work is implemented, how much of it still has current passing evidence, and how much a person has actually accepted. Agents push the first number up quickly. The other two move at the speed of your checks and your review, and that is where real progress lives. If you report one blended figure, the project looks further along than it is, and the gap shows up later as surprise rework. This article gives you a way to measure each number honestly, a short weekly routine for reading them together, and a guide to what the gaps between them mean. It works with a spreadsheet, an issue tracker or a kanban board for agent work, and it pairs well with milestones defined by accepted outcomes.

Three numbers, three different questions

Implementation answers: what does the record say has been built? A task counts when the code exists and the agent or developer says it is ready for checking. Current evidence answers: do the checks that support that work still pass against the code as it is today? A test run from last Tuesday says nothing about a file changed on Thursday. Acceptance answers: which outcomes has a named person looked at and agreed are done?

Each number needs its own denominator. Implementation is usually counted over tasks. Evidence is counted over checks. Acceptance is often counted over a checklist of outcomes that does not map one to one onto tasks. Mixing denominators is the most common way progress reports go wrong. Ten tasks done and twelve of twenty checklist items accepted cannot be added into one percentage, and they should not be. Write each figure with its denominator next to it, for example: 31 of 40 tasks implemented, 22 of 30 checks current, 12 of 20 outcomes accepted.

Why agent work inflates the first number

With a human team, implementation and review tend to move at a similar pace because the same people do both. With agents, implementation becomes cheap and fast while review stays human. The result is a growing pile of work that is built but not looked at. An agent's report that a task is complete is a claim, not a measurement, so it belongs in the implementation column at best.

A concrete example from BRAIN FLUID's own development workspace on October 30, 2026: the board held 123 cards, with 50 DONE and 39 in VERIFY, meaning built and waiting for review. A separate acceptance checklist had 139 items, 70 passed and 69 pending. Those are different populations, so they are not one count, and neither is a release-readiness score. DONE could also mean implementation closed at the owner's direction before manual acceptance. Reporting only the cards that moved would have overstated where the project stood; reporting only the checklist would have hidden how much built work was waiting.

A weekly progress read in five steps

Step 1: Count implementation. List tasks by state and count those that are built, whether or not they are reviewed. Note how many sit in review.

Step 2: Check evidence freshness. For each check that supports built work, ask whether the code it covers changed since it last passed. Anything that changed is stale until rerun. Treat a missing result as unknown, not as a pass.

Step 3: Count acceptance. Use your outcome checklist, not task states. Only items a person explicitly accepted count.

Step 4: Compare with last week. Record the three figures in a dated note. The trend matters more than the level: implementation rising while acceptance stays flat is a warning.

Step 5: Pick the next review action. End the read with one concrete action, such as reviewing the three oldest items in VERIFY or rerunning the stale export tests. If the read produces no action, it was a status ritual rather than progress tracking. The weighted progress article covers how to stop small and large tasks counting the same.

Reading the gaps between the numbers

High implementation with low acceptance usually means review is the bottleneck. Starting more agent work will make it worse; a WIP limit on work waiting for review is the usual fix.

High implementation with stale evidence means code has moved under earlier checks. Shared helpers are the classic case: a change in one module can leave another task's earlier pass meaningless. Rerun the checks before you trust the old results, and see stale test results for why a green run can expire.

Acceptance higher than implementation is rare but happens when outcomes are accepted on a demo before the underlying tasks are closed. That is usually a bookkeeping problem, but check it rather than assume.

All three high and the project still feels unfinished? Your checklist is probably missing outcomes. Add them, and accept that the acceptance figure will drop. A number that went down because you measured more honestly is progress in itself.

QUESTIONS

Should VERIFY work count toward project progress?

Count it toward implementation, because the work exists and is ready for checking. Do not count it toward acceptance, because nobody has agreed it is right yet. Showing both figures side by side makes a large review backlog visible instead of hiding it inside a single percentage.

How often should I measure progress on an AI-assisted project?

Weekly is enough for most projects. Daily counts tend to track agent activity rather than outcomes and create noise. Take the three figures on the same day each week, write them in a dated note, and compare trends rather than single readings. Measure more often only near a deadline.

What is the difference between built and accepted?

Built means the code exists and someone, often the agent, says it is ready. Accepted means a named person checked the outcome against what was asked and agreed it is done. An agent can produce the first on its own. Only a human decision produces the second.

RELATED GUIDES

• How to read project progress in BRAIN FLUID Build
• How to read BRAIN FLUID reports and provenance

RELATED HARNESS PAGES

• Milestones for AI-assisted projects Milestones for AI-assisted projects: define them by accepted outcomes and passing checks, not by cards closed, and keep release a separate decision.
• Weighted progress: why card counts mislead Weighted progress: why card counts mislead. Give tasks explicit weights against a fixed baseline, count only accepted work, and rebase when scope changes.
• WIP limits for AI agent work WIP limits for AI agent work: why agents make starting too easy, and why the limit belongs on review capacity rather than on running sessions.
• kanban for AI agents Kanban for AI agents: the board states that matter when software does the work, including review, blocked and decision owed.
• Deciding which AI agent tasks need human sign-off Deciding which AI agent tasks need human sign-off: a risk-based policy, who signs off what, and why DONE is not the same as released.