Part 20: Bounded tasks and ongoing work

You operate two kinds of agent and they tend to get one kind of management. The first fixes a bug, runs a migration, or writes a report. It starts, works, and stops. The second triages an inbox, watches a queue, or keeps dependencies current. It has no last step. Ask "is it done?" of the first and the question has an answer. Ask it of the second and the honest reply is that the question does not apply.

Tell the two apart first#

	Bounded task	Ongoing responsibility
Shape	Has a start and an end state you can describe	Runs until someone stops it
Examples	Fix issue 4821, migrate a table, draft the quarterly report	Triage refunds, keep dependencies patched, answer tier-1 tickets
The question	Did the checks hold?	Is it inside its authority and budget, and what is it waiting on?
Managed through	Completion criteria set before the work starts	Authority, budget, and review points
Reviewed	At the end of the run	On a schedule, and when a threshold trips

The common mistake runs in one direction: inventing a finish line for ongoing work so that it fits a task tracker. An inbox agent with a "done" state will report done. That tells you nothing about the inbox.

Bounded tasks: define completion before the work starts#

Part 10 made tests the ground truth of behavior and had the agent write the failing test first. Generalize that. Before a bounded run begins, write down the checks that decide completion, and fix them so the run cannot revise them.

A command that must pass. pytest tests/test_billing.py exits 0.
A file or a diff condition. The migration exists. No file outside billing/** changed.
A human decision. The release owner approves the pull request.

Fixing the checks first matters for a plain reason. An agent that judges its own work can stop early or skip verification. The Berkeley taxonomy names this family of failures: premature termination, and no or incomplete verification, both recorded across the frameworks they studied.⁵ A check the run cannot edit removes the agent's opinion from the verdict. The verdict becomes a function of recorded results, and another person can recompute it from the record (part 19).

# done/issue-4821.yaml     written before the run, hashed when it opens
task: "Fix DecimalConversionError on POST /api/v2/refunds"
checks:
  - run:   "pytest tests/test_billing.py::test_refund -x"
  - run:   "ruff check billing/"
  - diff:  { only_paths: ["billing/**", "tests/**"] }
  - human: { role: release-owner, question: "Safe to ship in 2026.09?" }
on_fail: { retries: 3, then: route_to_operator }

Counterweight · What a passing verdict means

A passing verdict means the specified checks held. It does not establish that every requirement was captured or that every action was correct. Your team decides whether those checks are enough for the task, and a thin set of checks passes thin work. When checks fail, the useful record is not just "failed". It is the reasons, and whether the agent continued, waited for a person, or reached its retry limit.

Ongoing work: authority, budget, and review points#

An ongoing agent is managed the way you manage a standing responsibility held by a person. You do not ask whether they are done. You look at what they are allowed to do, what they have spent, what they are waiting on, and what they did since you last looked.

Authority. The mandate from part 15, reviewed on a date, not only when something goes wrong.
Budget. The monthly limit and the per-run ceiling from part 17, with the at_limit action stated.
Open requests. The routed requests from part 16 that a person has not yet answered. This is the list an operator reads first each morning.
Review points. A schedule (weekly for a new agent, monthly once it is stable) and a few thresholds that trigger a review early.

Review trigger	Reading	Usual cause
Denials rise week over week	`requests_by_answer`	A tool or a task changed and the rules did not
Run cost p99 leaves its band	`cost_per_run_p99`	A loop, often on a failing check or a stale index
Routed requests wait longer	`time_to_answer_p95`	The named approver changed roles, or the rule routes too much
Tool use ratio falls	`tool_use_ratio`	The work drifted away from the equipment
The operator changes	Inventory	Nobody has re-read the mandate since

The operator's week#

Put together, the operating job is small and regular. Daily, answer what is waiting. Weekly, read the spend and the denials for each agent, and review the runs that tripped a threshold. Monthly, re-read each mandate with its three owners, retire the agents nobody can justify, and turn repeated approvals into narrower rules. The field kit has this as a one-page checklist. None of it requires reading transcripts, which is the test of whether parts 14 to 19 are in place.

Where Oxagen fits

Oxagen is where that week happens. Every agent enrolled in Oxagen is on the Runs page with its mandate, its open requests, its spend, and its last run. An operator answers routed requests from the Access page, and an ongoing agent shows its authority, its open requests, and its spend this month with no finish line. Oxagen treats completion checks as an optional control for bounded tasks. They are not the definition of the product, and ongoing work does not need them.

Do this week

Sort your agents into the two columns. Use the inventory from part 14. Anything you cannot place is doing both jobs and should be split.
Write completion checks for one bounded task type. Start with the one that reaches review most often. Three checks are enough: a command, a diff condition, and a human decision if the change ships.
Fix the checks before the run. Hash the file when the run opens and record the digest as the first row. Reject a run whose checks changed midway.
Set two review triggers for one ongoing agent. Pick from the table. Send the alert to the operator by name.
Put the monthly mandate review on a calendar. Thirty minutes, three owners, one agent at a time.

Measure it

checks_held_first_attempt: bounded runs whose checks held without a retry, over all bounded runs. This is first_attempt_rate from part 13, against criteria the run could not edit.
runs_closed_without_checks: bounded runs that ended with no completion criteria at all. Each is a verdict by assertion.
open_requests_age: the oldest unanswered routed request, per operator.
days_since_mandate_review: per agent. Over 90 is a review that is due.

Takeaway

Define completion when the work has an endpoint, and fix the checks before the run starts. When the work continues, do not invent a finish line. Manage its authority, its requests, and its spend on a schedule.

Bounded tasks and ongoing work

Tell the two apart first#

Bounded tasks: define completion before the work starts#

Ongoing work: authority, budget, and review points#

The operator's week#

Cite this

Updates by email