feat: expose swarm agent identity and execution state

[marius-kilocode]

What Problem This Solves

Shared-board participants previously appeared as generic agent types or session IDs. This made same-type workers difficult to distinguish and made it unclear who sent a message to whom. Successful posts also did not consistently distinguish finished recipients from recipients whose availability was unknown.

Closes #13670. Part of #13673, built on the merged prototype in #13629.

Why This Change Was Made

Use existing session titles as display labels and keep session IDs as routing keys. Titles, including legitimate parentheses and suffixes, are preserved. There is no separate naming registry, duplicated assignment field, or copy of the full task prompt.

Execution information comes from the existing directory-scoped Task job and session-status services. A finished invocation is not inferred from idle state, and missing runtime metadata remains unknown after restart. Availability is a timestamped observation at the post attempt, not a live status or delivery guarantee.

The roster prioritizes the root, reader, and recently active members while retaining the 50-member and 32 KiB response bounds. Title lookup does not depend on which members fit in that roster. Queries retain project/directory isolation; active priorities are materialized once, and posting uses indexed title lookups for already validated endpoints rather than scanning history under the writer lock.

The contract remains compatible with existing records: participant metadata adds sessionID, optional agent, and state; reads expose the observation time and roster truncation; messages carry optional fromLabel/toLabel; post metadata includes from and an availability snapshot with observedAt, total, active, inactive, and unknown counts. No database schema or server endpoint changes are required.

User Impact

• Agent-facing rosters and user-facing communication routes use the same existing titles.
• Posts show a sender-to-recipient route and the message body once. Each message in a board read has its own route. Agent-facing protocol codes such as INFO and RESULT remain in tool data but are not shown on the cards.
• Existing subagent icons distinguish communication from task creation. Broadcasts show paired icons and “All agents.”
• Narrow views use two-line routes; long names truncate with full available titles and routing IDs in tooltips.
• Older records without titles retain ID fallbacks. “Primary agent” is only a fallback; a supplied title such as main is preserved.
• All seven new UI labels are present in all 28 supported locales.
• Directed posts and broadcasts report known finished recipients or unknown availability, excluding the sender. Self-posts and broadcasts with no other recipients do not emit an inactive-recipient warning. The stored-only disclaimer remains. Posts do not wake agents or change creation, resumption, cancellation, or permission behavior.

Evidence

81 focused tests passed: 69 board/store/context/Task regressions, the existing real Task-runtime board scenario, and 11 tool-display tests. After rebasing onto current main, the exact CI command bun turbo typecheck --filter='!@kilocode/kilo-jetbrains' passed all 29 tasks. The notification test fixture now provides the required job/status services, and replay assertions compare stable history and cursors rather than the changing observation time. Extension compilation, focused lint, Knip, annotation checks, marker checks, and whitespace checks passed. Lint retains pre-existing warnings. Locale coverage and {{from}}/{{to}} placeholders were checked across all 28 dictionaries.

The local compile succeeded using the existing active-Bun fallback after the pinned bunx launcher failed. Local validation used Bun 1.4.0-canary and SQLite 3.51.0.

Latest screenshots

Updated from the rebased build in isolated VS Code on September 3, with protocol-code badges removed. These use synthetic message records, not a live-provider conversation. The captures were cropped and checked for private data; media is hosted separately and is not included in the code diff.

Reading directed and broadcast messages, wide layout

Posting a message

Narrow layout and long-title tooltip

Visual checks covered narrow and wide layouts, long titles, broadcasts, legacy fallbacks, and supplied main titles. Light, dark, and both high-contrast themes were exercised during implementation. Isolated test instances were cleaned up.

Scoped query-cost verification

An equivalent-result native SQLite comparison checked the initial correlated lookup against the final indexed approach. These are synthetic query measurements within this implementation, not a speedup claim against the prototype or end-to-end UI latency.

Descendants / active entries	Roster query before / after	Post-title query before / after
100 / 20	0.211 / 0.147 ms	0.080 / 0.011 ms
5,000 / 1,000	191.026 / 5.559 ms	3.865 / 0.011 ms

Medians of five interleaved runs used identical in-memory data and production index order, including bindings, preparation, materialization/index creation, execution, and finalization. Every run returned identical ordered roster results and title rows. Title queries ran inside BEGIN IMMEDIATE, but measurements exclude transaction boundaries and other post work. The 1,000-active case is a same-directory stress condition, not observed ordinary usage.

Manual Test

1. Start two same-type workers with distinct session titles. Check their roster entries and direct-message routes.
2. Expand a post and a multi-message read. Confirm each body appears once; narrow the panel and hover long names.
3. Broadcast after other invocations finish, then resume a worker and post again. Check the timestamped availability warning without expecting automatic wake-up or a read receipt.
4. Post to self or broadcast with no peers. Confirm no inactive-recipient warning appears, while the stored-only disclaimer remains.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (39 files)

• packages/opencode/src/kilocode/tool/board.ts
• packages/opencode/src/kilocode/board/store.ts
• packages/kilo-ui/src/components/message-part.tsx
• packages/kilo-ui/src/components/basic-tool.css
• packages/kilo-vscode/webview-ui/src/stories/composite.stories.tsx
• packages/opencode/test/kilocode/board-tools.test.ts
• packages/opencode/test/kilocode/board/store.test.ts
• packages/opencode/test/kilocode/board-context.test.ts
• .changeset/swarm-agent-identity.md
• packages/ui/src/i18n/*.ts (28 locales)
• visual regression baselines (2 pngs)

Previous Review Summary (commit 08cbaf1)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 08cbaf1)

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	0
SUGGESTION	1

Issue Details (click to expand)

SUGGESTION

File	Line	Issue
packages/opencode/src/kilocode/tool/board.ts	163	Vacuous "no other recipients were active" warning when availability total is 0 (self-posts)

Files Reviewed (38 files)

• packages/opencode/src/kilocode/tool/board.ts - 1 issue
• packages/opencode/src/kilocode/board/store.ts
• packages/kilo-ui/src/components/message-part.tsx
• packages/kilo-ui/src/components/basic-tool.css
• packages/kilo-vscode/webview-ui/src/stories/composite.stories.tsx
• packages/opencode/test/kilocode/board-tools.test.ts
• packages/opencode/test/kilocode/board/store.test.ts
• .changeset/swarm-agent-identity.md
• packages/ui/src/i18n/*.ts (28 locales)
• visual regression baselines (2 pngs)

Fix these issues in Kilo Cloud

---

_{Reviewed by grok-4.6 · Input: 184.7K · Output: 20.9K · Cached: 1.1M}

_{Review guidance: REVIEW.md from base branch main}