[bug] check_work makes a supervisor deny work it just delegated — the #254 guard misfires on delegators

[serge-ivo]

What happened

Coder Lead (5fab318d), 2026-08-06. User: "Focus on FAS platform. Can you clean it up?"

22:33:44 — the tool log records, unambiguously:

✅ delegate_goal   Delegated. Run 97a46cbc-04ad-43a5-8030-076d4ad9e88a started at depth 1.

and the Lead reports: "FAS platform is still running the cleanup — iteration 0 of 10."

22:35:00 — user: "Did you just do this action or it was done before?"

22:35:15 — the Lead calls check_work, which returns:

✅ check_work  You have not started any work on this instance — there are no runs.
               If you told the user you did something, that was wrong; say so.

and it answers:

The cleanup on FAS platform was done before this conversation … I did not trigger it in
this session; it was already finished when you asked me about it.

It did trigger it, 90 seconds earlier, and the transcript proves it.

Cause

check_work is scoped to the calling instance, correctly and deliberately
(tool-registry.ts:97):

// Scoped to THIS instance, not just the owner … without this an agent could read another of the
// owner's agents' runs and report it as its own — a fresh way to describe work it did not do.
if (!run || run.instanceId !== ctx.instanceId)

But a supervisor's work is not on its own instance. delegate_goal starts the run on the
SUBORDINATE (instanceId: 964594b6…, the FAS Coder). So for a Lead, check_work truthfully reports
zero runs — and then appends (work-report.ts:79):

"If you told the user you did something, that was wrong; say so."

That sentence was written for #254, where an agent denied work it had really done. Applied to a
supervisor it produces exactly the failure it was built to prevent, in the opposite direction:
it instructs the model to retract a true statement, and the model complies.

The Lead already has the right tool — check_delegation — and had used it two turns earlier.
Nothing told it that check_work is the wrong question for a delegator.

Why this one matters

A supervisor that denies delegating is worse than one that cannot delegate. The user now has to
verify every claim against the run log, which is the entire job the supervisor exists to do. It
also poisons the transcript: the next turn is built from a history in which the delegation did not
happen.

Fix

Make the tool aware of what kind of agent is asking. For an instance that supervises anyone,
check_work should report delegated runs too — or refuse and redirect:

"You delegate work rather than running it yourself. Use check_delegation to see runs you started
on your subordinates."

And the no-runs sentence must not assert the user was misled unless it can actually tell.
"There are no runs on this instance" is true and safe. "If you told the user you did something,
that was wrong" is an inference the tool is not entitled to make — it does not know what else the
agent has done, and here it was simply false.

Ideally check_work on a supervisor returns the union: own runs plus runs it delegated (the data is
there — agent_loop_runs carries the instance, and the supervision graph carries the roster).

Verification

• A Lead that has just delegated, asked "did you do that?", answers yes and cites the run id.
• check_work on a supervisor with zero own runs but live delegations does not say "you have not
  started any work".
• The [bug] The prompt still forbids what start_work does — a Coder denied real work and told the user to redo it #254 case still holds: an agent that ran nothing and claimed it did is still corrected.

[serge-ivo]

Fixed in 792d7a0.

Why check_work missed the delegation: it is scoped to the calling instance — correctly, so an agent cannot read another of the owner's agents' runs and describe them as its own — but a supervisor's runs are never on its instance. delegate_goal starts the run on the subordinate, so a delegator structurally has zero runs of its own, and the empty-case sentence then asserted the user had been misled.

The fix matches the query to what a delegator does, rather than softening the message:

• runs now record who asked for them — agent_loop_runs.delegated_by (migration 0090), populated from the onBehalfOf that was already threaded through every driver and then discarded. Audit-shaped, never an authority.
• check_work reports own and delegated runs, naming the agent each ran on, and accepts a delegated run id (instance identity alone rejected it).
• deliberately not derived from the supervision graph: "every run on an agent I supervise" also contains runs the owner started there, and claiming those would be a fresh over-claim in the opposite direction.
• the correction sentence is withheld only from a delegator, for whom an empty own-instance record is the normal state.

Not weakened: for an agent that delegates to nobody the #254 wording is byte-for-byte unchanged, and a run on a sibling agent this one did not delegate is still refused. Both pinned by tests.

Two contributing causes went with it. executionAuthorityPrompt had no delegation branch, so a Lead was told it "cannot run shell commands… never claim you fixed a bug" — false for the only thing it exists to do; canDelegate is now derived from the resolved tool set like every other sentence there. And the recent-work prompt block only fired for canStartWork, so it never fired for a supervisor — the Lead here did call check_work and still recanted, so the answer belongs in the prompt before the challenge arrives.

⚠️ No CI run verified this — GitHub Actions is in a declared major outage and has created no run for any commit in ~20. Verified locally: pnpm -r typecheck, vitest (4389 passed), biome (no new diagnostics), docs:drift, check-file-size.