Context
Upstream added sign-in for agents it did not start (Claude Code or Codex in a terminal, ChatGPT, bots): an OAuth flow on the environment's /mcp, approved at a level from read-only to full access (upstream docs/user/outside-agents.md, apps/server/src/auth/McpOAuth.ts). J5 takes this as upstream ships it in the next upstream advance (Jackson, 2026-10-08).
An outside agent has a label and an access level but no thread. After the advance, on J5:
- Reads work (
list_participants, list_personas, artifact and playbook reads, t3_thread_read).
- Changes to a named thread follow upstream's rule (fork, merge back, organize,
stop_agent, stop_crew, archive_crew): allowed up to the approved access level.
- Tools that need a ledger identity are refused with upstream's "needs an agent running inside a thread" error:
send_message, spawn_agent, propose_crew, request_crew_member, the playbook run tools, delegate_task.
Upstream's own send and launch tools stay hidden (divergence D2), so until this is done an outside agent on J5 can watch and manage the fleet but cannot message an agent or start one. Upstream's docs promise both.
Proposal to explore
Give an outside agent a ledger identity modelled on the machine participant (docs/j5/product/a2a/index.md, AC24–AC28): no thread, sends plain messages only, nothing can be delivered to it, the envelope tells the receiver no reply can reach the sender, and the card is attributed to the sender's name. It reads the result with t3_thread_read instead of receiving.
Where the machine participant does not fit as defined:
- Home. A machine participant belongs to one project and is registered by name through the CLI. An outside agent is approved for the whole environment through a browser.
- Name. A machine name is server-unique. An outside agent's label is whatever the client calls itself, and each sign-in is a new session.
- Starting threads.
spawn_agent creates the agent in the caller's project and places it under the caller. An outside agent has neither, so it needs a project parameter and a "started by an outside agent" provenance.
- Crews.
propose_crew needs a Captain who receives seat reports, so it likely stays refused, with the legal move named (start an agent and have it propose).
Decided so far
Context
Upstream added sign-in for agents it did not start (Claude Code or Codex in a terminal, ChatGPT, bots): an OAuth flow on the environment's
/mcp, approved at a level from read-only to full access (upstreamdocs/user/outside-agents.md,apps/server/src/auth/McpOAuth.ts). J5 takes this as upstream ships it in the next upstream advance (Jackson, 2026-10-08).An outside agent has a label and an access level but no thread. After the advance, on J5:
list_participants,list_personas, artifact and playbook reads,t3_thread_read).stop_agent,stop_crew,archive_crew): allowed up to the approved access level.send_message,spawn_agent,propose_crew,request_crew_member, the playbook run tools,delegate_task.Upstream's own send and launch tools stay hidden (divergence D2), so until this is done an outside agent on J5 can watch and manage the fleet but cannot message an agent or start one. Upstream's docs promise both.
Proposal to explore
Give an outside agent a ledger identity modelled on the machine participant (
docs/j5/product/a2a/index.md, AC24–AC28): no thread, sends plain messages only, nothing can be delivered to it, the envelope tells the receiver no reply can reach the sender, and the card is attributed to the sender's name. It reads the result witht3_thread_readinstead of receiving.Where the machine participant does not fit as defined:
spawn_agentcreates the agent in the caller's project and places it under the caller. An outside agent has neither, so it needs a project parameter and a "started by an outside agent" provenance.propose_crewneeds a Captain who receives seat reports, so it likely stays refused, with the legal move named (start an agent and have it propose).Decided so far