Voice agents

Voice agents combine instructions, voice selection, safety configuration, and a browser-oriented test surface into a reusable conversational setup. The route presents the intended configuration model. Durable agent persistence, production tool execution, phone deployment, and guaranteed realtime connectivity remain unverified. Treat the builder as a preview configuration experience and verify each runtime dependency before relying on a session.

Agent model

A Voice agent is a configured conversational voice experience. Its definition can include instructions, a selected model and voice, routing preferences, and safety rules. That definition is different from an active session: configuration describes intended behavior, while a session represents a browser or phone-oriented interaction attempt.

The route metadata describes a Voice Agent Builder for persistent configurations and browser WebRTC testing. “Persistent” is product intent in the current surface; the supplied files do not establish the backing store, save semantics, versioning, ownership model, or recovery guarantees. A configuration shown after a reload should not be documented as durable until those storage paths are audited.

Keep three states separate:

• Configured means the interface contains the agent settings.
• Testable means the current browser and provider dependencies can attempt an interaction.
• Deployed would require a verified long-running or phone runtime, which is not established here.

The same distinction applies to tools. A tool listed in a configuration is not evidence that it will execute during a voice turn.

The agent model also needs a clear ownership boundary. Instructions belong to the configuration, while provider secrets remain server-side and user consent remains a separate governance record. Session events, usage entries, and generated audio are operational outputs; they should not be embedded back into the agent definition as if they were stable configuration fields.

A Voice agent is a configured conversational experience rather than proof of a deployed realtime service. The agent route is described as a Voice Agent Builder with persistent-configuration intent, instructions, safety rules, and browser WebRTC testing. The backing store and lifecycle guarantees for saved agent configurations remain unverified. Voice selection depends on provider and model metadata, which can be active, setup-required, coming soon, degraded, mock, or local-unavailable.

Configuration

Start with the agent’s purpose and the instructions needed for that purpose. Instructions should describe the desired conversational behavior, not contain provider credentials, personal secrets, or operational tokens. Add safety rules before testing so that the intended boundaries are part of the configuration rather than an afterthought.

Provider and routing choices should be checked independently. The Voice catalog includes mock, hosted, and local entries with mixed states such as setup-required, coming soon, degraded, and local-unavailable. A selected provider can still fail if server-side configuration is missing. Automatic routing can also change the execution path or use mock fallback.

A careful configuration pass should answer:

1. What task is the agent expected to handle?
2. Which instructions constrain its responses?
3. Which provider, model, and voice are intended?
4. Is fallback acceptable, and how will it be disclosed?
5. Does the use involve personal voice data or consent-sensitive material?
6. Are any listed tools actually backed by a verified execution contract?

Exact save controls, role controls, deployment states, and a public agent-configuration API remain unverified. Document fields only as they appear in the current surface.

Configuration review should happen before every browser test when instructions, provider, or safety settings have changed. Read the visible values back from the surface and confirm that no placeholder, setup-required, or coming-soon state is being mistaken for an active dependency. If the build does not expose a save confirmation, assume only that the current form state is available.

Instructions and safety settings describe intended behavior before a browser interaction begins. Browser testing is the first stated live path, while phone-oriented deployment remains setup and architecture focused. No audited contract proves that configured tools execute during a Voice-agent interaction. Realtime interruption handling, reconnection, event ordering, and durable transcript behavior require additional source review.

Voices

Voice choice depends on the selected provider, model, and current configuration. The constants file defines example voices and models, but those entries are not a permanent public catalog and do not establish live provider health. A voice that appears in the interface may be unavailable for the selected route, require provider setup, or resolve through a different fallback path.

Use a short browser test to confirm pronunciation, pace, clarity, and route identity. Check the provider metadata returned by the runtime when it is available. If the result uses mock fallback, label it accordingly and do not use the test as evidence that the requested hosted voice is ready.

Changing speed, model, or voice can alter the perceived result. The verified speech handler accepts speed from 0.1 through 10, but a Voice-agent realtime path may have different controls or constraints that were not audited. Keep agent-specific settings tied to the current interface rather than copying the speech endpoint contract wholesale.

For cloning-related voices, a user declaration of consent must be considered before use. The declaration is not independently verified by Ethen, and the presence of a consent record does not prove that cloning is supported by the chosen provider.

