How LiveKit and FaceTime work together with Chert

Understand the connection before writing code

The call path is: FaceTime participant → Chert bridge → your LiveKit room → your agent. Your backend owns the room and supplies call-scoped access. Chert handles the connection to the assigned FaceTime line. Your agent still needs its own model, voice, tools, and provider credentials.

For a named LiveKit agent, the CLI provides a path that does not require you to build an inbound webhook receiver. A backend-controlled Bring Your Own Room integration lets your service accept or decline an incoming call and supply a short-lived room token. Choose the path that matches who should control admission and the room lifecycle.

Prepare the project and agent

Start with an assigned Chert project and line, the required project access, and a working LiveKit agent. Check the current CLI quickstart for supported Node versions and the recommended CLI release. Use the same runtime in both terminals.

Keep your LiveKit credentials in the agent folder’s environment file. Confirm they belong to the project where the agent registers. Never put provider secrets in browser code, a public repository, or a support screenshot.

Run the agent and connector separately

After following the installation and sign-in steps in the quickstart, start your agent in one terminal using its normal startup command. In a second terminal in the same folder, check the connection and start the connector:

chert doctor
chert dev --agent YOUR_REGISTERED_AGENT_NAME

Replace the placeholder with the exact dispatch name registered by your worker. These commands assume you have completed project selection and have a running agent; they are not a standalone provisioning script. Keep both processes running. Wait for the connector and waiting room to be ready before placing a test call.

The optional agent-specific doctor check starts a real agent job and may incur provider usage. The read-only doctor check and successful room membership do not establish that a conversation works.

Verify the media, then verify the lifecycle

1. Call the exact assigned address with FaceTime Audio or, on a video-enabled line, FaceTime Video.
2. Ask a question and a follow-up. Confirm that the agent responds to what you actually said, then try interrupting once.
3. For agent video, confirm that the picture updates. For caller vision, change the scene and verify that the agent responds to the change.
4. Hang up from the caller’s device and wait for the room to be cleaned up.
5. Make a second call. Confirm it starts a fresh conversation and releases its resources afterward.

Record the first failing stage rather than treating every symptom as a networking problem. A connected but silent agent may have a model credential, credit, mute, or application error. An immediately ended call may be an admission or readiness problem.

Move to backend-controlled calls when needed

The BYOR flow lets your backend own the accept decision and supply short-lived room access. For outbound calls, prepare the room and keep the agent silent until bridge readiness or the corresponding call-start notification. The outbound reference defines the request and readiness contract.

Use the FaceTime API’s credentials and base URL, not the separate Messaging API contract. Monitor terminal call reasons and cleanup as well as connected state. An unanswered call must not leave a task marked complete or a room running indefinitely.

Budget for the full application

Chert’s line plan is one part of the cost. Your own LiveKit, model, and other provider usage is separate. Check daily minutes, call duration, concurrency, and caller access before sizing a trial or production rollout.