The contract and the SDKs (Go, TypeScript, Python) are complete. The BMA platform side is deployed with text input only; file inputs are refused explicitly.
By default BMA’s server harness runs every session. With the agent capability, an executor that contains a complete agent (its own model loop and tools, for example a desktop app) serves the sessions instead: BMA delivers each user turn to it, and it streams Managed Agents events back. Clients see the same sessions, the same event log and the same /v1 stream either way.

​
How it fits

​
Bind an agent to an executor

  1. Connect your executor with a machine token and advertise capabilities.agent in executor.register (models, permission modes, interaction kinds, max_sessions). The SDK does this for you with ServeAgent / serveAgent / serve_agent.
  2. Ask the BMA team to bind the BMA agent to that machine: the public /v1 API has no route for the binding yet.
From then on: Input queues while the executor is offline and is delivered when it reconnects.

​
Protocol

The executor stores its local conversation handle in executor_session_ref; BMA sends it back on the next turn.start, so the executor can resume after a restart.

​
What the server harness does that an external brain does not

Context compaction, context_too_large handling, automatic session titles and BMA’s built-in tools belong to the server harness. An external brain manages its own context and tools, and can still use BMA machines through the hand side of the protocol.