Summary
The orchestrator agent picker currently lets users switch to agents even when AO does not know whether that agent is installed or authenticated. That creates a
broken switch flow:
if the agent is not installed, it should not be selectable as a runnable orchestrator target
if the agent is installed but not authenticated, should not be selectable as a runnable orchestrator target
if switching triggers the agent’s own login/bootstrap flow, that can spawn a fresh session outside AO’s normal orchestrator startup path, so the replacement
session may miss AO’s system prompt / expected initialization
This means the settings UI can present options that are not actually safe to switch to.
Problem
Today the user can pick an orchestrator agent without a reliable preflight check for:
supported by AO
installed locally
authenticated / ready to run
That leads to two bad outcomes:
The agent still appears in the switcher.
The user can save and attempt a restart.
Restart then fails late instead of the UI blocking the choice up front.
The switch is allowed.
The agent may prompt for login during startup.
That login flow can create a new session/process that AO did not initialize the normal way.
The resulting session may not receive AO’s system prompt and expected orchestrator bootstrap.
Expected behavior
The switcher should only present agents in states the user can act on clearly.
Unsupported or unavailable agents should not look like normal selectable options.
If an agent is not installed, the UI should show that state and block switching.
If an agent is not authenticated, the UI should show that state before save/restart, not only after failure.
AO should only cut over to a new orchestrator when the target agent is actually ready to launch through AO’s normal startup path.
Why this matters
This is not just a UX issue. It can produce orchestrator sessions that start outside AO’s intended initialization path, which risks missing the system prompt
and breaking orchestrator behavior in subtle ways.
Acceptance criteria
Agent catalog API exposes per-agent readiness state: supported, installed, authenticated.
Project Settings uses that catalog instead of treating every known agent as equally selectable.
Uninstalled agents are not shown as normal switch targets, or are visibly disabled with an install-required reason.
Installed but unauthenticated agents are clearly marked before switching.
Save/restart is blocked unless the selected orchestrator agent is runnable through AO.
Switching cannot fall into an external login/bootstrap path that bypasses AO’s normal orchestrator initialization.
Tests cover:
uninstalled agent
installed but unauthenticated agent
installed and authenticated agent
restart path preserving AO system-prompt initialization
closes #2310
aoagents/ReverbCode#275
Summary
The orchestrator agent picker currently lets users switch to agents even when AO does not know whether that agent is installed or authenticated. That creates a
broken switch flow:
if the agent is not installed, it should not be selectable as a runnable orchestrator target
if the agent is installed but not authenticated, should not be selectable as a runnable orchestrator target
if switching triggers the agent’s own login/bootstrap flow, that can spawn a fresh session outside AO’s normal orchestrator startup path, so the replacement
session may miss AO’s system prompt / expected initialization
This means the settings UI can present options that are not actually safe to switch to.
Problem
Today the user can pick an orchestrator agent without a reliable preflight check for:
supported by AO
installed locally
authenticated / ready to run
That leads to two bad outcomes:
The agent still appears in the switcher.
The user can save and attempt a restart.
Restart then fails late instead of the UI blocking the choice up front.
The switch is allowed.
The agent may prompt for login during startup.
That login flow can create a new session/process that AO did not initialize the normal way.
The resulting session may not receive AO’s system prompt and expected orchestrator bootstrap.
Expected behavior
The switcher should only present agents in states the user can act on clearly.
Unsupported or unavailable agents should not look like normal selectable options.
If an agent is not installed, the UI should show that state and block switching.
If an agent is not authenticated, the UI should show that state before save/restart, not only after failure.
AO should only cut over to a new orchestrator when the target agent is actually ready to launch through AO’s normal startup path.
Why this matters
This is not just a UX issue. It can produce orchestrator sessions that start outside AO’s intended initialization path, which risks missing the system prompt
and breaking orchestrator behavior in subtle ways.
Acceptance criteria
Agent catalog API exposes per-agent readiness state: supported, installed, authenticated.
Project Settings uses that catalog instead of treating every known agent as equally selectable.
Uninstalled agents are not shown as normal switch targets, or are visibly disabled with an install-required reason.
Installed but unauthenticated agents are clearly marked before switching.
Save/restart is blocked unless the selected orchestrator agent is runnable through AO.
Switching cannot fall into an external login/bootstrap path that bypasses AO’s normal orchestrator initialization.
Tests cover:
uninstalled agent
installed but unauthenticated agent
installed and authenticated agent
restart path preserving AO system-prompt initialization
closes #2310
aoagents/ReverbCode#275