agentic-mobile-control/openspec/changes/cloud-planner-proxy/design.md

Context

The Host Agent's AIPlanner (runtime/ai_planner.py) delegates the actual LLM call to a ToolCallingClient (runtime/tool_calling_client.py): AnthropicToolCallingClient/OpenAIToolCallingClient each build a provider SDK client that implicitly reads ANTHROPIC_API_KEY/OPENAI_API_KEY from the Host Agent's own process environment, and build_client() selects between them based on PlannerConfig.provider (from runtime/planner_config.py, itself read from the Host Agent's local env). None of this touches the Cloud Control Plane today.

The Cloud Control Plane (apps/cloud-api + packages/cloud-platform/cloud) already authenticates every Host Agent with a host-scoped bearer credential for heartbeat, claim/long-poll, lease renewal, and terminal result reporting (cloud/internal_api/*), with the Host Agent importing shared Pydantic models directly from cloud.internal_api.models rather than duplicating schemas. Separately, packages/cloud-platform already depends on the root Runtime package (device-agent-runtime, workspace dependency), the same way apps/device-host-agent does -- so cloud-side code can import runtime.tool_calling_client directly instead of reimplementing Anthropic/OpenAI wire-format handling a second time.

A prior change in this session made the Host Agent default AI_PLANNER_ENABLED to on (apps/device-host-agent/host_agent/execution.py). That means every Host Agent now needs a working planner path by default, which raises the stakes on where its provider credentials live.

Goals / Non-Goals

Goals:

• Let an operator configure LLM provider, model, and credentials once, on the Cloud Control Plane, instead of per Host Agent.
• Let a Host Agent execute AI-planned tasks without holding ANTHROPIC_API_KEY/OPENAI_API_KEY locally, by proxying its planner decision calls through the Cloud Control Plane.
• Reuse existing Host<->Cloud authentication and existing provider wire-format code; add no new auth scope and no duplicated Anthropic/OpenAI translation logic.
• Preserve today's direct-to-provider path as a fully supported, still-default option, so existing Host Agent deployments with local keys are unaffected.

Non-Goals:

• Not moving prompt construction (runtime/planner_prompts.py, Scene serialization, world/history summarization) to the cloud. The Host Agent keeps building system_prompt/user_prompt locally; the cloud endpoint is a thin "make this one LLM call and return one tool call" proxy, not a re-implementation of planning.
• Not building per-tenant/per-host provider overrides, usage metering, rate limiting, or a management UI for the proxy. Single cloud-wide provider/model/credential configuration only, matching how AI_PLANNER_* is configured today (env-based, one value cluster).
• Not changing the existing heartbeat/claim/renew/result protocol or its spec (host-agent-protocol).
• Not deprecating or removing the direct-to-provider transport.

Decisions

D1: New endpoint reuses runtime.tool_calling_client server-side instead of reimplementing provider calls

cloud.internal_api adds a route whose handler constructs an AnthropicToolCallingClient/OpenAIToolCallingClient (imported from runtime.tool_calling_client, already an allowed dependency direction since packages/cloud-platform depends on device-agent-runtime) using Cloud-side provider/model/credential configuration, and calls .decide(...) with the request payload. This eliminates a second implementation of Anthropic/OpenAI tool-calling wire-format translation, which ai-planner-runtime/design.md already flagged as a drift risk for the two-provider case -- a four-implementation case (two providers x two transports) would be worse.

Alternative considered: hand-roll a minimal cloud-side Anthropic/OpenAI client in cloud.internal_api. Rejected: duplicates parsing logic (_decision_from_anthropic_response, _decision_from_openai_response) that must stay in lockstep with the Host Agent's local transport as providers' APIs evolve.

D2: New transport axis, orthogonal to provider selection

Host Agent config gains AI_PLANNER_TRANSPORT (direct default | cloud), independent of AI_PLANNER_PROVIDER. direct is today's behavior unchanged (Host Agent builds the SDK client itself). cloud builds a new CloudProxyToolCallingClient instead; provider/model selection and credentials for that path live in the Cloud API's own AI_PLANNER_PROVIDER/AI_PLANNER_MODEL/ANTHROPIC_API_KEY/OPENAI_API_KEY configuration, not the Host Agent's.

Alternative considered: overload AI_PLANNER_PROVIDER=cloud as a third provider value. Rejected: provider and transport are different axes (a cloud transport still ultimately calls anthropic or openai), and conflating them would make the Cloud API's own provider config harder to reason about ("provider" would mean different things on each side).

D3: CloudProxyToolCallingClient lives in host_agent, not runtime

runtime/tool_calling_client.py's ToolCallingClient stays a plain Protocol; the new client is added in apps/device-host-agent/host_agent/ (e.g. host_agent/cloud_planner_client.py) and satisfies that Protocol structurally. This preserves the existing boundary enforced by apps/device-host-agent/tests/test_execution.py::test_runtime_owned_packages_do_not_import_host_or_cloud_concerns, which forbids runtime (and core/device/driver/tools) from importing cloud or host_agent. The new client wraps a new method on the existing host_agent/client.py::HostAgentClient (which already holds the authenticated httpx session and imports cloud.internal_api.models), so it reuses the same request/auth/retry plumbing as heartbeat/claim/renew/result instead of opening a second HTTP client type.

D4: Reuse the existing host-scoped bearer credential; no new auth scope

The new endpoint sits on the same internal router and auth dependency as heartbeat/claim/renew/result. A Host Agent that can already reach the Cloud Control Plane for task assignment can reach the planner-decide endpoint; there is no separate enrollment or credential to provision for this capability.

Alternative considered: a distinct scope/credential just for planner-proxy calls (defense in depth, so a compromised heartbeat credential couldn't run up LLM cost). Rejected for this proposal to keep the change additive and consistent with how the rest of the internal API already treats "any authenticated host" uniformly; revisit if abuse/cost containment becomes a concrete concern (see Open Questions).

D5: Request/response payload mirrors the local ToolCallingClient.decide() signature

The proxy request carries system_prompt, user_prompt, an optional base64 screenshot, the tool specs (already JSON-serializable ToolSpec/dict shapes used to build provider tool schemas), and a timeout. The response carries the resolved tool_name/arguments (or a structured error). This keeps the Host Agent and Cloud Control Plane in the same shape as today's local call, so AIPlanner itself needs zero changes -- only the client it's constructed with changes.

D6: Cloud does not durably persist prompt text or screenshot bytes from proxy requests

The endpoint handler processes the request in memory and returns; only metadata (host id, tool name decided, latency, error class if any) may be logged for observability. This bounds the new sensitive-data surface created by routing screenshots and prompts through the cloud (an accepted trade-off from the earlier feasibility discussion) to "in transit and in process," not "at rest in cloud logs/DB."

D7: Proxy failures surface as ToolCallUnavailable, matching direct-transport failure behavior

Any failure calling the cloud endpoint (network error, auth rejection, non-2xx, provider error surfaced by the cloud side, timeout) raises ToolCallUnavailable from CloudProxyToolCallingClient.decide(), exactly like today's direct-transport failures. This preserves the existing, already-accepted behavior that a planner failure fails the current task step immediately with no silent fallback to the stub planner -- this proposal does not change that risk profile, only where the call happens.

Risks / Trade-offs

• [Risk] Cloud Control Plane is now in the hot path of every planning step for hosts on the cloud transport -> Mitigation: direct transport remains the default and fully supported; operators who need offline/low-latency operation simply don't opt in. Bounded by the existing AI_PLANNER_TIMEOUT_SECONDS, same as today.
• [Risk] Cloud Control Plane outage now stalls planning (not just new task assignment) for opted-in hosts -> Mitigation: same ToolCallUnavailable -> task-fails-fast behavior as any other planner error; no new silent-hang mode. Documented as an explicit trade-off of opting into cloud transport.
• [Risk] Screenshots and prompt text now transit through the Cloud Control Plane -> Mitigation: D6 (no durable persistence); still an expansion of the data path operators should account for versus direct-to-provider, which never touches the cloud.
• [Risk] Cloud API gains a new dependency on anthropic/openai SDKs and becomes a second place holding provider credentials -> Mitigation: reusing runtime.tool_calling_client (D1) keeps this to configuration and routing, not new provider-integration code; credential handling follows the same "environment or secret manager" pattern already documented for the Host Agent in docs/CLOUD_DEPLOYMENT.md.
• [Risk] Any authenticated host can drive cloud-held LLM spend (D4) -> Mitigation: none in this proposal beyond existing per-host authentication; flagged as an Open Question rather than silently accepted, since it's a cost/abuse concern rather than a correctness one.
• [Risk] ai-planner-runtime's accepted spec text ("AI Planner is disabled by default") is already stale relative to the Host Agent's actual default (changed in a prior, separate session change without an openspec artifact) -> Not a risk introduced by this proposal, but this proposal's delta spec is written against that same pending, unarchived agent-runtime capability, so the discrepancy should be reconciled once, when ai-planner-runtime is archived (see Open Questions).

Migration Plan

1. Add Cloud API configuration (AI_PLANNER_PROVIDER/AI_PLANNER_MODEL/ AI_PLANNER_TIMEOUT_SECONDS/provider API keys) and the new internal route, guarded by the existing host-scoped auth. Off by default in the sense that no Host Agent calls it until configured to use cloud transport.
2. Add the Host Agent's AI_PLANNER_TRANSPORT setting (default direct) and CloudProxyToolCallingClient. Existing deployments are unaffected until an operator sets AI_PLANNER_TRANSPORT=cloud and removes the local provider key.
3. Update docs/CLOUD_DEPLOYMENT.md with the proxy configuration path and its trade-offs (latency, availability coupling, data-path expansion).
4. Rollback is setting AI_PLANNER_TRANSPORT=direct (or unsetting it) on affected hosts and restoring their local provider key; the Cloud API route can remain deployed but unused.

Open Questions

• Should planner-proxy calls eventually get their own credential scope separate from heartbeat/claim/renew/result, to bound blast radius and allow independent cost/abuse controls? Deferred; revisit if this becomes a real deployment.
• Should the Cloud API expose any per-request cost/usage observability (e.g. token counts) given it now brokers every LLM call for cloud- transport hosts? Out of scope for this proposal's tasks; worth deciding before recommending cloud transport for cost-sensitive fleets.
• When ai-planner-runtime is archived, its "disabled by default" spec text needs reconciling against both the Host Agent's actual default (from the earlier, separate change) and this proposal's transport addition -- noted here so it isn't lost, matching how edge-host-self-enrollment's design.md tracked its own dependency on an unarchived pending spec.