Explain what function calling lets a model do that plain text generation does not.

Passway is a chat travel concierge. Tell it where you want to go and it searches flights and hotels, then can actually book them. Briallen Iyengar owns the booking assistant. Five weeks into building a multi-city version of it, she ran her usual audit against the airline's real reservation system, and found out that most of the confirmations reading "Booked!" were sentences with nothing real behind them.

How to answer this, stage by stage

Nobody is grading whether you can define function calling. They are grading whether you can say, with a real number, what a reply can get away with when nothing checks it against the real world.

Let's learn

Here is what happens when a chat reply and a real action start to look exactly the same, and only one of them is actually true.

Say we build a travel concierge that chats with you about a trip, then actually books it: real flights, real hotel rooms, a reservation you can show up to.

Both replies can say the same six words. Only one of them changed anything outside the chat window.

The first version of the assistant only handled one flight at a time, and it worked. Every "Booked!" reply had a real reservation behind it: forty out of forty, in the very first week anyone tested it for real.

Then it grew. A new multi-city mode let a traveler chain several flights into one trip, Mumbai to Lisbon to Casablanca to Mumbai, planned and booked in one chat. The natural-language planning half of that feature worked so well in early demos that the booking half quietly slipped down the list of things anyone double-checked. By week five, only six of twenty five multi-city "Booked!" replies had a real reservation behind them. The other nineteen were confident, well-formed sentences describing a booking that had never happened.

Here is the turn. The nineteen missing reservations were not the real problem. The real problem is that nothing in the chat told anyone which six replies were true.

This is the fix in one picture: a confirmation message is not allowed to exist until a real result exists behind it.

What it costs at its worst: a customer shows up at the airport holding a confirmation number the airline has never heard of, and finds out on travel day, not before. The plain-text-only version of this tool, the one that never claimed to book anything, was honest by accident. The new one claims something false with total confidence.

What I would leave alone: explaining baggage fees, comparing two itineraries, answering "is this a good time to visit Lisbon." None of those change anything real, so plain text is fine there, actually better, since checking a live system for an answer that was never going to touch it just adds a wait with nothing behind it.

The lesson: a model that only writes text can never lie about the real world by accident, because it never touches the real world. Give it a way to act, and the moment its words and its actions can drift apart is a moment worth watching for on purpose, not something you find out about from a customer standing at a gate.

Now here is the same thing as a story

The short version above is what you actually say in the room. Read this one for the habit that let a false confirmation sit unnoticed for five weeks, and what happened once the fix was real.

Every Friday afternoon, before she does anything else, Briallen Iyengar pulls a real sample of trip requests and checks each "Booked!" reply against the airline's own reservation system, not the chat, the actual system. She has done product for booking tools for six years, and she says the tell is never how a reply reads. It is whether the thing it claims actually exists somewhere else.

For the first two months of Passway's single-flight assistant, the Friday check was almost a formality. Forty requests, forty real reservations, every single week. She kept doing the full check anyway, because a habit that costs twenty minutes and confirms good news is an easy habit to keep.

Then multi-city shipped, five weeks against a travel-season deadline, and the Friday check started to shrink. Week two, she still pulled forty, but only skimmed the ten multi-city ones since the demos had looked flawless in the team meeting that same morning. Week three, she stopped pulling the airline records at all for the multi-city slice and just read the transcripts for tone. They always sounded fine. Reading for tone is faster than checking a real system, and nothing had gone wrong yet, so nobody had a reason to notice she had quietly changed what "checking" meant.

Nobody decided, on any single day, to stop checking the real system. It just got easier not to, one Friday at a time.

The trigger was small. In week four, a new hire sat in on the Friday review for the first time and asked a plain question: "Wait, does this actually check that the reservation exists, or just that the message sounds right?" Briallen opened her mouth to answer and realized she did not actually know anymore, not for the multi-city slice.

The demo and the audit used the exact same kind of trip request. Only one of them checked what actually happened after.

So she went back to the full check, the real one, the one she had let thin out. She pulled every "Booked!" reply from that week's multi-city requests and matched each one against the airline's own reservation list, by hand, the way she used to. Six matched. Nineteen did not.

We did not lose six good bookings. We lost the ability to tell which of the twenty five replies a customer could actually trust.

I want to say the problem was that the multi-city booking code was unfinished. It was, but that is not really the story. Briallen never had a number in her head for how many fake confirmations was too many. She had a Friday habit, and the habit only kept catching real problems because she personally kept doing the slow version of it, even after it stopped feeling necessary.

The decision she would take back sits in a design meeting from months earlier, back when the single-flight assistant was brand new. Someone asked whether the "Booked!" message should wait on the real function result before it rendered, or just get generated as soon as the model decided a trip was arranged. Waiting felt like unnecessary complexity for a tool that, at the time, basically never failed to book what it said it would. They shipped the ungated version. Nobody revisited that call once multi-city got bolted on under a five-week deadline.

Run the same five weeks again, gate in place this time: a confirmation cannot render until a real function call has actually returned a real reservation. By week five, the nineteen fabricated confirmations become nineteen honest replies instead, "still working on this leg, hang tight," not a lie dressed as good news. Zero customers ever see a false booking. Launch slips twelve days while the multi-city booking code actually gets finished, instead of shipping fake confidence on schedule.

One design let the words get ahead of the work. The other keeps them tied together, even when that means admitting out loud that the work isn't done yet.

Passway shipped the gated version twelve days late. Then a second problem showed up, this one from the opposite direction.

