review · segments

Untitled session

claude 61 events 1 segments master

segment 1 of 1

Assess feasibility of flower proxying Solo tool calls for remote agents

Done

Systematically investigated the Solo HTTP API surface (39 endpoints), solo-cli interface, flower's existing Solo integration (SoloClient, SoloAgentToolService, dispatch/spawn services), and the critical attribution question. Found that while flower's MCP is already web-reachable and SoloClient shells solo-cli for stateless writes, the Solo HTTP API does not accept an actor/on-behalf parameter in any write endpoint, so every proxied write collapses to flower's HTTP-API identity. Coordination primitives (locks, kv, timers, PTY input) are MCP-only and absent from HTTP API entirely. Concluded proxy is only worth building if soft/cosmetic attribution is acceptable.

outcome

A structured verdict and report delivered via StructuredOutput, concluding that a faithful proxy is not feasible due to attribution constraints.

next steps

—

key decisions

Attribution is make-or-break: Solo HTTP API stamps createdByActorId/Name from the bearer token, no write endpoint accepts an actor parameter.
Process input and coordination primitives (locks, kv, timers) are MCP-only, absent from the HTTP API, so not proxyable via flower's web MCP.
Flower's MCP is already web-reachable via Mcp::web('/mcp'), and SoloClient already wraps solo-cli for projects/processes/todos/scratchpads.
Proxy worth building only if soft attribution (embedding actor_ref in content body) is acceptable; cannot faithfully proxy actor-scoped operations.

open questions

—

20 hours ago → 19 hours ago