Real-Time Media ConductorArchitecture · Design decisions
Agentforce Live design and current RMC behavior
Map Agentforce Live concepts to current code, then identify the product requirements that would justify the next abstraction.
The proposed Agentforce Live design separates live interaction from longer-running reasoning. RMC implements durable room events, native media coordination, and asynchronous delegations. This page maps those implementations to the proposed design and identifies the remaining work.
In that design, Agentforce Live owns interaction, and Agentforce is the proposed first-party reasoning and action runtime. Compatible customer or third-party runtimes would use the same agreed contract. The current RMC demo uses its OpenAI and HTTP reasoner integrations; it does not yet supply that general Agent Runtime contract or a dedicated Agentforce implementation of it.
Use this section to evaluate the direction, find the current extension points, and identify the requirements for further changes. The architecture walkthrough describes the implemented client path.
Keep interaction and reasoning at different cadences
A customer can keep speaking, interrupt playback, or share a screen while a reasoner works on a task. These actions should not all wait for one synchronous reasoning response.
In the current application, native providers carry media. RMC coordinates participant authority, durable events, conversation state, and requested work. A directly wired adapter can invoke a separate reasoner service. The result returns to the room and can inform the live interaction.
The separation is about responsibilities. Separate connections or Go goroutines do not, by themselves, prove that a voice session survives every reasoner, storage, or runtime failure. That stronger availability claim needs a defined failure policy and an end-to-end test.
Translate the narrative into this repository
| Narrative concept | Current implementation | Remaining design work |
|---|---|---|
ConversationSession |
A durable Room, conversation turns, voice-session records, and native media sessions |
A product-level lifecycle spanning modalities, handoff, and reconnect |
| Semantic interaction | Typed text, conversation, and video facts; authorized ContextProjection |
A shared schema and compatibility policy across independently released integrations |
| Agent Runtime contract / ARI | DelegationAdapter.Run, embedded RoomAgent.Handle, cancellation, and task revisions |
A remote lifecycle for streaming, checkpoint recovery, handoff, and session ownership |
| ACP semantic stream | Room events, voice notifications, and the example reasoner/0.1 HTTP boundary |
A common streaming interaction/reasoning protocol, if a product needs one |
| Channel and transport provider | MediaAdapter, VoiceAdapter, and current client integrations |
Additional proven providers, including any required telephony or CCaaS integration |
| Reasoning and model providers | Current OpenAI and HTTP reasoner adapters | Separate model selection, routing constraints, and compatibility rules |
| Event extension surface | Authorized durable pub/sub with independent cursors | External consumer operations such as retention policy and dead-letter handling |
| Execution envelope | Participant authority and filtered context at current boundaries | A cross-service contract for tenant, policy, classification, residency, and allowed providers |
| Personality profile | Instructions and product/provider configuration | A typed profile and tests for how it affects each modality |
| Telemetry contract | Bounded timing records, basic traces, and existing diagnostics | Common cross-service traces and product outcome evaluation |
ACP and ARI here refer to names in the design narrative. They are not protocol implementations supplied by this repository. A room is also not a drop-in implementation of every proposed ConversationSession responsibility.
The current definitions are in types.go, voice.go, media.go, context.go, and telemetry.go.
Start at the boundary your team owns
Client teams can use the TypeScript SDK, share one room handle, and consume selected durable facts. Keep native tracks and transient view state in their existing owners.
Conversation engineers can work on the current voice adapter, playback, interruption, and native media integration. LiveKit dependencies explains which pieces are provider-specific today.
Reasoning teams can connect a concrete service through the current HTTP reasoner boundary. The service owns its models, credentials, and work execution. It should not need LiveKit track objects or browser playback state to answer a semantic request.
Extension authors can use an embedded room agent, delegation adapter, or registered tool. Start with build an extension and the current integration catalog.
Platform architects can use the open questions to turn the narrative into decisions supported by a product flow and evidence.
Make replacement a testable claim
The narrative proposes that changing a provider should require configuration changes rather than application redesign. Treat that as a target acceptance criterion.
Today, changing the HTTP reasoner to another service implementing the same reasoner/0.1 exchange can preserve the room-facing adapter. Replacing LiveKit would also affect browser media code, bootstrap assumptions, and the vision processor. Replacing the voice provider requires matching the actual signaling, notification, interruption, and cleanup behavior expected by the client.
For each replacement, state what remains stable, what must change, and what test proves compatibility. A descriptor with a capability name is not that proof.
Evolve through one product need at a time
The current integration catalog records implementations, contracts, and examples. Package distribution or installation support would require additional requirements for compatibility, release ownership, and deployment controls.
Keep the current durable pub/sub path small. Leave transient presence and meters on their native path. Add remote execution, model routing, or stricter side-effect recovery only when a workflow requires their semantics. The evolution guide proposes acceptance criteria for those changes.