The code is written. Before the task is accepted, someone still has to recover a failed run, find missing evidence, or explain the same constraint again.
How much human work is left?
Our earlier discussion about agents reaching their usage limits focused on safe handoffs. I want to extend that discussion to the human effort across an entire task.
Here, finished means the result has met the task's agreed acceptance criteria, including a check in the intended environment where relevant.
The following is a proposed measurement method. I am not presenting a measured productivity improvement.
Follow one task through acceptance
Imagine an agent updating a small feature. It prepares the code quickly. During the remaining work, a person clarifies a requirement, retrieves a review result, investigates an interrupted operation, and approves the release.
Those interventions have different purposes. I would record them separately:
| Intervention | Example | Useful record |
|---|---|---|
| Necessary judgment | Choose between two valid behaviors or authorize publication. | The decision, decision holder, and active time. |
| Missing information | Repeat a constraint or locate evidence that the successor needs. | What was missing, where it should live, and active time. |
| Recovery | Establish what happened before an interruption and prepare a safe restart. | The uncertainty, recovery action, and active time. |
The goal is to preserve necessary decisions while reducing avoidable recovery and information-search work.
A lower intervention count needs context. One long investigation may cost more than several quick decisions. A task that silently skips an approval would also make the count misleading.
A log small enough to use
For each intervention, record:
- Task identifier and the agreed outcome.
- Intervention reason.
- Human active minutes.
- Information or evidence needed to continue.
- The next permitted action and who owns it.
At the task level, record elapsed time, waiting time, final status, and acceptance evidence. Keep waiting time separate from active work. When several people participate, record their active time separately and add it for the task total.
Statuses should include accepted, still in progress, blocked, and abandoned. Keeping those entries makes unfinished work visible when reviewing the workflow.
The first improvement might be quite small: retain the exact reviewed revision, preserve the unresolved operation after a timeout, or put the current task constraints somewhere a successor can find them.
The log should show which change would remove a recurring intervention.
Add cost without hiding the unfinished work
For a defined group of comparable tasks and an observation window, I would track three measures together:
- Human active time through the end of the observation window.
- Time to acceptance and the number still unresolved.
- Actual cash spending, including retries and recovery.
Record subscription usage separately from additional charges. If a subscription fee is allocated across tasks, state the allocation rule. Keep human time in minutes unless a labor-cost assumption is explicitly supplied.
For a cost-per-accepted-task calculation, retain the spending on failed and unfinished tasks in the same group. Report the acceptance count alongside the ratio. If nothing has been accepted, report spending and zero acceptances directly.
This creates a basis for comparing similar work before and after a workflow change. The comparison still needs matching scope and acceptance requirements.
Start with the intervention you keep repeating
For your last accepted agent-assisted task, how many times did you step in, and which intervention would you remove first?
A rough breakdown of active time and intervention reasons is enough to start. I am particularly interested in repeated explanations, evidence searches, and recovery steps that a better handoff could address.
Disclosure: I maintain Agent Role Contracts (ARC) at Netsujo. ARC checks declared responsibilities, scope, reviews, and handoffs. The intervention log proposed here measures the surrounding workflow; any claim of reduced effort would need actual observations.
