Transcripts are not enough: structured call outcomes for agents

What was said is not what happened

Give an agent the transcript of a phone call and ask it whether the table is booked. It'll read forty turns of "let me check" and "can you hold" and "we have 7:00 or 8:15", and give you a confident answer. Usually the right one. But you've made a language model work out a fact that was known the moment the call ended, and it'll have to work it out again every time something downstream needs it.

Worse, it's guessing at commitment. "That should be fine" from a host is not "you're booked". Whoever was on the call could have pushed for the second. A reader of the transcript can only interpret the first.

So the line that made the call should say what happened, in fields, while it still knows.

What comes back from one of our calls

This is what get_call returns on our line once a call is written up. The same object comes back over REST. (If the tool names are new to you, start with what an MCP phone tool is.)

• status: how far the call itself got. Completed, or no-answer, busy, failed.
• outcome: one line on what happened, like "Reserved · Friday 8:15pm · party of 2".
• summary: a short written account of the call.
• action_items: what now needs doing, such as holding Friday at 8:15 on the calendar.
• notes: the details the line captured. Names, amounts, dates, reference numbers.
• transcript: every turn, marked as the assistant or the caller, each with a time.

Two questions hiding in "how did it go?"

Did the phone call take place? And did the job get done? They need separate answers, because a call can go perfectly and still end in no.

The first is the call status: queued, ringing or in-progress while it's live, then completed, no-answer, busy or failed. That's plumbing. Your agent mostly uses it to know when to stop waiting.

The second is the result. For reservation calls our line logs one of these: confirmed, alternative_confirmed, waitlisted, hold, requires_online, needs_owner, callback_later, no_availability, declined_by_venue, voicemail, not_reached. Eleven ways for a booking call to end, and only the first two mean the owner has the table they asked for or one they said they'd accept.

The honest statuses are the useful ones

It's tempting to design a status list as success plus a bucket called failed. Don't. The states in the middle are where an agent earns its keep.

Take needs_owner. The restaurant wants a card to hold the table. Our line never reads out a card number and never agrees to a charge, so the call can't finish the job. But it hasn't failed. The table is there if the owner acts, and the agent's next move is to ask Graham, with the details in hand.

Or take not_reached, which is different from voicemail, which is different again from no_availability. Try later. Wait for a callback. Try somewhere else. Three different next actions. Fold them into "failed" and your agent has to open the transcript to find out which one it's in, which is where we came in.

Design from the next action backwards

If you're writing your own outcome schema, for phone calls or for anything else an agent hands off, start from what the agent will do next and work back. Every status should lead to a different action. If two statuses lead to the same action, merge them. If one leads to two, split it.

Here's how that sorts for a booking call:

• Done, tell the owner. Confirmed, with the date, time, party size and name.
• Done, but changed. An alternative was taken inside the window the owner gave. Say what moved.
• Waiting on the other side. Waitlisted, a hold, a callback later. Set a reminder to check.
• Waiting on the owner. A deposit or a decision. Ask, with the details.
• Wrong channel. The venue only books online. Send the owner there.
• No. Nothing available, or the venue declined. Try the next place on the list.
• Nobody there. Voicemail or not reached. Try again at a better hour.

Fields are for amounts, dates and names

The same thinking applies below the status. A quote call that comes back as prose ("he said about forty-eight fifty with the permit") makes the agent dig a number out of a sentence. A quote call that comes back with the amount, what it includes, how long the price holds and the start date as separate details can go straight into a comparison of three contractors.

One caution. Notes are what the line heard. Treat them the way you'd treat a colleague's notes from a call: good to act on, and worth confirming in writing when money is involved.

Keep the transcript, read it second

None of this makes the transcript useless. It's the record. When the owner asks "did they say anything about parking?", the answer is in there and nowhere else. When a status looks wrong, the transcript is how you check. We keep the written call and not the audio, so it's the fullest record there is. (Who can read your AI's call transcripts covers the privacy side.)

But it's the second thing to read. The rule we give every agent that connects to our line is short: don't claim a booking, an appointment or a commitment unless the call outcome says so. An agent can only follow that if the outcome is a field it can read. The fields are listed on the docs page.

Common questions

More on for developers

• What an MCP phone tool is, and what your agent gets from one
• Build or buy: telephony for AI agents
• OAuth for MCP servers, in practice
• Voicemail detection: the awkward first three seconds of an AI call