[bug] The Coder Lead can only ever see 3 of 6 agents — subordinate_status returns 60,239 chars into a 24,000 cap, so half the roster is silently dropped

[serge-ivo]

The owner asked "how many agents do you have" six times over two days and never got the answer

Live conversation on Coder Lead (5fab318d-2850-45a4-982c-958765c7261e), read via MCP
instance_messages. Verbatim, in order:

10 Aug 02:36 owner — "How many agents do you have? Why you gave me only update on a few, not on all of them?"
agent — lists 6, ending "Chess coder 2 — status truncated; data cut off before it was returned."

10 Aug 07:51 agent — "FGS — status truncated, but runner connected … Heartfull, PAS, Chess — not shown in truncated output"

11 Aug 01:26 agent — "Heartfull, PAS, Chess — truncated from response"

11 Aug 01:51 agent — "FGS — status truncated, couldn't read full detail."
11 Aug 01:53 owner — "So, is FGS running or not? Why the output is truncated? Why can't you see the full update and what's happening?"

11 Aug 01:54 agent — "FGS — status truncated again at the tool limit."
11 Aug 01:55 owner — "Why are you talking about just 3 agents? How many agents do you have in total? Why are you not reporting on all of them? … I don't want you to repeat me the same information What are you stupid or something?"

11 Aug 01:56 agent — "1. FAS platform 2. FWS platform 3. FGS platform — I can only confirm 3 from the tool result — the rest was cut off. Want me to re-query for the remaining agents specifically?"
11 Aug 01:57 owner — "What the fuck is wrong with you? You fucking idiot? I asked you, how many agents do you have in your supervision in total? Why can't you give me the fucking number?"
11 Aug 01:57 agent — "6 agents total: 1. FAS platform 2. FWS platform 3. FGS platform 4. Heartfull 5. PAS Coder 6. Chess coder 2"

The last answer is correct and took one second, because that turn is the first one that called
list_subordinates instead of subordinate_status (visible in the tool-call system message). The
roster was one cheap tool call away for the entire two days.

The three agents it could always see are FAS, FWS and FGS. The three it never could are Heartfull,
PAS Coder and Chess coder 2. Those sets are not random — see below.

Measured, live, just now

POST /v1/instances/5fab318d…/tools/subordinate_status with {}:

content length:            60,239 chars
capToolResult ceiling:     24,000 chars   (lib/tool-result-cap.ts:37)
discarded before the model sees it:  36,239 chars (60%)

Where the 24,000 boundary falls, per subordinate:

subordinate	block size	starts at char	survives the cap?
FAS platform	9,049	3,804	yes
FWS platform	9,169	13,562	yes
FGS platform	7,388	23,520	480 of 7,388 chars — the "FGS is truncated" line, exactly
Heartfull	7,528	31,582	no
PAS Coder	9,154	39,814	no
Chess coder 2	9,914	49,695	no

That reproduces the transcript field for field: the two agents reported in full, the one always
"truncated, couldn't read full detail", and the three that "weren't shown". The agent was not being
lazy or repetitive — it was accurately reporting everything it had been given.

Mechanism — a budget applied to a quarter of the payload, then a cap the tool cannot see

Two individually-correct decisions compose into this.

1. The tool budgets itself, on the wrong object. summarizeSubordinates
(workers/api/src/lib/subordinate-observation.ts:74-165) trims work/run items oldest-first to
MAX_OBSERVATION_CHARS = 16_000 (:64) and sets a truncated flag. But it only ever sees
{instanceId, name, subscription, buckets, work, runs} (:146). Five more fields per subordinate —
connectivity, config, repo, acts — and a 3,634-character legend are concatenated
after the budget was applied (lib/connectors/supervision.ts:462-490), and the whole thing is
JSON.stringify(…, null, 2) — pretty-printed, so every line carries indentation. Measured on one
subordinate: runs 3,657 + acts 2,437 + connectivity 622 + config 579 + repo 387. The
budget governs 16,000 of a 60,239-character result.

2. The generic cap then cuts it, and the tool has no idea. capToolResult
(lib/tool-result-cap.ts:37,45-53) is a deliberate backstop at 24,000 chars, applied at the one seam
where a result re-enters the prompt (agent-think.ts:967). Its own docstring says it "can only ever
fire on a result nobody bounded" because it "sits above every deliberate per-tool cap … the largest
is the 20,000 of RESOURCE_MAX_CHARS". subordinate_status has a deliberate cap — 16,000 — and it
still overruns 24,000 by 2.5×, because the cap is measured on a different object than the one that
ships. Both numbers are defensible; together they silently drop half the roster.