Once function calling genuinely worked end to end, the confirm step, "yes, cancel it" or "yes, charge the card", added a full extra turn to every booking and every change. Wilhelmus Farrand, who owns the conversational UX, watched completion rates dip and made the case that the model was right almost all the time now, so the confirm step was mostly just friction. He cut it for the delay-recovery flow specifically, the one where the assistant tries to help a traveler who's about to miss a connection.

The assistant was not wrong about the flight being missed. It was wrong to decide alone what to do about it.

Two weeks later, a traveler's connecting flight ran late, and they asked the assistant to help. The assistant reasoned, correctly, that the connection was unreachable, and decided, on its own, that cancelling the now-useless leg and searching for a same-day replacement was the right move. It called the cancel function immediately. It never asked first. The old fare, three hundred forty dollars, nonrefundable, was gone, and by the time a replacement search ran, that same seat cost more. The traveler ended the chat with less than they walked in with.

What I would tell myself, back in that first design meeting: sounding done and being done are not the same claim, and the day you give a model real hands, that difference stops being philosophical and starts being a phone call to a customer standing at a gate.

LEAD, so a chat reply never outruns what actually got booked

Not a way to prove Briallen is smarter than a deadline. LEAD is what forces you to name the number that would have caught this before anyone shipped it, and the line that keeps a working model from acting alone on a costly guess.

Four different actions, four different rules. None of them is "trust the model a little less everywhere."

The recap, one line per letter: link the assistant's confirmations to whether a real reservation exists, not to how fluent the reply sounds. The early signal is the receipt rate itself, sliced by trip complexity, because a transcript quality score cannot tell a true confirmation from a well-written one. Name the abuse plainly: once a model can really act, "the model chose to call it" quietly gets treated as "the customer approved it," and that substitution is what actually costs money. The decision step is what makes the whole thing real: different rules for different actions, sorted by cost and how hard a mistake is to undo, not one blanket setting for how much to trust the model. Two things worth saying plainly, since this is where the real judgment sits. Passway's team considered a different fix for the fabricated-confirmation problem before building the receipt gate: keep confirmations text-only and add a disclaimer to every single one, "this may not be finalized yet." They rejected it, because a disclaimer on every reply trains a customer to distrust the 96 percent that were completely correct along with the 4 percent that weren't, which breaks trust everywhere instead of fixing it where it was actually broken. The AI-specific failure worth naming by name is a model's fluency at describing an outcome, which is not evidence the outcome happened, and the guardrail that actually catches it is the receipt gate itself: no real function result, no confirmation text, full stop. And the trade-off was real and taken on purpose: gating every confirmation behind a verified function call means waiting for the real system to answer instead of generating a sentence instantly, and the multi-city launch slipped twelve days rather than shipping on schedule. Both costs were accepted, because a customer discovering a fake booking at the airport is far more expensive than either one.

And if you want to be sure it really works, try it somewhere else

Same four letters, a veterinary clinic chain instead of a travel concierge, and this time the fabricated confirmation comes from an overloaded calendar, not an unfinished feature.

Wickerbrook runs the scheduling assistant for a chain of veterinary clinics. Pet owners chat with it to reschedule appointments and request prescription refills, and it can actually change the clinic's real calendar, not just describe doing so. Thordis Marchside owns it, and hit a smaller version of Briallen's exact problem four weeks after a summer rush pushed evening chat volume past what anyone had load-tested.

The calendar API timing out under evening load is a different cause than Passway's unfinished feature. The same lie reaches the owner either way.

Wickerbrook's receipt rate, the share of "you're all set" replies backed by a real calendar change, held near 92 percent for same-day reschedules through the spring. Over four weeks of a busier summer, it fell to 58 percent, because the clinic's calendar system started timing out under evening load, and the assistant's fallback text still generated a friendly, confident reply either way. The reviewer-graded "helpfulness" score never moved off 4.6 out of 5 the entire time.

Mapped onto LEAD: the link is the same shape, a reply only means something if a real appointment actually moved on the real calendar, not if the sentence sounds warm. The early signal is again the receipt rate itself, sliced by time of day, since a general helpfulness score cannot separate a true confirmation from a good guess. The abuse Thordis found was smaller but real: to make room for a rescheduled slot, the assistant auto-cancelled three existing wellness visits over one month without asking the owners first, each one requiring a staff member to call and apologize. Her decision step matches Briallen's: booking a fresh, open slot fires alone, because it is easy to release; cancelling any existing appointment, or touching a refill for a controlled substance, always waits for a real yes.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to it: name the receipt gate as one line, and the confirm-before-consequential-action rule as the other.
Cost: no budget this quarter to build a polished confirm-step screen. Whoever owns the assistant writes down, in public, which specific actions are allowed to fire alone this month, before anyone builds anything fancier.
The model got better, for real: say the multi-city booking call now succeeds 99.9 percent of the time. Still gate the confirmation on the real result, because the one time in a thousand it fails is exactly the time a customer needs the truth, not a nice sentence.

Where people run it wrong.
They grade the assistant on how convincing its replies sound instead of whether a real system actually changed, so a fluent excuse passes the same bar as a real success.
They treat "the model decided to call the function" as the same thing as "the customer asked for this," when only an actual human yes should authorize spending money or destroying a reservation.
They gate everything behind a confirm step, including harmless lookups, and train people to click "yes" on reflex, which quietly defeats the one confirm step that actually mattered.

How to use it live. When an interviewer asks what function calling changes, ask yourself one question before answering out loud: "if the model is wrong here, does a sentence sound wrong, or does something real happen." That line is usually the whole answer.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0