Section 1
Scope to a job with a checkable output
Write the scope as a sentence with a verifiable ending. Not helps customers. Instead: given an order number, states the current status and expected delivery date, using the fulfilment system as the only source. Test the sentence by asking what a wrong answer looks like. If you cannot describe one precisely, the scope is too broad to build against. Then list what the bot must refuse. Refusals are a feature and the cheapest reliability improvement available. A bot that handles four intents well and declines everything else beats one that attempts everything at moderate accuracy, because staff learn to trust the first and learn to check the second, which removes the saving.
Section 2
The four parts, and which one is hard
Interface. Where people meet it. Almost always best placed inside a tool the team or the customer already uses. Retrieval. The mechanism that puts your actual documents and records into the model's context. This is what makes the bot answer about your business instead of about businesses in general. Policy. The rules that constrain behaviour: what it may say, what it must escalate, what it never states without a source, tone, and the refusal conditions. Action. Writing something back into another system. This is the part that carries real risk and the part most likely to be underestimated. The hard part is almost never the model. It is retrieval quality and the action layer, which is where the engineering hours go.
Section 3
Grounding beats a bigger model
The most reliable improvement available is not a better model. It is a better corpus. A bot that answers from a curated set of current documents outperforms a bot with a larger model and a stale, contradictory knowledge base. Which means the highest-value work is unglamorous: find the three places the same policy is written differently, decide which is correct, delete the others, and give the bot only the survivor. Two practices follow. Cite the source in the answer, so a reviewer can verify in a second rather than a minute. And instrument for the case where retrieval returns nothing relevant, because that is exactly the moment an ungrounded system invents something. The correct behaviour there is to say so and hand over.
Section 4
Evaluate before you launch, using real cases
Build the evaluation set before the bot. Pull fifty real cases from your ticket history, including the ambiguous ones and the ones staff got wrong. Write the correct answer for each. That file is the specification, the regression test, and the argument you will use with a sceptical team. Run it before launch, after every prompt change, and after every model change. Silent model updates are common and they move behaviour. Then run in shadow mode: the bot drafts, a person sends. You get accuracy data without exposure, and the edits people make are the highest-quality training signal you will get about what wrong looks like in your business. Move to autonomy on a defined intent only after the edit rate on that intent has been low for a sustained period.
Section 5
Permissions, logging, and the off switch
NIST frames AI risk management around trustworthiness, design, evaluation, and use, and for a bot that is mostly about permissions. Give it read access broadly and write access narrowly. Scope every credential to the minimum: the specific table, the specific queue, the specific action. Put a rate cap on anything it can do repeatedly. Use idempotency keys where a repeated action would create a duplicate charge or record. Log the question, the retrieved sources, the version, the answer, and the human edit. Without those five you cannot debug a complaint, and you cannot improve the retrieval that caused it. Keep a kill switch a non-engineer can operate, and test it. An off switch that requires a deployment is not an off switch.
Section 6
Running cost and the metrics that matter
A bot is not a project with an end date. Budget for maintenance: the corpus goes stale, connected systems change their fields, the model provider updates, and intents drift as your product changes. Assume ongoing hours, not a one-off build. Measure containment against correctness, never containment alone. Track accuracy on the evaluation set, the human edit rate in shadow mode, escalation rate and reason, retrieval hit rate, cost per resolved case, and time from a wrong answer to someone noticing. If the edit rate is high, the problem is nearly always retrieval or scope rather than the model. Fix the corpus and narrow the job first. For a worked example, see [Startup Success: How AI Automation Transformed Our Business](/blog/startup-success-how-ai-automation-transformed-our-business). For the stack, see [Top AI Automation Tools for Startups in 2026](/blog/top-ai-automation-tools-for-startups-in-2026); for how a persuasive internal case gets made, [Lessons from Great Storytellers in Business History](/blog/lessons-from-great-storytellers-in-business-history).