[ymote]

ADR 0004 §4 promises an agent for every app. A live run on 625d6cc found:

• News ships tools.json (G3) but declares no octos.* and never calls octos, so it had no peer;
• the system agent's peer_list was empty and News's tools never registered;
• Settings › Assistant listed only Rinx;
• the person had nowhere to talk to an app's agent.

Builds on #183 (merged).

Which apps have an agent

This comes from manifests and grants, never names (apps::agent_apps, crates/shell/src/agents.rs):

• a native app granted agent.octos;
• a script app whose manifest declares octos.* or an agent block;
• a script app whose admitted bundle ships tools.json (App Hub's AgentBundle::load).

Settings lists every one of them.

Peers once allowed

• Consent works as before (ADR 0004 §8/§4: approval router, standing rules, shell sheets, first-use consent #120 first use, shell, ai-host: consent turns script-app agents on and turning an agent off revokes it live (G10, G5) [skip ci] #159 revocation). The first use can come from the "Ask " panel, from the app's own octos call, or from the system agent's agents.ask, which shows the first-use sheet over the system chat.
• When the person allows an agent, and at startup for agents already allowed, the shell prepares its peer: contained::prepare → OctosAppService::prepare (new; Broker::bind), i.e. peer/prepare with the tools and generic_tools registered. The system agent's peer_list then shows it, and peer_send_input reaches it.
• Each app has one peer (card.<app id>). The app, its cards, the panel and the system agent all share it.
• The peer is launched with every octos.* service for the shell's panel. The app's own context is still opened with only what its manifest declares, and ContainedOctos still checks declared first.
• The system agent hears about agents it cannot list:
  • a note in front of the system chat's turn whenever the apps' agents changed (the pane and history hide it);
  • host tools agents.list and agents.ask on the system session, answered by the shell.
• Revoking releases the peer and closes the panel's context. The shell refuses peer/input to it, as before.

"Ask "

This is the system chat's pane in app mode (app_chat/, system_chat/view.rs app_panel: true):

• it opens a sharing context with open_conversation;
• it shows both lanes merged, with speakers: "You", "System agent", "'s agent", and "'s agent, to the system agent";
• it has a composer and a Stop button (Peer turn deadlines: expire unanswered prompts, free the turn, Stop on the shared conversation [skip ci] #167, both lanes);
• the app's questions (G11) are shown and answered in the panel; approvals stay on the shell's sheets.

You can open it from:

• the bar's "Ask " beside the focused window's title;
• Shift+F8;
• Setup › Assistant › Ask this app's agent.

On desktop it sits beside the system chat, so both lanes are visible; on phone it is a full-screen sheet.

Tests

• news_is_listed_as_having_an_agent, allowing_an_agent_queues_its_preparation.
• both_lanes_show_with_their_speakers_and_run_in_parallel, the_merged_history_names_its_speakers.
• the_panel_opens_a_sharing_context_and_sends_person_turns_there: consent first, then open_conversation (never a plain context), history, a TurnFrom { Person }, preparation, and revocation. Runs on fake peers.
• the_shell_prepares_a_consented_apps_peer_and_its_panel_shares_it (ai-host).
• real_kernel_an_allowed_apps_agent_is_prepared_listed_and_shares_its_conversation (pinned kernel, scripted model):
  • nothing is prepared before consent, then the peer is prepared once allowed;
  • the system agent's peer_list shows os-news-…;
  • the panel's person turn runs in the person's lane;
  • the system agent's peer/input turn sees it through the shared history;
  • the peer's turn is offered news_list/news_read;
  • revocation releases the peer.
• the_system_agent_is_told_about_agents_it_cannot_list.

Local checks: shell lib tests (desktop 568, phone 588, with the real kernel), app-peers (incl. real kernel), ai-host (with and without octos-core,llm), kernel, clippy for app-peers and ai-host, cargo check for desktop and phone, native_apps.py --check, setup.py --check --cargo. I also ran a hidden-window desktop pass against a scripted model: the bar showed "Ask News", the first-use sheet appeared, the panel reached "ready", it answered with speakers, and it sat side by side with the system chat.

Known limits (also in ADR 0004's follow-ups)

• A native app's peer exists only while the app is open (Rinx needs its signed-in account).
• A script app's person turns carry its app id as the kernel's speaker label (the peer name is kept for resume). The panel shows "You".
• Prepared peers hold a kernel connection, so the kernel's idle stop waits for them.
• A script app's agent cannot ask the person questions yet. App Hub offers a contained app's agent no octos kernel tool (HostLimits::offered_tools), so an admitted manifest cannot list ask_user_question in agent.tools (found by test: the two-lane scenario against the real kernel (and two fixes it found) #182). The panel shows and answers the app's questions once it can. The fix belongs in App Hub (offer ask_user_question to contained agents), not in a shell-side exception.

🤖 Generated with Claude Code