Open architecture questions

These questions are open design decisions, not missing configuration steps. Each starts with the current implementation, compares implementation options, and names the evidence needed before expanding the runtime.

Use them in a design review with a specific user flow. “Make everything pluggable” is a direction; “support a second reasoner without changing the client event contract” is a requirement that can be tested.

What is the lifecycle of a ConversationSession?

Today: the room owns durable identity and context. Voice sessions, native media connections, and component subscriptions have separate lifetimes. There is no single object implementing every ConversationSession responsibility in the narrative.

Options: keep product composition around these primitives, add a small session facade for a defined user flow, or expand/rename the core room abstraction. Renaming alone would not define handoff, modality transitions, or ownership.

Next decision: specify one cross-modality flow, including who ends the shared room and who closes local resources. Prefer a product facade if the current primitives can express it. Verify that a view change, media disconnect, and human handoff produce the intended distinct outcomes. See room lifetime and client ownership.

How replaceable must LiveKit be?

Today: pub/sub is independent of LiveKit, while camera/screen bootstrap, browser track ownership, and the vision processor use LiveKit explicitly. The server has a media control interface, but replacement is not configuration-only.

Options: keep the current integration, use another LiveKit deployment, add a second media transport, or use a direct single-provider media path for a narrower product.

Next decision: name the required alternative and the reason for it: deployment control, a contact-center integration, a device constraint, or a different media topology. Compare the native client and processor work as well as the server adapter. Require evidence for track-level authority, identity mapping, reconnect, and cleanup. See the dependency map.

What should be stable between interaction and reasoning?

Today: RMC has normalized events, authorized context projections, task identity/revision, and an example HTTP reasoner exchange. It does not implement a general ACP or remote ARI lifecycle.

Options: retain a narrow request/result contract, add streaming results to a specific integration, or define a broader remote runtime lifecycle.

Next decision: write the second integration's input, output, cancellation, timeout, and context requirements. Introduce only the semantics both implementations need. Decide who owns each schema and how older consumers behave after a schema change. Semantic contracts explains the existing fields and their limits.

What survives a process or provider failure?

Today: durable events survive with the SQLite database; SDK consumers reconnect from processed in-memory cursors; application restart requires saved progress or replay. Outstanding delegations are marked interrupted after runtime restart. Native media uses separate connections, but RMC still owns control and coordination.

Options: keep the current deployment and explicit recovery, isolate a particular work service, or split more runtime responsibilities when a measured availability requirement demands it.

Next decision: define the acceptable user experience for reasoner failure, LiveKit failure, RMC restart, and storage failure separately. Test each on an isolated stack. A test proving text publication continues during a slow handler is useful evidence; it is not proof that an established call survives a runtime outage. See agent isolation tests and restart storage behavior.

Which interaction changes belong in durable history?

Today: room publications are durable. The voice integration journals normalized transcript deltas and provisional turn updates as well as completed turns. Raw media uses a separate path. Typing and meters remain native/local state.

Options: preserve the existing event granularity, reduce selected high-frequency updates to durable milestones, or use an existing provider's transient stream for live-only presentation.

Next decision: identify what a reconnecting client must reconstruct and measure the write volume of the actual flow. Before removing or coalescing records, account for existing consumers of those event types. The narrative's four delivery classes are proposed semantics, not switches on today's publish API. See event granularity.

How long must replayable history remain available?

Today: SQLite stores the durable room log. Closing a room updates its lifecycle and arranges provider cleanup; it does not delete the room's event history. The current API has no general retention, redaction, or history-expiry policy. Read the store and room lifetime.

Options: retain current history for the deployment's defined lifetime, add targeted removal for a concrete requirement, or introduce a bounded replay window with an explicit snapshot/recovery contract.

Next decision: state how long a returning client may be offline, what data must remain replayable, and what the product must remove. Define how a client recovers when its saved cursor predates available history. Keep lifecycle closure, access revocation, and data deletion separate. A targeted schema change may be enough; these questions do not require a general migration framework in advance.

Who decides whether a late result is still relevant?

Today: delegations carry a task key, revision, execution ID, and basis sequence. Newer revisions can supersede older work. Voice epochs protect the active voice-session lifecycle. These mechanisms do not decide every product-specific question about whether an answer is still useful.

Options: render every accepted result in a work history, apply a product freshness rule before presenting it, or request a newer task revision when relevant context changes.

Next decision: define what happens when the customer changes the question while reasoning runs, or interrupts after an answer starts playing. Distinguish “result produced,” “accepted into the room,” “presented,” and “heard.” A result tied to an older basis may remain useful as history without being the next thing the assistant should say. See delegations and voice control.

When does an extension need durable worker recovery?

Today: an embedded room agent reacts while its worker is active and does not restore a persisted consumer position on restart. An SDK consumer can save its own projection and cursor. Neither mechanism makes arbitrary external effects exactly once.

Options: keep an embedded reaction for bounded local work, use an application-managed consumer with explicit replay/idempotency, or add a purpose-built durable job integration.

Next decision: identify the external effect and the failure window that matters. A recomputable UI enrichment and an irreversible external action do not need identical machinery. Require a restart example showing what may repeat, what may be missed, and how the destination handles duplicates before adding atomic output/checkpoint infrastructure. See extension failure behavior.

What would make an adapter marketplace worth building?

Today: implementations are wired in code. The catalog documents them; descriptor versions and capability names are not an installation or certification system.

Options: keep a source catalog, publish reviewed package releases, add deployment-time selection, or support customer-installed integrations with an explicit trust boundary.

Next decision: identify the adoption problem. Repeated discovery work calls for better entries. Incompatible independent releases call for a compatibility policy. Untrusted customer code calls for isolation and policy enforcement. Choose the change that addresses the observed adoption problem. See the marketplace proposal.

Where are policy and data residency enforced?

Today: participants, grants, visibility, and filtered context govern the current room boundary. Trusted code chooses external endpoints and credentials. A room ID is not, by itself, a complete tenant, classification, residency, or allowed-provider policy model.

Options: keep policy in trusted product composition for the current deployment, define a typed execution envelope at one remote boundary, or introduce broader policy routing after several integrations require it.

Next decision: trace one piece of data through capture, storage, context selection, external execution, and replay. Name the enforcement point for each rule. Do not accept a proposed envelope field as enforcement without a check at the sending and receiving boundary. A separate policy decision that must block an action needs a synchronous contract; an ordinary asynchronous subscriber cannot serve as an implicit interceptor. See authorization and the semantic context boundary.

What evidence supports independent releases?

Today: the repository has tests for its client, runtime, media lifecycle, and concrete integrations, plus basic bounded timing diagnostics. It does not implement the narrative's complete provider-substitution matrix, common outcome evaluation, or independent Conversation/Agent ADLC release system.

Options: maintain the current integration tests, add fixtures for one independently released contract, or build a broader compatibility gate once several teams release against it.

Next decision: choose one replacement or independent release and state what must remain unchanged. For example, a reasoner change should preserve correlation, cancellation, authorized context, and result shape; a voice change also needs playback and interruption tests. Measure the user-visible outcome as well as transport success. Evolution steps lists concrete experiments without claiming they have already passed.

Record a decision with enough context to revisit it

For each decision, record the product flow, current constraint, chosen option, rejected alternatives, evidence, owner, and trigger for revisiting it. Use roles such as client owner, interaction owner, reasoning owner, and platform owner until an actual team accepts responsibility.

Keep an open question open when the requirement is unknown. A long list of provider slots should not become an implementation plan by default.