Your AI agent is not the system

An AI receptionist looks like one thing: a voice that answers the phone. It is not one thing. Around that voice sit fifteen or so decisions about intent, authority, state, ownership, escalation and failure, and none of them are the voice. Buying the agent is the easy part. Engineering what happens before, during and after it speaks is the work, and it is where the value actually sits.

What my friend was picturing

A realtor I know asked me last week whether an AI receptionist could answer his phone and make follow-up calls. Reasonable question, and the answer is yes. But listening to how he asked it, I could hear the picture in his head: you buy the thing, you switch it on, it works. An appliance.

I have some sympathy, because that is exactly how these are sold. It is also how they fail. What he was describing as one purchase is a set of business decisions he has never had to write down, because until now a person made them in the moment without anyone noticing.

Ask a receptionist what she does and she will say she answers the phone. Watch her for a morning and you will count a dozen judgements she makes without being asked: this caller is upset, this one is a supplier, this one has asked the same question twice, this one should go to the boss now rather than at five. None of that is in her job description. All of it has to be in the system.

The fifteen jobs behind one voice

Here is what actually has to be decided for a front desk that answers a call and does something useful with it. Some of these are software. Most of them are a business owner making a rule out loud for the first time.

• Intent. Why is this person calling? Booking, complaint, supplier, wrong number, existing client with a problem.
• Risk. Is this routine, sensitive, urgent, or the kind of call that becomes a legal problem if it is handled badly?
• Knowledge. What is this system allowed to tell people? Prices, availability, policy, and what it must never guess at.
• Authority. What may it decide by itself, and what needs a human to say yes?
• Gatekeeping. What proceeds, what is blocked, what gets handed straight to a person.
• State. Is this a new lead, a qualified one, a booked client, someone on a waitlist, someone mid-complaint? The right next sentence depends entirely on which.
• Ownership. When it cannot finish, whose problem does it become? Not the office, not an inbox somebody checks eventually, but a named person, because a job given to everybody is a job given to nobody.
• Response times. How fast does that person have to act before the lead is cold?
• Escalation. What happens when they do not.
• Follow-up cadence. When does the system get back in touch, and how many times.
• Stop conditions. When does it stop. This one is skipped constantly, and it is how businesses end up chasing someone who bought three weeks ago.
• Guard conditions. Before it sends the next message, is the person still in the state that makes the message appropriate?
• What it leans on. This system does not work alone. It books into a calendar, writes to whatever holds your customer list, sends texts through a phone network. Any of those can be down for an hour. What happens in that hour?
• Graceful degradation. Can the business keep working when one piece is down, without lying to anybody.
• Logging. Afterwards, can you tell what the system did, what a human did, and where it went wrong?

Read that list again and notice how little of it is about artificial intelligence. It is a description of how a business handles its own phone. The model is the easy component. The list is the product.

A caller asks for Tuesday

Take the simplest possible call. Somebody wants an appointment on Tuesday.

A thin agent hears the request, checks a calendar, and books it. That works, and it will keep working right up until something is slightly unusual.

An engineered system does the same thing operationally. Identify the intent. Establish what it is allowed to do about it. Check real availability. Book if it can. Write it into wherever you keep customer records. Move that person from enquiry to booked client. Send the confirmation. Decide whether a human needs to do anything afterwards, and if so, whose job it is and by when. Then watch that it happened.

The difference is invisible on a good day, which is precisely why it gets left out of the quote.

When the calendar is down

Now the calendar will not answer. Not your calendar exactly, but the service it lives on, which the system has to ask every time before it can promise anybody a slot.

The thin agent has two failure modes and both are bad. It invents an appointment that does not exist, because a model asked to book something will happily narrate having booked it. Or it dead-ends the caller, who now believes your business could not help them.

What should happen is unglamorous and entirely mechanical. Say plainly that availability cannot be checked at the moment. Take the caller’s details. Create a callback obligation. Attach it to a named person. Start a clock. Escalate if the clock runs out. The caller gets a slightly worse experience instead of a false one, and the business finds out that its calendar was down rather than discovering it from a customer standing in reception on Tuesday.

Anthropic’s own engineering guidance on building effective agents is blunt about where the effort goes: agents “can handle sophisticated tasks, but their implementation is often straightforward,” and because their autonomous nature carries “the potential for compounding errors,” the recommendation is “extensive testing in sandboxed environments, along with the appropriate guardrails.” The intelligence is not the hard part. The fence around it is.

Why so many of these die

This is not a niche concern, and there is a number attached to it. Gartner forecasts that “over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls.”

Read that as what it is. It is a prediction rather than a measurement, and the poll underneath it surveyed 3,412 webinar attendees, who are people already interested enough in the subject to attend a webinar about it. That is not a random sample of businesses. Treat the 40% as a considered opinion from people who watch this market, not as a finding.

What is harder to wave away is the reason given. Escalating costs, unclear business value, inadequate risk controls: not one of those is a complaint about the model. They are all complaints about the system around it, which is the list above.

Gartner also names the sales problem directly. It calls it “agent washing” — “the rebranding of existing products, such as AI assistants, robotic process automation (RPA) and chatbots, without substantial agentic capabilities”, and estimates that of the thousands of vendors selling agentic AI, only about 130 are real. Its analyst Anushree Verma puts the useful half plainly: “Many use cases positioned as agentic today don’t require agentic implementations.”

That last sentence is worth more than the forecast, and it is worth putting in plainer words: most of what is being sold to you as an AI agent does not need to be an agent at all.

The difference is real and Anthropic draws it precisely. A workflow is a system where the model and its tools are “orchestrated through predefined code paths” — the steps are decided in advance and written down. An agent is one where the model “dynamically directs its own processes and tool usage” — it works out its own steps as it goes.

Booking an appointment has known steps. Ask what they want, check the calendar, take the slot, confirm it, tell somebody. You do not need a system that reasons its way to a fresh approach on every call. You need one that follows those five steps reliably and knows exactly what to do when one of them fails. That is a workflow, and it is cheaper to run, more predictable in front of a customer, and far easier to fix at two in the morning.

An agent earns its extra cost when the steps genuinely cannot be known in advance. Most front desks are not that. Anthropic’s advice arrives at the same place from the other direction: find “the simplest solution possible, and only increase complexity when needed.” The word on the invoice should follow the work, not the other way round.

What to ask before you buy one

You do not need to understand the engineering to tell whether somebody else has done it. Six questions, and you can ask them on a call.

What is it not allowed to say? A vendor who has thought about authority boundaries answers immediately. One who has not will tell you how accurate the model is, which is a different question.

What happens when the calendar is down? If the answer is that it will not be, ask again.

Who owns a call it cannot finish? A name and a time, or nothing has been designed.

When does it stop following up? There should be a rule, and someone should be able to state it.

What can I see afterwards? If you cannot reconstruct what happened on a specific call, you cannot improve it and you cannot defend it.

Does this need to be an agent at all? The honest vendors will sometimes say no.

None of this makes the technology less useful. Always On Front Desk exists because the calls a small team cannot cover are real revenue, and covering them works. The argument is only that the covering is a system, not an appliance, and that the difference shows up on the bad day rather than the good one.

Which raises the question underneath all of this, and it is the subject of the next article: you cannot engineer any of the fifteen decisions above until somebody has written down how the business actually handles its phone today. Most owners have never done it. That is not a failure of technology, and no amount of technology substitutes for it.

Questions people ask