What you need before Octo can take calls

A number, an agent, and a binding between them. Where each lives, and why a number that answers is not proof that anything is set up.

Updated

Three things, on two screens. The third is the one people skip, and skipping it produces a phone line that answers convincingly while doing none of your work.

A number

/phone-numbersBuy a number. You pick a country, then choose from Available numbers. This is the fast path and it is done in about a minute.

The alternative is Bring your own Twilio number, or a full carrier connection if you already have one. That flow has four steps — Carrier, Connection, Numbers, Verify — and asks for SIP details you get from your carrier: SIP host, SIP port, Transport, SIP username, SIP password, Caller ID, and a Dial format with optional prefix and suffix.

Two things about the carrier path worth knowing before you start it:

  • It needs an owner or admin. “Adding a carrier requires an owner or admin. Nothing was created.”
  • A failure does not leave a mess. If setup fails part-way you get “Setup failed — nothing was left half-configured.” Your details stay filled in, so retrying is retyping nothing.

Dial format matters more than it looks. Some carriers want national format, and sending E.164 to one that expects national is a configuration that validates cleanly and then fails at dial time.

An agent

/agents → create one. At minimum it needs a name and a system prompt — “Agent name and system prompt are required.” — and a greeting, the First thing your agent says.

Everything else about the agent (voice, pipeline, knowledge) can wait. What cannot wait is that this agent exists before you bind the number, because the binding is the next step.

The binding between them

This is the step that gets skipped.

On /phone-numbers, the number should say ”… answers this channel” with your agent’s name in it. On /agents, the Deployment section should show Deployed to … rather than Not deployed or No voice channel.

If either says otherwise, you have a number and an agent and no connection between them.

Why an unbound number still answers

Here is the trap. A connected number answers before you have bound anything. A test agent picks up, sounds plausible, and knows nothing about your business.

So “I called it and someone answered” is not evidence that setup worked. It is evidence that the number is connected, which was the easy half. The check that means something is the greeting: if you hear your First thing your agent says, you are through. If you hear anything else, the binding is missing.

This costs people more time than every other item on this page combined, because the symptom of failure is a working phone call.

A phone to test with

Not the browser. /agents offers a Start mic test“WebRTC mic test. No phone needed — talk to the agent straight from this page” — and it is genuinely useful for checking what the agent says.

It does not test the phone path. The screen says so itself: “WebRTC works for browser testing. Phone routes need a number.” A mic test passing tells you the agent works; it tells you nothing about whether calls reach it.

Use Call this number to test and ring it from an actual phone.

A timezone

Set the workspace timezone before anything schedules itself. It is the default every later feature reads, and correcting it afterwards does not retroactively fix anything that already ran on the wrong one.