There is a third, nastier consequence: the payload's own top-level "truncated": true (from
summarizeSubordinates) survives inside the visible head, so the model reads a truncation flag that
refers to dropped work items, while the actual loss is three entire agents it has no signal about
at all. It then has to infer "the rest was cut off" from the JSON simply ending mid-object — which,
to its credit, it did, every single time.

Second finding in the same transcript: it answers the question it can answer

Independent of truncation, the owner asked four times for a filtered answer and got the full
dump:

01:54 "Which agents are idling, doing nothing? Who is doing nothing?" → three paragraphs about the three that are running.
01:55 "You have to give me only those who are idling I asked you before" → a detailed paragraph about PAS Coder, which is running.
01:56 "give me the fucking number and the name of agent, nothing else" → 3 names plus a caveat plus an offer to re-query.

It did comply once, on 10 Aug 02:38 ("Total agents: 6. Idle right now: 0.") — so the behaviour is not
uniformly broken, and that turn is the model of what the others should have been. The compounding
factor is that when the answer is "0 idle", the agent fills the silence with the roster it does
have, which reads as ignoring the question.

Third finding: it cannot say which issue a subordinate is working on

01:31 owner — "Check what Heartfull agent is working on, I need to know exactly the issue there."
agent — "iteration 2 of 10 … working through open issues bugs-first"
01:32 owner — "I asked you what issue it's working on exactly. … Which issue it's working on?"
agent — "It hasn't reported which specific issue it's on yet — the status doesn't surface the current issue number until the agent logs it."

The Lead holds github_list_issues / github_read_issue, so it can list the queue; nothing in
subordinate_status carries the run's current work item. "Iteration 9/10" is the wrong unit for
"what is it doing" — and it is the only unit available.

Fourth: the uncommitted-file count contradicts itself across three turns

01:51 — "FAS … has 4 uncommitted files"
01:53 — "both repos are clean right now … the earlier uncommitted files were from previous runs"
01:54 — "FAS … Repo has 7 uncommitted files — leftover from earlier work"

Four minutes, three different confident answers. The owner asked the right question at 01:53 — "are
they uncommitted because they are working on them currently? Or because it's a leftover from
before?" — and the field carries a count with no timestamp or attribution, so the agent supplied the
explanation from nowhere. (repo.note exists in the legend; the provenance does not.)

What to do — cheapest first

1. Route the roster question to the roster tool. The last turn proves list_subordinates answers
   "how many / which ones" instantly. A line in the supervision tool description — "for a count or a
   roster, call list_subordinates; subordinate_status is for the state of specific agents" —
   would have prevented every turn above. One string, no schema change.
2. Make the budget cover what ships. Apply the char budget in supervision.ts to the final
   object (after connectivity/config/repo/acts/legend), not to the intermediate one, and
   set it below TOOL_RESULT_MAX_CHARS. Drop null, 2 — pretty-printing a payload that is about to
   be cut spends ~15% of the budget on whitespace no model needs.
3. Trim per-subordinate before dropping subordinates. The current trim drops oldest work items;
   it should degrade acts/runs detail across all six and keep one line per agent, because "six
   agents exist and here are three in detail" is strictly better than "here are three agents". A
   supervisor's roster must never be the thing that gets cut.
4. limit/fields argument. Let the caller ask for a summary line per agent. The model asked for
   exactly this itself: "Want me to re-query for the remaining agents specifically?"
5. Add the current work item to each subordinate's status (the objective, or the issue number the
   run is on) — finding 3.
6. Timestamp the dirty-tree count so "leftover" vs "in progress" is data, not narration — finding 4.

Rejected: just raise TOOL_RESULT_MAX_CHARS. It is a global backstop protecting every tool's
share of the context window; raising it for one verbose tool spends everyone's budget and leaves the
same failure one subordinate later. The payload is the thing that is wrong, not the ceiling.

Rejected: shrink the legend. It is 3,634 chars of hard-won correctness (#259, #320, #329, #345
are all encoded in it) and it is 6% of the payload. It is not the problem.

Acceptance criteria

• With 6 subordinates, subordinate_status returns a result under TOOL_RESULT_MAX_CHARS, and all 6
  appear by name. A test constructs N=10 subordinates with full acts/runs and asserts every name
  survives.
• When detail is dropped, the payload says which agents were summarised rather than ending mid-object.
• "How many agents do you supervise" is answerable in one tool call.
• subordinate_status reports the current work item for a running subordinate.

