Architecture - relay + sidecar

braXos Composer runs as a split: a cloud-hosted Maestro Relay handles authentication, authorization, and tool projection, while an on-prem-role Composer MCP Sidecar executes connector operations against the customer's systems of record. They communicate over the braXos Orchestrator publish/subscribe bus.

sequenceDiagram
    participant C as MCP Client (Claude)
    participant R as Maestro Relay (cloud)
    participant O as Orchestrator (pub/sub)
    participant S as Composer Sidecar (on-prem)
    participant SoR as System of Record

    C->>R: MCP call (OAuth-authenticated)
    R->>R: Authn + authz + resolve org
    R->>O: Publish command (T1 publisher token)
    O-->>S: Deliver over subscription (T2)
    S->>SoR: Execute operation (server-side creds)
    SoR-->>S: Result
    S->>O: Publish reply (T3)
    O-->>R: Deliver reply
    R-->>C: MCP result

Why split

• The relay lives in the cloud with the MCP client and owns identity, org isolation, and the projected tool catalog. It never touches customer data directly.
• The sidecar runs where the data is (customer/on-prem), holds the downstream credentials, and executes operations. Data does not have to traverse the model to move between systems (see transient pipelines).

The three-token model

Each organization's relay↔sidecar link uses three Orchestrator tokens:

Token	Role	Where it lives
T1	Relay command publisher	Discovered by the relay from the Keycloak Organization attribute PUBTOKEN (or PUBTOKEN_<instance>)
T2	Sidecar subscriber	Sidecar config; the sidecar connects wss://…/ws/{T2}
T3	Sidecar reply publisher	Sidecar config; replies POST to …/api/reply

The relay auto-discovers T1 per organization from Keycloak, so onboarding a tenant is a matter of provisioning the Orchestrator tenant/channel and writing PUBTOKEN on the org.