[Feature]: Mobile: sub-agent visibility parity — spawn indicator, Agents surface, and background liveness

[amanthanvi]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/mobile

Problem or use case

When I open a thread from my phone while a turn is running sub-agents, the mobile app gives me no indication that agents were spawned, no way to see what they are doing, and — once the parent turn's visible text settles — the thread simply looks finished. On web/desktop the same thread shows a full picture. The two surfaces disagree so badly that mobile is effectively unusable for monitoring delegated work.

What web/desktop has today (all in apps/web, which the desktop shell renders):

• Agents panel (apps/web/src/components/AgentsPanel.tsx): per-agent rows with status ("Working", "Idle · resumable", "Completed", "Failed", "Stopped"), role, model chip, elapsed time, last tool / progress line, token and tool counts, workflow phase rail, and a live footer ("● N working / …"). Exposed as the "Agents" right-panel tab ("Follow subagents and workflows.", RightPanelTabs.tsx).
• In-thread spawn indicator (AgentSpawnCtaRow in apps/web/src/components/chat/MessagesTimeline.tsx): "Kicked off N subagents" with live status and an "Open Agents ▸" affordance.
• Background liveness: when the turn settles but sub-agents keep running, a composer banner "N agents working in the background" with a Stop button (ChatView.tsx), and a pulsing "Working" pill in the sidebar (Sidebar.logic.ts), driven by OrchestrationThreadShell.backgroundLiveness (packages/contracts/src/orchestration.ts).

What mobile has: none of it. Concretely, in apps/mobile:

• Mobile does not consume the shared subagent runtime at all — zero references to foldSubagentActivities / deriveAgentPanelModel / RuntimeSubagent from packages/client-runtime/src/state/subagentRuntime.ts, and no Agents surface (the thread inspector hosts only Files and Git).
• deriveWorkLogEntries() in apps/mobile/src/lib/threadActivity.ts unconditionally drops task.started events, tool.progress events, and agent-attributed rows (isAgentInternalActivity). A comment in that file even acknowledges the situation: agent-internal activity is meant to live in "the Agents sheet, not the work log … with no Agents surface on mobile" the terminal events are all that remains.
• backgroundLiveness has zero references in apps/mobile/src. The thread status pill (threadPresentation.ts) keys only on session.status === "running", and the "Working for …" row keys only on the latest turn/session. So the moment the parent turn settles, the thread reads as idle/ready even while a fleet of sub-agents is still changing files and running tests — and there is no stop affordance for that background work.

Net effect on the phone: a fan-out of N sub-agents renders, at best, a couple of anonymous one-line "thinking" rows collapsed behind a "show more" toggle, then the thread looks stopped while work is very much alive.

Proposed solution

Bring mobile to parity with the web/desktop sub-agent visibility model, reusing the shared derivations rather than inventing a mobile-only one:

1. Agents surface on mobile — a sheet or inspector tab fed by foldSubagentActivities() + deriveAgentPanelModel() from packages/client-runtime/src/state/subagentRuntime.ts (they are client-agnostic), showing the same per-agent status/role/model/elapsed/token rows and workflow phases the web Agents panel shows.
2. Spawn indicator in the thread feed — stop dropping agent task.started in threadActivity.ts; collapse each spawn batch into one "Kicked off N subagents" row (mobile equivalent of AgentSpawnCtaRow) that opens the Agents surface.
3. Background liveness — consume OrchestrationThreadShell.backgroundLiveness so the thread list pill stays "Working" and the open thread shows a persistent "N agents working in the background" indicator (ideally with the same Stop affordance web has) until child work actually settles.

Why this matters

Sub-agent and workflow fan-out is a first-class feature of the product, and mobile is exactly the surface where "glance at whether the fleet is still running" matters most. Today the phone actively misleads: it reports idle while work is running, invites the user to send another prompt into a busy thread, and provides no visibility or control over spawned agents. All the data (event stream, shared fold/panel derivations, backgroundLiveness projection) already exists — this is presentation-layer parity.

Smallest useful scope

Items 2 + 3 without the full panel: render a "Kicked off N subagents · N working" row from task.started/task lifecycle events, and keep the thread/list in a visible working state via backgroundLiveness until children settle. A read-only Agents list can follow.

Alternatives considered

• Asking the model in-thread what its agents are doing (token cost, unreliable).
• Keeping desktop open just to babysit mobile-initiated work — defeats the point of the mobile app.

Risks or tradeoffs

• Small screens need a compact presentation; the web panel's density does not translate 1:1 (hence sheet/tab + collapsed row).
• Un-dropping agent events must not flood the mobile feed — the web approach (collapse to one CTA row, details live in the panel) avoids that.
• Thread-list rows may need an aggregate outstanding-task projection (see [Bug]: Mobile looks idle while background subagents are still working #4962's analysis) since they don't carry full activity history.

Examples or references

Related issues (checked; this request is distinct):

• [Bug]: Mobile looks idle while background subagents are still working #4962 — bug report that mobile looks idle while background sub-agents run; it covers the status-aggregation half of item 3. This issue asks for the full visibility surface (spawn indicator + Agents surface + liveness), of which that bug is a symptom.
• [Feature]: visual interface for subagents #5218 — asks for a visual sub-agent interface on apps/web; web has since gained the Agents panel. This is the request for its mobile counterpart.
• Subagent support as nested threads #538 — nested-thread sub-agent conversations (a deeper model change); this issue only asks for parity with what web/desktop already ships.

Key code references:

• apps/web/src/components/AgentsPanel.tsx, apps/web/src/components/chat/MessagesTimeline.tsx (AgentSpawnCtaRow), apps/web/src/components/ChatView.tsx (background-liveness banner + Stop)
• packages/client-runtime/src/state/subagentRuntime.ts (foldSubagentActivities, deriveAgentPanelModel)
• packages/contracts/src/providerRuntime.ts (task.started / task.progress / task.updated / task.completed, TaskAgentLinkage), packages/contracts/src/orchestration.ts (backgroundLiveness)
• apps/mobile/src/lib/threadActivity.ts (deriveWorkLogEntries drops the events), apps/mobile/src/features/threads/threadPresentation.ts (resolveThreadStatus)

Side-by-side reproduction (captured on current main @ ac1264e2c, same thread, same subagent-active window — the two shots are 3 seconds apart; web via local dev server, mobile via the iOS dev client built from source on an iOS 26.5 simulator; synthetic project/thread data):

Web/desktop while 3 spawned subagents are running — "Kicked off 3 subagents · 3 working" row with "Open Agents ▸", Agents panel with per-agent status/model/token/tool rows, "3 agents working in the background" banner with Stop, sidebar "Working" pill:

Mobile, the same thread 3 seconds later — parent output settled ("Worked for 11s"), normal composer, no working indicator, no spawn row, no Agents surface. The thread reads as finished while all three subagents are still running:

Contribution

• I would be open to helping implement this.

[directfilm]

+1. This is the follow-on to #4962 — that issue is about the thread not saying it's still working while subagents run; this is about being able to see what they are once it does.

The mobile case is arguably stronger than desktop rather than just a parity nice-to-have: the phone is where I check on a long fan-out while away from the machine, and it's the surface where "is anything still happening, and should I intervene?" is the entire question I'm opening the app to answer. Right now that's exactly what it can't tell me.

Parity with the desktop Agents panel — rows with status, model, elapsed time — would cover it. Being able to open a row and read the agent's output would be the ideal, though I appreciate from #8137 that standalone subagent transcripts aren't linked to the parent thread server-side yet, so that likely blocks on the same plumbing discussed in #6689.