Real-Time Media ConductorExtend · Implementation
Current integration catalog
Find the implementations that exist today, their contracts, and the host code that registers them.
This is a source catalog of the integrations already in the repository. It helps a team find the right starting point. It is not an installation service, and a listed descriptor does not mean the integration is configured in every running server.
Find an implementation
| Integration | Primary contract | Use it for | Start with |
|---|---|---|---|
| Deterministic adapter | DelegationAdapter |
Credential-free task plumbing and reproducible examples | Implementation |
| OpenAI Responses | DelegationAdapter with prepared-context support |
The current OpenAI-backed background reasoning path | Implementation |
| HTTP reasoner | DelegationAdapter |
A service implementing the example reasoner/0.1 exchange |
Adapter, tests |
| Text fallback room agent | RoomAgent |
Event-driven replies on the demo's text channel | Implementation |
| LiveKit | MediaAdapter and lifecycle/presence interfaces |
Current camera/screen-share setup and provider coordination | Implementation |
| OpenAI Realtime | VoiceAdapter |
Current native voice, sideband events, and voice controls | Implementation |
| Vision processor | Purpose-built external service | Assigned LiveKit tracks, local Apple Vision, and structured observations | Service guide |
| Northwind tools | ToolHandler |
Concrete catalog, weather, and scenario operations | Capabilities, bundle |
| Message statistics example | RoomAgent |
A minimal authored extension with no provider | Run the example |
The vision service is not an installed Go adapter. Its example-specific assignment API and native dependencies are part of that integration's deployment. Similarly, scenario tools are registered by the scenario composition; a room's scenario_id alone does not install them in the standalone server.
Understand registration and routing
The host registers requested-work adapters with Registry.RegisterAdapter, event-driven agents with RegisterRoomAgent, and named tools with RegisterTool. Media and voice adapters are supplied separately to the HTTP server with WithMediaAdapter and WithVoiceAdapter.
For delegations, the registry selects an adapter matching all requested capabilities, then prefers lower numeric priority and uses ID as a tie-breaker. It does not evaluate language, region, price, health, or measured quality. Matching a capability means the host registered that claim; it is not a certification result.
Read registry.go, standalone wiring, and demo wiring. Runtime topology is a basic authorized inventory of what was wired, not a marketplace control plane.
Read descriptor versions carefully
Current version values have different meanings. The LiveKit descriptor reports 1; the HTTP reasoner reports reasoner/0.1; the Realtime adapter reports its configured model. These strings are useful identity metadata, but the registry does not enforce one shared package-compatibility scheme.
For reuse, record both the package/source revision and the RMC contract revision tested with it. Do not infer that two entries with similar version strings can replace each other. The semantic boundary and media dependency page identify the behavior that a replacement must preserve.
Choose the right starting point
For a new external reasoner, study the HTTP adapter's correlation checks, response bounds, and cancellation before adding a new protocol. For an event reaction, run the minimal room-agent example. For a tool, start with the descriptor and direct invocation behavior, including any required confirmation.
For another media provider, plan both server and client work. A Go adapter implementing credential issuance alone does not replace the browser's native transport or the processor's track handling.
To make one of these integrations reusable by another team, fill in the entry template and link its example and validation. The adapter marketplace proposal builds on that documentation practice.