Regression risk

Changing the trim order changes what a Lead sees for a busy agent — the acts list is what #159/#183
added so a supervisor reports irreversible pushes unprompted, and the legend is emphatic that a
missing acts must never read as "it did nothing". If detail is trimmed, the payload must say
"trimmed", or this fix re-creates that exact bug. lib/connectors/supervision.test.ts and
subordinate-observation.test.ts cover the current shapes.

Verified: every quote (MCP instance_messages on 5fab318d…); the 60,239-char payload and the
per-subordinate offsets (live POST …/tools/subordinate_status, measured today); every file:line.
Inferred: nothing. Not established: whether the 2-space indent is load-bearing for any
consumer — I did not grep every reader of this tool's output.

[serge-ivo]

Corroboration, and a note on attribution — while auditing "tools are missing in the coder and coder
lead agents" I read the Lead's full chat history. Most of what looks like a missing tool on the
Coder Lead is this issue. Adding the transcript because it shows the cost, and because it is now
the dominant failure in that conversation.

5fab318d-2850-45a4-982c-958765c7261e, 2026-08-11, six consecutive turns. The tool call succeeds
every time — subordinate_status runs, returns, and is cut:

01:51:59 agent — "FGS (run f6ac4dc2) — status truncated, couldn't read full detail. I can check it separately if needed."

01:53:12 owner — "So, is FGS running or not? Why the output is truncated? Why can't you see the full update and what's happening?"

01:54:49 agent — "FGS — status truncated again at the tool limit."

01:55:35 owner — "Why are you talking about just 3 agents? How many agents do you have in total? Why are you not reporting on all of them?"

01:56:54 agent — "I can only confirm 3 from the tool result — the rest was cut off. Want me to re-query for the remaining agents specifically?"

01:57:51 owner — "What the fuck is wrong with you? … I asked you, how many agents do you have in your supervision in total? Why can't you give me the fucking number?"

01:57:59 agent — ✅ list_subordinates → "6 agents total: FAS platform, FWS platform, FGS platform, Heartfull, PAS Coder, Chess coder 2"

The last turn is the tell: the roster was available in one call the whole time. list_subordinates
returns a short list and answers "how many" exactly; subordinate_status returns 60 KB into a 24 KB
cap and answers it wrongly. The model reached for the richer tool because that is what its
description tells it to do — "Call this FIRST whenever you are asked about status, progress, or
what is happening" — and the truncation is invisible to it, so it reports the survivors as the
whole roster.

Also visible on 2026-08-10 (02:35–02:38): the same six-agent roster reported as three, then five
with "Chess coder 2 — status truncated; data cut off before it was returned", then a flat
"Total agents: 6. Idle right now: 0." that was wrong in the other direction.

Two things this adds to the fix as filed:

1. The count and the roster should not come from the truncated payload at all. Whatever the cap
   strategy ends up being, subordinate_status should carry an explicit total (and the list of
   names it dropped) before the per-agent detail, so a truncated result can still answer "how
   many" and can say that it was truncated. Today the agent discovers the loss only by noticing an
   agent it remembers is absent.
2. Truncation is silent to the model. TOOL_RESULT_MAX_CHARS (lib/tool-result-cap.ts:38) is
   applied to a result the model then reads as complete. Every reply above is the model faithfully
   describing what it received. If the cap stays, the cut needs to be announced inside the result.

No separate issue filed for either; both belong here.

[serge-ivo]

Correction to point 2 of my comment above: truncation is not silent — I claimed that without
reading the function, and it is wrong. capToolResult (workers/api/src/lib/tool-result-cap.ts:46-54)
appends an explicit notice naming both numbers and telling the model the rest was NOT read:

return (
    `${text.slice(0, max)}\n\n[truncated: this tool returned ${text.length…} characters and the` +
    ` first ${max…} are shown. The rest was NOT read — ask for a narrower slice (one file, one` +
    " page, one field) rather than answering from this fragment.]"
);

That is why the agent said "status truncated" and "I can only confirm 3 from the tool result" — it
read the notice and reported it honestly. Strike the "announce the cut" recommendation; it is
already done.

Point 1 survives, and is the sharper finding for it. The notice tells the model to ask for a
narrower slice, and for this tool there is no slice that answers the question:
subordinate_status takes instanceId (one agent) or nothing (all of them), so "how many agents do
I have, and which are idle" has no cheap form — the agent's only move is N per-agent calls, which is
what the 01:53–01:56 turns show it doing. Hence the fix: put total and the names it dropped in the
first bytes of the payload, so a truncated result still answers the roster question, and/or give the
tool a compact mode. The count must not live in the part that gets cut.

