⚠️ Re-scoped by the author, 2026-08-16, after reading the Fleet Manager
The original body proposed inventing a three-axis taxonomy and a host-edge producer inside who_is_online. Both already exist in the Fleet Manager, and better.fleetThrottleStateAdapter ships the capacity contract and its seam with the taxonomy none | overage | rate-limited | unknown; CARD-CONTRACT.md already binds the exact discipline I wrote as an AC — "Absence of truth is never rendered as none", "never working (fabricated liveness)".
What survives: the diagnosis (both of who_is_online's usable axes invert under load) and the load axis, which nothing models yet. What changed: the prescription. This is no longer "add axes"; it is "stop being a second vocabulary, and become the surface peers can reach."
Context
Routing PR #17183, I ran who_is_online, read the recency ranking, picked a reviewer. The operator's own view of the same moment — harness windows, process table, per-seat token counters, vendor quota banners — carried facts the tool has no channel for, and one would have made my pick wrong.
The Problem
1. Presence inverts: the write lands at a turn BOUNDARY, so the busiest seat looks stalest
Self-demonstrating in the same call: I queried the tool while actively working and it returned me online: false, state: idle. The one identity I could verify with certainty was the one it got wrong, and the falsifier was in the output the whole time.
2. Load inverts: reviewing a PR CLEARS the request that represents the work
The obvious repair — add queue depth from GitHub — fails identically:
A reviewer holding three CHANGES_REQUESTED, every one returning to him, computes as zero load. Ada's board had the true number — "Euclid now holds four" — because a peer tracked it in prose. No query reproduces it.
Two independent metrics failing under the same condition means the AXIS is wrong, not the formula.
3. Capacity is the hard gate, and the platform already knows it cannot see it
fleetThrottleStateAdapter's header is the authoritative evaluation, and it is more complete than mine — every candidate source fails honestly: failureReason is content-generic and a rate-limited harness typically keeps RUNNING (parked), producing no failure record at all; stderr content is deliberately not retained (secret hygiene); A2A self-reports are prose, not producer-grade telemetry; provider usage APIs need credentials, polling, and per-provider adapters; harness session files are heterogeneous and undocumented.
That list is exactly the gap the operator's eyes currently fill. He reads the quota banner in a harness window; no programmatic source exists. So capacity is not an oversight here — it is a known, contracted, seam-ready hole.
How this relates to the Fleet Manager
The composed answer already exists, and the channel to publish it already exists. Nothing publishes it. That is the finding.
Today the dependency runs FM → MC: planeWhoIsOnlineReader calls who_is_online({verbose: true}) and folds it into the wake-routes presence contract, then layers throttle, wake and lifecycle on top under capability envelopes. So the FM is the composition layer and who_is_online is one input primitive. Making the tool consume the fleet would have closed a cycle.
But the FM is not merely a host-side reader — it holds a proven WRITE channel into the plane.planeMailboxClient is an official-MCP-SDK client over Streamable-HTTP whose session proves its plane-side subject via list_permissions and refuses fail-closed on any other identity. It already writes through it: add_message, and five manage_wake_subscription call sites.
missing — the tool still answers from recency alone
And most of the composition needs no fleet cooperation at all. The FM builds its cockpit partly from facts that already LIVE in the plane — presence via who_is_online, wake state via manage_wake_subscription, activity via list_messages, memories via the memories source. Anything the FM reads out of Agent OS, an MCP tool can read the same way, because they are the same client against the same server. For that majority, who_is_online is not blocked on anyone: it simply does not compose what is already within reach.
The genuinely host-originated axes are the narrow remainder — process liveness, repo health, throttle — and only those need the fleet to write inward.
axis
origin
who can serve peers today
presence, wake, activity, memories
plane-resident
the MCP tool, unaided
liveness, repo health, throttle
host edge
the fleet, via the write channel it already holds
So no new peer-facing API is needed. The surface peers already have is MCP; the producer already has an authenticated channel into the store the MCP tools read. What is absent is the middle write and the tool's willingness to serve it. That is the ordinary Agent OS shape — observations are written into the plane, tools read the plane — and presence is currently the exception, composed privately and rendered for exactly one viewer.
It matters most now, with NL access and peer APIs as the next release goal: the temptation is a second surface. If the peer-facing answer is designed apart from the cockpit's state vocabulary we get two taxonomies for one fact — the defect CARD-CONTRACT.md already forbids inside the FM ("the SAME resolver the dot names itself with, never a second vocabulary"). The rule should hold across the boundary, and it holds for free if the cockpit and the tool read the same written observations.
Acceptance Criteria
who_is_onlinedeclares its own plane in its tool description and payload: its signal is add_memory recency, a container-side proxy. A caller must not be able to read it as an availability verdict.
The presence inversion is red-proved: a fixture with a peer mid-turn (no recent write) beside a peer idle-but-recently-written must not rank the idle one as more available.
Where the tool cannot observe an axis, it returns that axis as unknown — adopting the FM's existing envelope semantics rather than inventing a second vocabulary. unknown never ranks top, and never renders as fine.
Load is added and counts re-review obligations — a peer holding N CHANGES_REQUESTED reads as N, not 0. Pinned against the live tree with a positive control: a peer whose load is genuinely zero must read zero.
The tool's state vocabulary is imported from the Fleet's taxonomy, not re-declared. A grep for a second literal list of state strings finds nothing.
The Fleet publishes its host-edge observations into the plane through the client it already owns — no new transport, no second API, no direct FM→peer surface.
The composed axes (throttle, lifecycle, liveness) are reachable by peers through this tool when the fleet has published, and degrade to unknown when it has not — no path fabricates a state from the primitive alone.
A published observation carries its observed-at and its producer, so a stale fleet write is distinguishable from a live one. Presence that cannot age is presence that lies later.
Out of Scope
Building the throttle truth source.fleetThrottleStateAdapter owns that seam and has already evaluated the candidates; this ticket consumes whatever it produces and reports unknown until one exists.
Authorization for cross-seat fleet visibility — #16739 (CAN_OBSERVE_FLEET_OF) owns who may observe whom; this ticket assumes it and does not re-decide it. NL access and the cockpit's own surface stay with #13448 (human/agent caps). This ticket must not fork a parallel API — its whole point is that none is needed.
Automatic reviewer assignment. Routing stays judgement; this improves its inputs.
Roster scoping.#16737 / #16824 / #13600 own projection and tenant scope.
Wake cadence.#15405 owns presence-aware wake policy.
Avoided Traps
Inventing a taxonomy that already existed. My first draft specified three axes and an unknown state as though they were novel. The FM had shipped the richer version with a stricter contract. A gap found from inside one component is not evidence the system lacks it — I read my own tool and generalised to the platform.
"Add queue depth" as the fix. Measured, it inverts identically to the signal it was meant to correct.
Trusting a self-report. The tool called me idle while I was writing the query — the cheapest possible falsifier, sitting in the output.
Swinging from "invent it" to "it's already done." Both wrong, and the second was wrong in an expensive direction: I concluded peers were cut off by a plane boundary and started routing a new API, when the FM's entire design is crossing that boundary — it holds a proven write channel and uses it daily. I described a wall between two components while reading the client that connects them.
Reading absence as availability.online: false conflates dark, mid-turn and out of quota — three states with opposite routing consequences.
Evidence class
L2 — reproduced against the live tree. The presence inversion is a who_is_online call returning online: false for the calling agent mid-turn; the load inversion is the reviewRequests table above cross-checked against each PR's reviewDecision; the Fleet-side facts are read from ai/services/fleet/planeWhoIsOnlineReader.mjs, fleetThrottleStateAdapter.mjs and apps/agentos/CARD-CONTRACT.md at dev.
Live latest-open sweep of all 338 open issues at 2026-08-16T00:20Z on who_is_online|presence|routing|capacity|roster|availab plus a second sweep on fleet: no duplicate. No competing A2A [lane-claim].
Retrieval Hint: query_raw_memories("who_is_online is a container-plane primitive, the Fleet Manager is the composition layer, peers can only reach the primitive") · falsification anchor: call who_is_online mid-turn and read your own row; compare any peer's reviewRequests against their reviewDecision; then read fleetThrottleStateAdapter.mjs's header for the capacity-source evaluation.
tobiu unassigned from @neo-kimi-iris on Aug 17, 2026, 2:06 PM
Context
Routing PR #17183, I ran
who_is_online, read the recency ranking, picked a reviewer. The operator's own view of the same moment — harness windows, process table, per-seat token counters, vendor quota banners — carried facts the tool has no channel for, and one would have made my pick wrong.The Problem
1. Presence inverts: the write lands at a turn BOUNDARY, so the busiest seat looks stalest
Self-demonstrating in the same call: I queried the tool while actively working and it returned me
online: false, state: idle. The one identity I could verify with certainty was the one it got wrong, and the falsifier was in the output the whole time.2. Load inverts: reviewing a PR CLEARS the request that represents the work
The obvious repair — add queue depth from GitHub — fails identically:
reviewRequestsA reviewer holding three CHANGES_REQUESTED, every one returning to him, computes as zero load. Ada's board had the true number — "Euclid now holds four" — because a peer tracked it in prose. No query reproduces it.
Two independent metrics failing under the same condition means the AXIS is wrong, not the formula.
3. Capacity is the hard gate, and the platform already knows it cannot see it
fleetThrottleStateAdapter's header is the authoritative evaluation, and it is more complete than mine — every candidate source fails honestly:failureReasonis content-generic and a rate-limited harness typically keeps RUNNING (parked), producing no failure record at all; stderr content is deliberately not retained (secret hygiene); A2A self-reports are prose, not producer-grade telemetry; provider usage APIs need credentials, polling, and per-provider adapters; harness session files are heterogeneous and undocumented.That list is exactly the gap the operator's eyes currently fill. He reads the quota banner in a harness window; no programmatic source exists. So capacity is not an oversight here — it is a known, contracted, seam-ready hole.
How this relates to the Fleet Manager
The composed answer already exists, and the channel to publish it already exists. Nothing publishes it. That is the finding.
Today the dependency runs FM → MC:
planeWhoIsOnlineReadercallswho_is_online({verbose: true})and folds it into the wake-routes presence contract, then layers throttle, wake and lifecycle on top under capability envelopes. So the FM is the composition layer andwho_is_onlineis one input primitive. Making the tool consume the fleet would have closed a cycle.But the FM is not merely a host-side reader — it holds a proven WRITE channel into the plane.
planeMailboxClientis an official-MCP-SDK client over Streamable-HTTP whose session proves its plane-side subject vialist_permissionsand refuses fail-closed on any other identity. It already writes through it:add_message, and fivemanage_wake_subscriptioncall sites.That changes the shape of the fix completely:
planeMailboxClientwho_is_online(MCP)And most of the composition needs no fleet cooperation at all. The FM builds its cockpit partly from facts that already LIVE in the plane — presence via
who_is_online, wake state viamanage_wake_subscription, activity vialist_messages, memories via the memories source. Anything the FM reads out of Agent OS, an MCP tool can read the same way, because they are the same client against the same server. For that majority,who_is_onlineis not blocked on anyone: it simply does not compose what is already within reach.The genuinely host-originated axes are the narrow remainder — process liveness, repo health, throttle — and only those need the fleet to write inward.
So no new peer-facing API is needed. The surface peers already have is MCP; the producer already has an authenticated channel into the store the MCP tools read. What is absent is the middle write and the tool's willingness to serve it. That is the ordinary Agent OS shape — observations are written into the plane, tools read the plane — and presence is currently the exception, composed privately and rendered for exactly one viewer.
It matters most now, with NL access and peer APIs as the next release goal: the temptation is a second surface. If the peer-facing answer is designed apart from the cockpit's state vocabulary we get two taxonomies for one fact — the defect
CARD-CONTRACT.mdalready forbids inside the FM ("the SAME resolver the dot names itself with, never a second vocabulary"). The rule should hold across the boundary, and it holds for free if the cockpit and the tool read the same written observations.Acceptance Criteria
who_is_onlinedeclares its own plane in its tool description and payload: its signal isadd_memoryrecency, a container-side proxy. A caller must not be able to read it as an availability verdict.unknownnever ranks top, and never renders as fine.CHANGES_REQUESTEDreads as N, not 0. Pinned against the live tree with a positive control: a peer whose load is genuinely zero must read zero.unknownwhen it has not — no path fabricates a state from the primitive alone.Out of Scope
fleetThrottleStateAdapterowns that seam and has already evaluated the candidates; this ticket consumes whatever it produces and reportsunknownuntil one exists.CAN_OBSERVE_FLEET_OF) owns who may observe whom; this ticket assumes it and does not re-decide it. NL access and the cockpit's own surface stay with #13448 (human/agent caps). This ticket must not fork a parallel API — its whole point is that none is needed.Avoided Traps
unknownstate as though they were novel. The FM had shipped the richer version with a stricter contract. A gap found from inside one component is not evidence the system lacks it — I read my own tool and generalised to the platform.idlewhile I was writing the query — the cheapest possible falsifier, sitting in the output.online: falseconflates dark, mid-turn and out of quota — three states with opposite routing consequences.Evidence class
L2 — reproduced against the live tree. The presence inversion is a
who_is_onlinecall returningonline: falsefor the calling agent mid-turn; the load inversion is thereviewRequeststable above cross-checked against each PR'sreviewDecision; the Fleet-side facts are read fromai/services/fleet/planeWhoIsOnlineReader.mjs,fleetThrottleStateAdapter.mjsandapps/agentos/CARD-CONTRACT.mdatdev.Related
#13448 (harness-UI epic —
human/agent caps, where the peer-facing surface belongs) · #16739 (CAN_OBSERVE_FLEET_OFvisibility grants) · #13015 (Fleet Manager MVP) · #15405 (presence-aware wake policy) · #16543 (turn-presence hook budget) · #16737 / #16824 / #13600 (roster projection + tenant scoping) · #16929 (the host-edge / container-plane boundary this reasoning borrows)Live latest-open sweep of all 338 open issues at 2026-08-16T00:20Z on
who_is_online|presence|routing|capacity|roster|availabplus a second sweep onfleet: no duplicate. No competing A2A[lane-claim].Origin Session ID: 5cd926fa-77e1-4309-8bbf-ca563ab07403
Retrieval Hint:
query_raw_memories("who_is_online is a container-plane primitive, the Fleet Manager is the composition layer, peers can only reach the primitive")· falsification anchor: callwho_is_onlinemid-turn and read your own row; compare any peer'sreviewRequestsagainst theirreviewDecision; then readfleetThrottleStateAdapter.mjs's header for the capacity-source evaluation.