Build or buy: telephony for AI agents

The demo always works

You can get an agent to make a phone call in a weekend. Rent a number, open a media stream, pipe the audio into a speech model, pipe the reply back. You ring your own mobile, the thing says hello, you grin. Most of us have built that demo or watched a colleague build it.

Then you point it at a real tire shop on a Tuesday morning. There's a phone menu. There's hold music. Someone picks up mid-sentence, talks over your agent, and asks it to spell the name. The call drops, and nothing got written down.

That gap, between the demo and a call you'd trust with your own name on it, is what the build or buy question is really about.

What's on the build list

Here's the inventory, in roughly the order you'll meet it. None of it is exotic. There's just a lot of it.

• A carrier account and a number. Somebody has to rent the number and deal with the carrier. Texting from a business number brings its own registration.
• Media streaming. Live audio in both directions, in the narrow format phone networks use, over a connection you keep open for the length of the call.
• A speech model. Either one model that takes speech in and gives speech out, or a chain of speech-to-text, a language model and text-to-speech. The choice changes how the call feels.
• Turn-taking. Deciding when the other person has finished. Too eager and you cut them off. Too careful and every reply starts with a silence.
• Interruptions. When the caller talks over your agent, it has to stop, drop what it was about to say, and listen.
• Voicemail detection. Working out whether a person or a machine answered, without leaving a real person in dead air while you decide.
• The write-up. A transcript, a summary, the details captured, and a status your agent can act on.
• Uptime. Phone calls arrive when they arrive. Your media servers have to be there when they do.

The parts nobody budgets for

That list is the engineering. There's a second list that's closer to judgment. What does the agent say when someone asks if it's a robot? What happens when a venue wants a card to hold the booking? How long does it wait on hold before giving up? What does it say to a voicemail greeting, and does it leave the right callback number?

You'll answer those in a prompt at first. Then you'll find the call where the prompt didn't hold, and you'll start moving rules out of the prompt and into code. We wrote about why in guardrails for phone agents. It's real work, and it's the kind that only shows up once you've had a lot of live calls with strangers.

When building is the right call

If voice is your product, build. We mean that. If the feel of the conversation is the thing your customers pay for, you need to own the audio path, choose your own models, and tune the turn-taking yourself. Buying would put the most important part of your product in someone else's hands.

Build as well if you need something a finished line won't do. Our line is one assistant making one call for one reason, with no bulk dialing, by design. If your plan involves a dialer and a list, you're looking at your own stack or a developer voice platform, and at the rules for that kind of calling, which differ from place to place and are worth checking where you are.

And build if you have the people. A team that already runs real-time media in production will read the list above and shrug.

When buying is

Buy when the phone call is a means to an end. Your agent does research, or scheduling, or runs someone's household admin, and now and then the thing it needs sits behind a phone number at a business with no API. The call isn't your product. It's a tool your product needs, the way it needs search.

In that case what you want is small: a way to say what the call is for, and a way to read what happened. On our line that's place_call with a purpose in plain English, then get_call for the outcome, the details, the action items and the transcript. You connect by adding cosvoice.com/mcp to the agent, or over REST with a key.

The number, the voice, the conversation and the write-up already exist. There's nothing to host and nothing to deploy. The longer pitch is on the page for agent builders.

Five questions that usually settle it

Still unsure? Answer these honestly. We'd rather you built the right thing than bought the wrong one.

• Is the sound of the call what your customers pay for, or is it the result of the call?
• Does somebody on your team want to own real-time audio for the next two years?
• How many calls a day, really? Count last month's. Don't guess.
• Do you need to choose the speech model yourself, or do you need the table booked?
• If calls are down for an afternoon, what happens to the people relying on you, and who gets paged?

The middle path, and the cost you don't see

There's a third option, which is a per-minute developer platform. The carrier and the media are run for you, and you bring the prompt, the logic and the rules. It's a fair choice if you want control over the conversation but not the plumbing. Expect to own the behavior on the call and what gets written down afterwards.

A finished line sits one step further along. You give up control of the audio path and the model, and in return your agent's whole integration is a brief and a result. For ours, the money side is on the pricing page.

The cost that's harder to see is on the build side, and it's mostly time. Not the weekend. The months between the weekend and the first call you'd let ring your own plumber.

Common questions

More on for developers

• What an MCP phone tool is, and what your agent gets from one
• OAuth for MCP servers, in practice
• Voicemail detection: the awkward first three seconds of an AI call
• Latency in voice AI: why a second feels like forever