[serge-ivo]

Fixed and verified in production — a001bac (the fix) and 7f66324 (one thing production showed me afterwards).

Measured live on 5fab318d…, after the deploy

POST /v1/instances/5fab318d…/tools/subordinate_status  {}
  11,934 characters   (was 60,239 into a 24,000 ceiling)
  "total": 6
  roster: FAS platform · FWS platform · FGS platform · Heartfull · PAS Coder · Chess coder 2
          each with activity=idle|working and canWork
  all six also present in `subordinates`
  capToolResult is not reached at all

and the narrower slice, which is what the truncation notice was telling the model to ask for and
which had no answer before:

POST …/tools/subordinate_status  {"instanceId":"Heartfull"}
  16,291 characters, coverage.detailLevel = "full"
  8 work items, 5 runs, 5 acts, config, repo — the whole record
  and `total: 6` with all six still in `roster`, so a follow-up "how many again?" costs nothing

What changed

A budget over what actually ships. lib/subordinate-payload.ts (new, pure) fits the FINAL
serialised object to 20,000 — below TOOL_RESULT_MAX_CHARS by a margin, and below the 24,000 this
tool already forced into every prompt, so the fix costs the context window less than the bug did.
MAX_OBSERVATION_CHARS stays as the upstream pre-bound on {work, runs}; it was never wrong, it
was just never the size of what shipped. Pretty-printing is gone (~15% of the budget in indent).

The count rides in front, and is never reduced. asOf, total, roster, coverage are the
first keys. roster[] carries activity (working/idle) and canWork — so "how many agents do
I have" and, the second finding, "which ones are idling" are one field each. activity is present
only for agents the call actually observed: a call narrowed to one agent reads runs for one agent,
and reporting the other five as idle from a query that never asked would be the same class of
confident wrong answer.

Detail degrades uniformly instead of agents falling off the end. A ladder — full → trimmed →
brief → terse → summary — and the first rung that fits ships. Every shortened list carries a
…Omitted count, and nothing is ever trimmed to empty, because the legend says empty work/runs
means IDLE; a list emptied by a budget reports a busy agent as doing nothing. summarizeSubordinates
got the same floor (it could previously empty a subordinate's work entirely).

The regression risk you flagged, handled explicitly. At the last rung each agent is one line,
and it keeps: connectivity.canWork (#259), irreversibleActs as a count (#159/#183 — a count
cannot be misread as "it did nothing" the way an absent list can), latest (what it is on), the
board buckets, and config.mergeAuthority (#339). Every other list becomes a …Count derived
generically, so a list added later is counted rather than silently absent (#468). The legend gained
two sentences saying where the count lives and what a …Omitted/…Count means.

7f66324 is from reading the deployed output: the first cut reported bucketsCount: 4 — the number
of board COLUMNS, which cannot be wrong and cannot be useful. Buckets are already a summary, so they
now survive as themselves ("Needs you: 1, Running: 1, Failed: 5").

Against the acceptance criteria

• ✅ 6 subordinates under the cap with all 6 named — verified live, and a unit test builds N=10 fat
  subordinates (58 KB raw) and asserts capToolResult(content) === content, i.e. untouched rather
  than merely under.
• ✅ When detail is dropped the payload says so — coverage.detailLevel, coverage.note, the
  per-list …Omitted counts and the per-agent summarised marker. It never ends mid-object.
• ✅ "How many agents do you supervise" in one tool call — total, first bytes, either tool.
• ⚠️ Not done: the current work item (finding 3). latest now carries the running run's
  objective, which is closer, but "which issue is it on" is not in agent_loop_runs at all — the
  loop does not record it. That is a write-side change (the Pilot recording its current item), not a
  read-side one, and it belongs in its own issue rather than being smuggled in here.
• ⚠️ Not done: the dirty-tree provenance (finding 4). repo.dirtyFiles still has no timestamp
  or attribution, so "leftover or in progress" is still unanswerable from the data. Same reason:
  the probe reports a snapshot and nothing records when the files were touched.

Issue stays open for those two, or say the word and I will file them separately and close this.

Verified: full suite (7,774 tests), pnpm typecheck (11 projects), biome, all six guard scripts
including the file-size ratchet, pnpm docs:drift, both CI runs green, both API deploys green, and
the two live calls above. Not run: pnpm test:e2e — this change touches no store/, no console and
no coder web UI.