A clear way in.

Start by describing one conversation and its intended outcome. Choose the information your agent needs, the actions it may take and the point at which it should bring in a person.

1. Shape the agent. Write a system prompt, an opening message and clear boundaries.
2. Connect context and actions. Define knowledge sources and scoped tool inputs.
3. Trace the path. Model conditions, the voice response and a human handoff. Test the experience before connecting a channel.

This is a conceptual quickstart. Public account registration is not yet open.

Keep the system prompt, first message, language, model and voice configuration together. Separate knowledge retrieval from tools that change data.

Test ordinary requests, missing context and handoffs. After connecting a runtime, use transcripts and events to inspect decisions.

A workflow makes the next action explicit. Begin with a trigger, interpret input, then use conditions to route toward knowledge, a tool, a response or a person.

The public canvas lets you inspect a sample flow and download its example configuration. It does not publish or execute a production workflow.

Map inbound and outbound call paths, numbers and SIP entry points. Make queue behavior, DTMF input and transfers part of the routing design.

Define the destination for a human handoff alongside the agent route. The public call console shows sample sessions only.

Stable endpoint contracts, authentication requirements and error formats will be documented here as they become available.

Current code examples use illustrative syntax and an example host. Do not use these examples as a production API contract.

SDK guidance will describe supported packages and versioned interfaces when published. No installation command or public SDK package is asserted here.

For now, explore the client pattern: keep credentials at the service boundary, pass scoped configuration and handle results explicitly.

Design your receiving application around explicit event types and structured payloads. Consider validation, duplicate events and how your application records processing outcomes.

Delivery behavior and verification mechanisms depend on the published production contract. The current developer example illustrates handling only.

Explore an appointment assistant: identify the caller’s preferred day, request availability through a calendar tool, confirm the choice and return a voice response.

Keep sample data separate from production records. The site’s interactive examples run locally and do not access a microphone, place calls or execute external tools.

Begin an architecture review with transport, intelligence and execution boundaries. Identify which system owns the data and which component can change it.

Follow one conversation end to end: input, context, decision, action, response and observability. Make failure and human handoff paths explicit.