What is in the stop rule template?
The template has eight short sections you can fill in for any AI agent or chatbot, whether we build it or not:
- Basics: the agent's name, channels, owner and purpose.
- Systems and data: which systems it can read or write, and data it must never ask for or repeat.
- Alone: low-risk, reversible actions the agent may take without approval.
- With approval: actions the agent drafts and a person confirms, with who approves and how fast.
- Hard stops: a checklist of situations where the agent stops and hands over immediately, from "customer asks for a human" to legal, medical and money topics.
- Handover package: what the person receives when the agent stops: conversation, record link, data collected, reason and suggested next step.
- Tone and language: languages, voice, and whether the agent identifies itself as automated (we recommend it does).
- Success measure and review: what you'll measure, how often you review, and a change log.
Why write a stop rule before building an agent?
Because deciding boundaries after something goes wrong is too late. Writing the stop rule first forces the useful conversations: which actions are reversible, what a mistake would cost, and who owns the review. It also makes building faster, since the developer knows exactly what the agent should and shouldn't do. Read the full reasoning in our human-in-the-loop guide.
How do you fill it in?
- Start with the hard stops. They're the easiest to agree on.
- List every action the agent might take, and put each in "alone" or "with approval" using three questions: is it reversible, what if it's wrong, and is there a clear rule?
- Write the exact message the agent sends when it stops, in your own voice.
- Decide who receives handovers during and outside working hours.
- Set a review date. The first month's escalations will teach you a lot.
Can I see a completed example?
Yes. Our support triage agent worked example shows a filled-in stop rule for a fictional D2C support team, and the WhatsApp lead pilot example shows one for sales enquiries. Both are illustrations, not client projects.
Which file formats are available?
The template is a plain Markdown file (.md) and the same content as .txt. Both open in any text editor, can be pasted into Google Docs, Notion or Word, and work well with tables in Markdown-aware tools.
How do we apply this in client work?
Everything on this page feeds into how we run pilots. We start with a consultation to understand the process and the people involved, then write a one-page scope: the trigger, inputs, steps, outputs, a success measure and a stop rule that says what the agent may do alone, what needs approval and when it must hand over. We build inside the tools you already use, test on real or realistic cases including awkward ones, and review the results with your team before anyone talks about expanding.
We keep a few habits on every project: we never publish invented results, we label examples as illustrations, we list third-party costs separately, and we say so plainly when something isn't worth automating yet. If that sounds like the kind of partner you want, read the pilot process or message us on WhatsApp.
What should you prepare before talking to us?
You don't need a technical brief. A useful first conversation needs only a few things, and gathering them is valuable even if you never work with us:
- The process in plain words: what triggers it, who does what, and where it usually goes wrong.
- Rough volumes: how many messages, orders, tickets or invoices per week. A one-week tally is enough.
- Your tools: WhatsApp app or API, CRM, sheets, accounting or helpdesk software, including versions or plans where you know them.
- Three real examples: typical messages or cases, plus one awkward one, with personal details removed.
- What must never happen: the mistakes that would hurt most. These become the first lines of your stop rule.
- An owner: the person who will review the workflow once it runs.
Send these on WhatsApp or by email, or run the pilot scorecard first.