Not with an outage. They fail by producing plausible answers nobody checks, until someone notices the support bot has been confidently wrong for six weeks. The engineering that prevents that is unglamorous and it is most of the job.
Two things, and only one of them is the API bill. The API bill is usually the smaller number and it is easy to forecast: it scales with how much text goes in and out, and it drops sharply once you cache the parts of the prompt that never change.
The larger cost is upkeep. A bot that answers questions about your products is wrong the day your products change. Someone has to notice, and something has to be in place that tells them. We build that in from the start — a set of questions with known-good answers that runs on every change, so a regression shows up as a failing check rather than a customer complaint.
If a proposal quotes you an API cost and says nothing about evaluation, it is quoting you the cheap half.
An agent earns its complexity when the steps are not known in advance. If the task is 'read this invoice, pull out five fields, write them to a table', that is a script with a model in the middle, and it will be faster, cheaper and easier to debug than an agent.
An agent makes sense when the path branches on what it finds — when handling a request might mean checking stock, or issuing a refund, or escalating, and which one depends on the answer to the previous step. That is genuinely hard to write as a flowchart and genuinely well suited to a model with tools.
We will tell you which one you have. Reaching for the more impressive architecture when the simpler one fits is how projects get expensive.
You write down what a good answer looks like before you build, and you keep checking against it.
In practice that means a reference set — real questions from your actual users, with the answers you would want. It starts small. Twenty cases is enough to catch the obvious failures, and it grows every time something goes wrong in production, because the thing that went wrong becomes case twenty-one.
On top of that sits monitoring for the failures that do not show up in testing: the model refusing things it should handle, latency creeping up, costs drifting. None of this is exotic. It is the same discipline as any other production system, applied to a component that fails in softer ways.
Twenty minutes. If it isn’t work we should take, we’ll say so on the call.
Also