Real-Time Media ConductorArchitecture · Design decisions
Adapter marketplace proposal
A proposed distribution path built on explicit contracts, reviewed implementations, and evidence of reuse.
A proposed adapter marketplace would list integrations, their supported contracts, maintainers, and deployment requirements. A reviewed package and service catalog is the initial option. RMC does not have a marketplace installer, plugin sandbox, or dynamic provider-binding control plane today.
The current integration catalog is the starting point: concrete implementations, direct host wiring, and links to their contracts.
Separate discovery from execution
A catalog answers which integration exists, what it does, who maintains it, and what evidence supports its claims. The runtime executes code and enforces the room boundary. Those are different jobs.
Today, an adopting team can review an entry, pin a package revision, configure its external credentials, and register it in the host. The application uses the existing room contract. No discovery service needs to be on the live interaction path.
If installation is added, resolve the selected integration to a reviewed deployment configuration before execution. A model or event requesting a capability must not authorize downloading and running new code.
Give each entry a primary contract
“Adapter” is too broad to be a sufficient compatibility label. A requested-work adapter, room agent, native media integration, and tool differ in their triggers, lifetimes, and permissions.
| An entry should explain | Why the adopting team needs it |
|---|---|
| Primary runtime contract and capabilities | Which operation the integration actually implements |
| Package version and tested RMC revision | Which code and behavior were validated together |
| Input/output schemas and examples | How the application interprets the result |
| Required grants and data sent externally | What authority and context the integration needs |
| Provider/service dependencies and secret configuration | What must exist at deployment time |
| Timeouts, cancellation, retries, and restart behavior | What happens when work is slow, duplicated, or interrupted |
| Maintainer, support route, and deprecation policy | Who handles failures and compatibility changes |
| Validation evidence | Which claims were exercised, and which remain untested |
Use the catalog-entry template. It is a documentation template, not a manifest consumed by RMC.
Define capability behavior
The current registry matches capability strings. A future catalog should attach a behavioral contract to a claim such as reasoning.ask: accepted context, result shape, cancellation, error handling, and supported limits.
Keep package version, contract version, and provider/model version separate. A new model release may change response quality without changing the JSON shape. A new package release may fix cleanup without changing the model. Clients need to know which kind of compatibility is being claimed.
Do not advertise automatic region, cost, or quality routing unless the host actually implements it. The current router chooses by capability, priority, and ID. If a tenant requires an allowed provider or region, trusted composition must choose a compliant integration; a catalog label alone cannot enforce the constraint.
Support two kinds of author
An internal integration team can publish a Go package or a narrow service adapter, a complete example, and evidence for the supported contract. The adopting host pins and wires it in code. This fits the current runtime.
A customer or third-party author may need independent deployment and a stronger trust boundary. That requires decisions about code provenance, process isolation, credentials, network access, tenant separation, policy, and revocation. In-process Go grants do not sandbox arbitrary code. Installation would need to enforce these controls before executing an extension.
The narrative's proposed ExecutionEnvelope could make identity and policy context explicit across a future remote boundary. Passing fields with those names would not enforce residency or allowed-provider rules by itself; the sending host and receiving service would both need defined checks.
Grow the catalog only when adoption requires it
| Stage | Useful capability | Trigger for the next stage |
|---|---|---|
| Source catalog | Owners, contracts, examples, pinned revisions | Multiple teams repeatedly need to find and compare integrations |
| Reviewed package releases | Clear compatibility and upgrade/deprecation guidance | Independent release cadence creates real version coordination problems |
| Managed deployment selection | A host selects an approved installed implementation | Products need configuration changes without rebuilding host composition |
| Customer installation | Controlled onboarding of external packages/services | A concrete customer requirement justifies isolation and policy machinery |
These stages are proposals. Validate compatibility with a second implementation before introducing shared installation or provider-selection infrastructure.
Define what a successful adoption looks like
A team should be able to read an entry, run its example, understand the data it receives, configure it, and verify the documented behavior. Replacing an implementation should leave the agreed room-facing contract stable.
For reasoning, test the same objective/context/result boundary against the replacement. For media, also test native client behavior, track permissions, disconnects, and cleanup. For tools with external writes, test the destination's duplicate policy. No single descriptor comparison can substitute for those checks.
The open questions and evolution guide describe the decisions that should precede a general platform.