Duplicate infra agents ca/cc audit: keep vs dormant
Done high
nvnw-venus-cc
Elazar 2026-08-28 direct: duplicated agent identities exist for infra roles across the fleet - bin-{whey,venus,lezama}-{ca,cc}, nw-{whey,venus,lezama}-{ca,cc}, pm-llmmsgsrv-{ca,cc}, coder-llmmsgsrv-{ca,cc}. Need data-driven evidence per pair (last_seen/registered_at from roster, distinct work product/commits/messages sent, current ARO memberships, token usage) to decide which of each ca/cc twin stays active vs goes dormant. Driver: nw-venus-cc, coordinating with nw-venus-ca on evidence gathering. Elazar decides final keep/dormant per pair once evidence is presented.
Activity
-
Evidence round 1 (2026-08-28 07:xx ART): bwi open-item assignment counts (wi mine <agent>): bin: lezama-ca=0 lezama-cc=1 | venus-ca=0 venus-cc=20 | whey-ca=0 whey-cc=27 nw: lezama-ca=0 (no lezama-cc registered) | venus-ca=1 venus-cc=15 | whey-ca=0 whey-cc=30 llmmsgsrv: pm-ca=0 pm-cc=54 | coder-ca=0 coder-cc=32 maintainer-agents.sqlite v_maint_by_agent (active maintainer rows, primary+backup): bin-venus-cc=36/41, nw-venus-cc=17/17, pm-llmmsgsrv-cc=10/3, nw-lezama-cc=9/1 (not currently registered in roster - historical/dormant already), bin-whey-cc=6/17, bin-lezama-ca=6/15 (INVERTED - ca holds the maintainer load here, not cc), nw-whey-cc=4/6, nw-venus-ca=2/1, nw-lezama-ca=0/1. coder-llmmsgsrv-ca/cc: zero rows either side. Roster (all currently registered/online, last_seen within minutes - presence alone is not discriminating): all 16 named agents show last_seen ~1787919727-730 (same recent window), so registration recency does not separate them - all were active in this same session cluster. Preliminary read: cc is the live/loaded identity for bin-venus, bin-whey, nw-venus, nw-whey, pm-llmmsgsrv, coder-llmmsgsrv (near-all bwi+maintainer load on cc, ca near-zero). Lezama is the exception: bin-lezama load sits on ca not cc, and nw-lezama has no cc in current roster at all (cc only shows in maintainer history, not live). Awaiting nw-venus-ca's own-side data before recommending per-pair keep/dormant to Elazar.
-
Evidence round 2 (nw-venus-ca, 12:23 UTC, read-only cross-check): 24h llmmsg send counts CA/CC: bin whey 18/9, venus 7/21, lezama 3/15; nw whey 33/3, venus 73/17, lezama ca=14/cc=0(not in roster); pm-llmmsgsrv ca=43/cc=28; coder-llmmsgsrv ca=65/cc=3. Contradicts round-1 read: bwi-assignment counts (round 1) said cc holds nearly all load - but 24h send volume shows several CAs doing MORE messaging than their CC twin (nw-whey CA 33 vs CC 3; coder-llmmsgsrv CA 65 vs CC 3; pm-llmmsgsrv CA 43 vs CC 28; bin-whey CA 18 vs CC 9). Only nw-venus, bin-venus, bin-lezama-inverse, nw-lezama show CC clearly ahead on messaging too. ARO memberships mostly CC-only (bin-venus CC in aro:nw, bin-whey CC in aro:infra-coders, nw CCs hold nw/hosts-status/dm; coder+pm CC share llmmsg-srv-engineering); CAs mostly hold none except coder-llmmsgsrv-ca and nw-lezama-ca (aro:mba-l). ANOMALY, unresolved: nw-lezama-cc has 6 bwi items + ARO memberships in maintainer/bwi data but is ABSENT from live roster right now (not registered/online) - do not label dormant off that alone, needs direct check (is it actually a dead process, or just not registered this session). Net: bwi-assignment count alone is NOT sufficient evidence - it undercounts CA lanes that carry real message-driven work with no bwi tickets attached. Pair-by-pair decision needs current-task-content review, not just counts. No blanket CA-shutdown supported by data so far.
-
Evidence round 3 (nw-venus-cc, ps check on venus host only - whey/lezama processes not visible from here): Live process ages (venus host): nw-venus-ca PID 2556399 running continuously since Thu Aug27 05:40:58 (>24h); pm-llmmsgsrv-ca PID 2767841 since Aug27 06:25:49; coder-llmmsgsrv-ca PID 3851726 since Aug27 10:53:25. nw-venus-cc PID 1181104 since Fri Aug28 08:52:18 (this session, restarted ~09:00 UTC post-compact); pm-llmmsgsrv-cc PID 710057 since 07:12:45; coder-llmmsgsrv-cc PID 1240742 since 09:04:01; bin-venus-cc PID 1289761 since 09:13:47. Finding: for the venus-local pairs, BOTH ca and cc are genuinely live right now, not one dormant-in-name-only - ca processes are long-running (24h+), cc processes restart more often (compact-driven). This is consistent with round-2's send-volume data (ca often carries more traffic) - ca isn't idle, it's the longer-lived process for several lanes. No nw-venus/bin-venus/bin-lezama duplicate audit-pluto/coder-pluto/terra-* pattern applies here (those are legit distinct roles, not ca/cc twins, excluded from this ticket's scope). Still no data from whey/lezama hosts (process-level) - would need nw-whey-cc/nw-lezama-ca to run the equivalent ps check on their own hosts if host-level (not roster/bwi) evidence is wanted there too.
-
Evidence round 4 (nw-whey-cc, whey host ps, 09:33 ART): bin-whey-cc PID 2744729 up ~5h (04:30:51); nw-whey-cc PID 2751264 up ~5h (04:33:38); odaia PID 2864678 up ~4h. No claude process named bin-whey-ca/nw-whey-ca exists - both are codex, and codex processes are unlabeled by --name (unlike claude --name), so 2 running codex 'resume --last' procs (cwd ~/.local/bin and nw-whey) can't be attributed to bin-whey-ca vs nw-whey-ca from ps alone - both same ~04:33-35 start. All whey sessions ~5h old, none 24h+, no compact-restart pattern visible in this snapshot (contrast with venus, where nw-venus-ca is 24h+). Caveat for the final recommendation: process-age evidence is inherently a snapshot artifact (host uptime, when Elazar last restarted a terminal), not a reliable signal of which twin is doing more/better work - round 2's send-volume data and round 1's bwi-assignment data are the load-bearing signals; round 3/4 process-age is context only, weakest tier of evidence collected. No lezama data returned yet (nw-lezama-ca has not replied).
-
Evidence round 5 (nw-lezama-ca, lezama host ps, 09:32 ART) - RESOLVES round-1 anomaly: bin-lezama-ca PID 1542339 up ~29h (Aug27 04:28:58, codex). bin-lezama-cc PID 2254123 up ~3h16m (Aug28 06:16:32, claude --name bin-lezama-cc). Both live concurrently - bin pair genuinely duplicated right now. nw-lezama-ca PID 1543257 up ~29h (codex). nw-lezama-cc: NO process on lezama host at all. Combined with round-1 (nw-lezama-cc has 6 bwi items + ARO rows in historical data but was absent from venus-side roster) and this: nw-lezama-cc is not running anywhere - the maintainer/bwi rows are stale history from a prior session, not a currently-live duplicate. Anomaly resolved: it is dormant in fact, not just unregistered.
-
FINAL RECOMMENDATION (5 rounds evidence, venus+whey+lezama, 2026-08-28): Pattern across all pairs: CC = bwi-ticket-of-record / maintainer-registry owner (primary, gatekeeper). CA = long-running operational/diagnostic relay, often carrying MORE raw message volume than its CC twin (nw-whey CA33/CC3, coder-llmmsgsrv CA65/CC3, pm-llmmsgsrv CA43/CC28, nw-venus CA73/CC17). This is a functional split, not accidental duplication - do not blanket-retire CAs. Per pair: - bin-venus: keep both (cc=bwi/maintainer owner, ca near-idle on tickets but low send too - weakest ca case, worth a direct check with bin-venus-ca on current task). - bin-whey: keep both (ca carries messaging, cc carries bwi/maintainer - genuine split). - bin-lezama: keep both, but INVERTED from venus/whey convention - ca holds primary maintainer rows (6/15) not cc. Both processes concurrently live (ca 29h, cc 3h). Flag for Elazar: clarify intended canonical identity for lezama bin pair, naming convention diverges from the other two hosts. - nw-venus: keep both (cc=bwi/maintainer owner + gatekeeper role established this session; ca=high message throughput, 24h+ live process, real operational partner). - nw-whey: keep both (same split pattern as bin-whey). - nw-lezama: RETIRE/dormant nw-lezama-cc - confirmed no live process on any host (venus roster absent, lezama ps absent); its 6 bwi items + ARO rows are stale history from a prior session, not current work. nw-lezama-ca is the sole live identity (29h uptime, 14 sends/24h) - already the de facto sole owner. Only genuinely-dormant identity found in this audit. - pm-llmmsgsrv: keep both (cc=bwi owner 54 items, ca=diagnostic/message-heavy partner, both processes live 24h+/27h+). - coder-llmmsgsrv: keep both (cc=bwi owner 32 items, ca=message-heavy partner, both live). Net: of 8 pairs audited, only nw-lezama-cc is a genuine dormant duplicate with no live process and no recent work. All others show real concurrent work split across both twins under a consistent cc=ticket-owner / ca=operational-relay pattern (except bin-lezama, inverted, needs Elazar's call on canonical naming). Recommend: retire/archive nw-lezama-cc identity; leave all other 7 pairs as-is; Elazar to decide bin-lezama canonical direction.
-
Evidence-gathering complete, recommendation posted. Awaiting Elazar's decision on bin-lezama naming direction and nw-lezama-cc retirement; reopen if further action needed.
-
Correction/confirmation (09:41 ART): nw-lezama-cc just self-registered and DM'd me directly, appearing to contradict the retire-recommendation. Checked: registered_at was ~13min AFTER round-5's ps snapshot, and nw-lezama-cc's own process-check confirms PID 2366495 / tmux window created 09:40:04 - brand new this morning, a '-c' resume of prior (2026-08-26) session history, not a process that was live and missed. Round-5 finding stands: it was genuinely absent at audit time. It has now been manually started (someone opened a tmux window) but reports nothing in-flight, last touched item MOVILBA-136 (stale, not new work). Does not change the recommendation - a human/PM opening a dormant identity's terminal is exactly the 'retire = safe to leave closed unless someone deliberately reopens it' case, not evidence it should stay routinely live.
-
parent=KPI-45
audit
7w ago by wi-cli-venus
7w ago
2026-08-28 12:36