The Status a Peer Can Trust: Verified Progress for In-Flight Agents

TL;DR: two agents running at the same time have to tell each other what is happening right now — am I still moving, how far did I get, is it safe for you to start. Every A2A protocol standardizes the shape of that message and leaves its truth to the sender: the status is a self-report, authored by the same process whose progress you are trying to grade. fak’s answer is a run digest with no claimed field by construction — a peer is handed a pointer to progress the kernel verified (a git commit, an intent-ledger row), never a number the worker asserted. The one line to keep: status is a re-verifiable cursor, not a self-report.

Concept served: this is the in-flight, agent-to-agent sibling of Verify, don’t trust. That page is about grading a worker after it stops (did the commit land, is the memory still true). This one is about the harder, live case: a running agent B needs to read a running agent A’s state and act on it — before either has finished, with no human reading the diff in between.

The problem: an in-flight worker narrates its own status

Give an agent a long task and set a second agent to depend on it. The dependent agent needs to know: is the first one still alive, how far has it got, is the file region it holds safe for me to touch yet. The cheapest way to answer is to ask the first agent — and its answer is the least trustworthy signal in the system, because it is a self-report produced by the process whose progress you are trying to grade. “I’m 80% done” can be a hopeful guess. “Working” can mean wedged in a retry loop. “Completed” can mean it deleted the failing assertion. The confidence–accuracy gap — agents reporting high confidence in wrong answers — is by now a documented failure mode of multi-agent systems, not an edge case (survey).

In a single-human workflow you catch this by reading over the worker’s shoulder. Across a fleet of agents running concurrently, nobody is watching every worker. So the question is not “how do we transport a status message” — that is the easy half, and the whole industry has solved it. The question is: when agent B reads agent A’s status, can B believe it without trusting A?

What the standards actually standardize: the self-report

The 2025–2026 wave of agent-interop protocols all answer the transport half and punt on the trust half:

None of this is wrong — a shared vocabulary for task lifecycle is real progress, and fak deliberately interoperates with it (it projects a policy-filtered A2A Agent Card from its reviewed method registry; see the interoperability stance). The point is narrower: the wire format standardizes the shape of a status, not its truth. Signed Agent Cards prove who an agent is; they do not make the agent’s report of its own progress any less self-authored.

The research frontier has converged on exactly this gap. “From Agent Traces to Trust” argues agent trustworthiness “cannot be reduced to model accuracy alone; it depends on whether the execution process can be reconstructed, inspected, and governed” (arXiv 2606.04990); “VET Your Agent” pursues host-independent autonomy via verifiable execution traces (arXiv 2512.15892); “Right to History” proposes a sovereignty kernel unifying Merkle audit logs and capability isolation for verifiable agent execution (arXiv 2602.20214). The shared move: stop grading the answer, start grading the provenance.

fak’s answer: a digest with no claimed field

fak’s stance is structural, not exhortatory. It does not ask a worker to report honestly; it hands a peer a status object that has no field a self-report could occupy. The load-bearing property is a negative one: the digest has no claimed key by construction. A peer reading it cannot pick up a self-report it is never handed — progress is built only from the kernel’s verified rung.

Three surfaces carry the same shape, at three grains:

1. The run digest — dos_status

dos_status folds four adjudicated verdicts about a whole run into one peer-readable record: liveness (is it moving? — forward commit delta), progress (read from the intent ledger’s own rows, never the worker’s claim), region (the lease the run holds, so you know what files are unsafe to touch), and resume (the plan, computed only once the run has stopped). Every edge fails closed: a run with no intent ledger is a valid zero-progress fact, not an error; a run holding no lease has an empty region. It is the legible, peer-facing form of dos verify’s distrust discipline aimed at a run instead of a single phase — and it deliberately returns no claimed key.

2. The task read — the A2A HTTP edge

GET /a2a/v1/tasks/{id} returns a task’s own imperative record (state, result — the forgeable, self-authored half) and, alongside it, a progress object: the same no-claimed-field VerifiedProgress shape projected across the edge (internal/gateway/a2a.go, internal/relay/progress.go). progress is not a percentage and not a “done” boolean a closing leg could set; it is a list of steps, each a durable Ref — a commit SHA, an issue #1234, a memory slug, a path — that the reader can go re-read to confirm the step happened. So a foreign peer polling the task gets, in the same payload, the worker’s story and a cursor into evidence the worker did not author.

3. The live correction — a2achan

The tightest case is one running agent correcting another mid-flight. In internal/a2achan a worker exposes a live WorkerStatus row with a stable Digest(). An orchestrator’s CorrectionRequest is refused unless it cites that digest and matches the worker’s issue/task/lane exactly: a stale or fabricated status is turned away as UNWITNESSED before it reaches the worker’s inbox, an out-of-scope correction as TRUST_VIOLATION, oversized text as OVERSIZE. And the correction only counts as witnessed once the worker both acks it and reflects its id in its next planned action — acked-and-reflected, not acked-alone. Neither side is trusted on its word; each move must cite the other’s unforgeable handle.

Every one of these rides the same default-deny capability floor that gates an ordinary tool call — coordination in fak is not a side library with its own security surface (the full normative spec is the Multi-Agent Coordination Protocol RFC).

Why it holds: progress is a cursor, not a number

The through-line: fak never gives a peer a place to write a self-reported status, so a peer never reads one. Progress is a re-verifiable cursor — a pointer into git and the intent ledger — and the reader re-derives the truth from the artifact the worker could not forge. It is the live, agent-to-agent projection of the repo’s oldest rule: the model proposes, the kernel disposes — extended to the worker reports, the peer re-verifies.

Honest scope

Where to go next