Client-executed tools: the agent's eyes and hands (v1.16.0 to v1.16.1)

LoomCycle released v1.16.0-1.16.1 of its agent runtime, inverting tool execution so clients (browser, IDE, mobile) register tools via WebSocket and run them locally when the agent calls. The update fixes a naming issue where colons in tool names were rejected by Anthropic, OpenAI, and Ollama, and LoomBoard's Chrome extension is the first adopter with browser automation tools.

RFC BC inverts the tool-execution direction. A client browser, IDE, mobile app opens a WebSocket to the runtime and registers its own tools. When the agent calls one, the runtime routes the invoke over the socket to the connected client; the client runs the tool locally and returns the result. Four layers: a transport-agnostic registry invoke↔result correlation, per-principal connection map, per-key connection cap, delegate-and-block Invoke , a bearer-authed GET /v1/client-tools WebSocket endpoint bearer rides Sec-WebSocket-Protocol because browsers can't set Authorization on a WS handshake , dispatch through client -prefixed advertised tools grants gated by tools: allowlist globs , and a TypeScript connectClientTools helper in @loomcycle/client that auto-reconnects. v1.16.1 fixes the wire-safe name client: to client because Anthropic, OpenAI, and Ollama all reject colons in tool names, so v1.16.0 was uncallable end-to-end until the rename. LoomBoard's Chrome side-panel extension is the first customer, migrating from a channel-bridge to RFC BC in the same three-day window with browser read page, fill, click, and navigate tools plus a Confirm-vs-Auto approval bar.