Voice identity and conversational behavior should be evaluated separately. A voice may sound correct while the instructions are ignored, or the instructions may work while routing falls back to mock. Record the returned route information whenever the test surface exposes it, and repeat consent review when the selected voice represents a real person rather than a stock or synthetic option.

A selected voice remains dependent on model, provider, and configuration state. Consent and prohibited-use boundaries apply independently of whether an agent configuration can be saved or tested. Record the safety constraints that should shape responses before opening the browser test surface. Use the browser test to observe whether audio, connection, and turn handling behave as expected in the current environment.

Sessions

The browser test surface is the first stated live path for Voice agents. A successful test can demonstrate that the current browser, microphone, audio output, provider, and routing path can participate in one interaction. It does not prove production uptime, durable storage, reliable reconnection, consistent interruption handling, or a complete event stream.

Before starting a test, confirm microphone permission and audio-output availability. Keep the first exchange short and avoid sensitive information. Observe whether the connection opens, whether audio is captured, whether the agent responds, and whether the session can be stopped cleanly. If the surface provides events or session metadata, use them as current diagnostic information rather than a guaranteed long-term record.

Several session behaviors remain unspecified:

• a complete session state machine;
• event names and ordering;
• automatic reconnect or resume behavior;
• transcript persistence;
• retention of audio or session data;
• phone handoff or transfer behavior;
• concurrency or session-duration guarantees.

Phone-oriented sessions belong to a separate setup and architecture preview. Do not describe browser testing as evidence that inbound or outbound calling is enabled.

A useful browser test checks four independent stages: connection establishment, input capture, model response, and audio playback. Failure at one stage should not be documented as failure of the entire agent definition. For example, a denied microphone permission can prevent the interaction even when provider configuration and instructions are otherwise valid.

Browser testing can create an interaction attempt without establishing durable session storage. Treat tool entries as configuration intent until a source-backed execution contract is available. Define the agent purpose and instructions without embedding credentials or sensitive operational secrets. Do not promise that a browser test will reconnect, preserve a session, execute tools, or interrupt speech uniformly across providers.

Tools

Tool configuration is not the same as tool execution. Tools are part of the intended agent model, but Voice sessions do not yet have a verified production tool registry, invocation contract, approval policy, credential boundary, result schema, or failure behavior.

Until those components are directly verified, document tools as planned or unverified configuration intent. Do not claim that an agent can call external services, mutate data, retrieve private records, or perform actions merely because a tool field or card is visible.

A safe review asks:

• Which tool is named?
• What action would it perform?
• What data would leave the voice session?
• Which credentials would be required?
• Is human approval needed?
• How would failure or partial completion be reported?
• Is the tool available, setup-required, planned, or disabled?

If those answers are not supplied by the current product, leave the tool out of the test scenario. A Voice-agent response can still be evaluated for conversational behavior without representing an unavailable action as complete.

If a future tool contract is added, it should identify the action, input schema, credential source, permission mode, approval requirement, result shape, and error behavior. Until those contracts are implemented and verified, do not provide tool setup steps or examples that imply external side effects.

Tool entries should be treated as configuration intent until execution is directly verified. Choose a voice and provider only after checking configuration state and intended routing mode. A configured agent is not proof of a durable deployment, a phone number, or an always-on realtime service.

Limitations

Voice agents remain preview functionality with several unresolved boundaries. Durable configuration storage, realtime reliability, complete session events, interruption handling, tool execution, phone deployment, provider readiness, and retention all require additional implementation evidence.

The browser test should be described as an environment-specific attempt. Network conditions, browser permissions, provider setup, model availability, and audio devices can affect the result. A test that works once does not create a service-level guarantee.

Do not promise:

• persistent agents across environments;
• always-on WebRTC connectivity;
• successful interruption or barge-in behavior;
• executable tools;
• inbound or outbound phone calls;
• recording or transfer support;
• fixed session retention;
• universal voice or provider support.

Use the agent builder to define and inspect a configuration, test the browser path conservatively, and record which dependencies were actually available. Move to phone or production use only after the corresponding runtime, provider, consent, and operational contracts have been verified.

A production decision should therefore require evidence beyond a successful preview test: verified configuration storage, a supported realtime runtime, documented events, provider readiness, consent controls, operational monitoring, and a clear failure-recovery path. The current page can guide configuration and evaluation, but it cannot satisfy those deployment requirements by itself.

The preview boundary is most important around persistence, realtime reliability, tools, and phone deployment.