Reviewing agent-assisted technical work

Agent-assisted work can move quickly from a request to code, commands, and a summary. Before acting on the summary, a reviewer needs to know what the work established. Keep the diff, checks, logs, and remaining unknowns together so the next decision rests on evidence.

A verification loop starts with one question and one scoped change or investigation. It produces a diff, test output, logs, a manifest, or measurements. Review of those records determines whether the next action should continue, narrow the work, change direction, or stop. The loop helps a reviewer decide what an agent’s work proves, what it leaves open, and what to ask next.

Each task leaves a record suited to its risk. A code change can have a diff and tests. A long-running command can have logs, progress state, and a result. A data transformation can have a source snapshot, a run ID, and output files. The reviewer can then inspect the record that supports the next decision.

Scoping agent work

A broad request leaves the goal and constraints unstated. “Improve the pipeline” can produce many plausible changes. “Find why worker slots are idle at the end of a batch; keep the request limit unchanged; add a measurement for the next run” names the observed problem, the constraint, and the expected output.

One source-capture workflow supplied that example. In the observed pre-change run, a job with a request limit, eight worker slots, retries, a job ledger, and a progress sidecar completed about 12.2 jobs per minute. The ledger recorded retries and terminal failures. The sidecar, a small JSON status file, recorded completed and pending jobs. Elapsed time and completed counts showed worker slots waiting for slow requests and retries. The next change targeted queue scheduling and left the request ceiling unchanged.

Review records

The review record should match the work. A code change can include a focused test, the full suite, a compile check, a diff check, and a small fixture run. A data operation can retain its source version, configuration, output checksums, and field-level results. A background process can retain a ledger of attempts and a current progress file.

In the scheduler example, the run was configured for three requests per second and concurrency eight. It added 424 completed jobs in 34.7 minutes. The implementation refilled a worker slot after a request completed and recorded request elapsed time and transport-attempt counts. All 64 tests passed; the compile and diff checks also passed. Those checks established that the changed implementation passed its defined checks. A comparable post-change run is still required to measure the effect on completed jobs per minute.

Tests establish an implementation state. Measurements establish observed behavior. A later comparison can establish whether behavior changed under equivalent conditions. Each record answers a different question.

Result context

Many agent tasks produce data, reports, or retrieval results. Those outputs need provenance for a later review or reproduction. A run manifest can retain a source hash, run ID, environment, configuration, and output checksums. A result can retain the fields, terms, and rule version that produced it.

claim: example retrieval rule returned record OCID-123
evidence:
  source_snapshot: sha256:...
  rule_version: ict/2026-08-23
  matched_fields: [title, description]
  matched_terms: [network, modernization]
  replay_check: fixture passed

This record lets a reviewer inspect the source, rule, and interpretation separately. It can also record a limit: a missing identifier, a malformed field, a source that lacks coverage, or a retrieval rule without a reviewed reference set. Those findings narrow the permitted claim or require a follow-up check.

Evidence-driven follow-up

The purpose of the loop is to change the next request when the evidence changes the question. In a 25-document pilot, review of field coverage supported a descriptive explorer and evidence-backed retrieval. The review found no basis for prediction or commercial-likelihood claims, so the next work stayed within those limits.

Verification loops keep a scoped change, its observed result, and its remaining limits together. That record gives the reviewer a concrete basis for the next request.