Frequently asked questions

Short answers to common integration and architecture questions. The linked guides explain the exact contract and point to the implementation. Proposed platform features are labeled as proposals in the architecture discussion pages.

Scope and architecture

Is RMC the complete Agentforce Live platform?

No. It implements a focused durable room, client pub/sub, authority, current media/voice boundaries, and several execution integrations. The design narrative describes a broader platform with additional session, agent, model, policy, and distribution contracts. Start with design direction for the mapping.

Where does Agentforce fit in this design?

The narrative proposes Agentforce as the first-party reasoning and action runtime behind an agreed Agent Runtime contract. Agentforce Live owns interaction. The current RMC demo connects its existing OpenAI and HTTP reasoner implementations; the broader contract and a dedicated Agentforce integration remain design work. See design direction.

Is a room the same as a ConversationSession?

A room is the durable workspace. Voice sessions, native tracks, and UI subscriptions have separate lifetimes. A product can compose them into its conversation-session experience, but RMC does not supply every proposed ConversationSession responsibility as one object. See rooms.

Does all reasoning happen inside the live interaction loop?

No. Delegations run requested work separately from the room's command processing, and the demo can invoke an external reasoner. Native interaction has its own media path. However, process separation and outage behavior depend on the concrete integration; they are not implied by the word “async.” See the architecture walkthrough.

Are ACP and ARI supported protocols?

The names come from the design narrative. This repository currently exposes room events, voice contracts, embedded agents, delegations, and the example reasoner/0.1 HTTP exchange. It does not implement a general ACP stream or remote ARI lifecycle. See semantic contracts.

LiveKit and media

Do I need LiveKit to use RMC?

No for durable text/events, replay, state, or reasoning. Yes for the current camera/screen-share and assigned vision-track implementation. The standalone server can omit media registration when LiveKit configuration is absent. See LiveKit dependencies.

Does voice go through LiveKit?

The current browser voice implementation connects to OpenAI Realtime over WebRTC. RMC handles setup, control, and normalized durable outcomes. Camera and screen share use LiveKit. These are distinct native paths; see the media guide.

Do I need LiveKit Cloud or LiveKit Agents?

The integration uses LiveKit's media/control APIs, not a requirement to use LiveKit Agents for reasoning. LiveKit can be deployed through Cloud or self-hosting, with deployment-specific behavior to verify. This repository does not certify every deployment. See hosting and replacement options.

Can I replace LiveKit by changing one setting?

You can configure another compatible LiveKit endpoint. A different media system also needs changes to the server adapter, browser session/bootstrap, vision processor, and lifecycle validation. Provider replacement is an architectural goal, not a configuration-only feature of today's complete application. See the dependency map.

Does removing a participant invalidate every media token?

RMC stops future authorized use and records provider cleanup. Provider-token revocation depends on the deployment: LiveKit documents different Cloud and self-hosted behavior, and connected clients can receive refreshed credentials. Test reconnect denial against the deployed provider; do not treat initial TTL as the complete guarantee. See setup and revocation.

Are raw camera frames stored in room events?

No. The current vision path publishes bounded structured observations. Its sampled-image ingress keeps bytes in memory and can forward them to authorized active Realtime sessions. RMC does not persist or replay those image bytes. External provider data handling remains part of the deployment configuration. See the vision path.

Events, context, and recovery

Do partial transcripts go into the durable log?

The current voice adapter normalizes transcript deltas and persists them alongside provisional conversation updates. Completed transcripts commit turns. Raw audio and arbitrary provider callbacks are not automatically journaled. Moving partials to a best-effort path would be a deliberate compatibility change. See event granularity.

Is RMC an ephemeral event bus or a media broker?

Room publication is durable. Native media, typing, meters, and other live-only presentation state use their existing provider or local UI paths. There is no general ephemeral publish API with the narrative's selectable delivery classes. See events.

Why can a cursor advance without an event callback?

The reader scanned records hidden by authorization or selection. An ordered checkpoint advances processed position past that hidden history. Gaps in visible sequences are normal. See cursors and checkpoints.

Is delivery exactly once?

No end-to-end exactly-once effect is promised. Stable publication IDs support retry identity, and the SDK tracks successfully processed sequences in memory. Your projection and external destinations need appropriate duplicate handling, especially across restarts. See the projection recipe.

Can separate room agents consume the same room independently?

Yes. Each agent has its own worker for the room. One agent processes its selected inputs serially, while other workers can progress independently. Outputs still commit through the room's ordered publication path. This is scheduling within the current Go process, not process-level failure isolation. See worker ownership and the implementation.

Does a room agent replay missed events after restart?

The embedded worker starts from the room's current position when it starts. It does not restore a durable per-agent processed cursor. Use explicit application-managed replay or a purpose-built worker if missed-trigger recovery is required. See extension failure behavior.

Does the reasoner receive the full room history?

The HTTP adapter receives an authorized context projection, including committed conversation turns and selected kinds of current resources. It does not receive every custom event automatically. Its request field context_keys is not a general enforcement mechanism for narrowing the projection. See context meaning.

Does a completed result include every recent message?

No. Work has a basis position and may finish after newer room events arrive. The product decides how to handle an older result, whether to request a new revision, and whether to present it in the active interaction. See late-result ownership.

Does closing a room delete its history?

No. Closure changes the room lifecycle and arranges provider cleanup. It does not erase the SQLite event log. The current API does not supply a general retention or redaction policy. See history retention as an open decision.

Can I run many RMC replicas against the same room?

The current runtime owns per-room command queues in one Go service and uses SQLite WAL. It does not define a distributed room-ownership, cross-replica notification, or high-availability protocol. A multi-replica deployment needs an explicit design and tests for ordering, delivery, and failover. See failure and deployment questions.

Extensions and the proposed marketplace

How do I add an extension today?

Choose an existing contract, wire it in trusted host code, and document its grants and lifecycle. Run the minimal room-agent example, or start with a concrete implementation in the integration catalog.

Can an extension use Python, TypeScript, Flow, or Apex?

Embedded runtime interfaces are Go. An external service can use the language or platform appropriate to it and connect through a purpose-built HTTP integration or authorized room API client. RMC does not currently include general Flow/Apex connectors or a remote worker framework for those languages. The integration must define authentication, timeouts, retries, cancellation, and data scope.

Is there an adapter marketplace I can install from?

There is a documentation catalog of current implementations. A marketplace is a proposed distribution direction. Today, hosts review, pin, configure, and directly register code. The marketplace page explains the path from a catalog to managed installation and the decisions that would be required.

Does a capability or version string guarantee compatibility?

No. The current registry matches capabilities and orders candidates by priority and ID. It does not certify behavior or enforce a common semantic-version policy. Record tested package/runtime revisions and verify the actual input, output, authority, and failure contract. See catalog versions.

Are in-process adapters sandboxed by participant grants?

No. Grants protect the room operations and filtered data supplied through RMC. Arbitrary Go code still runs with the host process's execution privileges. Customer-supplied code needs a separate trust/isolation decision. See trusted extension execution.

Can an async subscriber block an action for policy review?

An ordinary subscriber observes committed events asynchronously. It is not an inline authorization or policy interceptor. A required pre-action check must be explicit in the operation's synchronous boundary, with a defined failure policy. See policy enforcement questions.

What should we build next?

Choose the first concrete integration or failure requirement that current contracts cannot satisfy. Prove it with a narrow implementation, then generalize only when reuse warrants it. See the proposed evolution steps.