What we kept out of the AI, and why it matters
The risk: missing a tender
A tender notice lands in a shared inbox. If no one catches it, the business loses the chance to bid. Multiply that across hundreds of emails a month, mixed in with spam, portal noise, and false alarms, and the risk becomes routine. It’s a Tuesday.
That was the problem a client brought us: automate email triage, pull out the key details, and get everything into a central register, so no tender slips through.
The temptation: let AI run everything
The easy version of this story is to hand the AI the inbox. It reads the mail, decides what matters, drafts the replies, remembers the follow-ups. One model, one prompt, done.
That’s quick to build. It’s also fragile. Every deadline, every cost, every safety rail now lives inside a block of instructions that will change the next time someone tweaks the prompt or swaps models.
We didn’t build it that way.
The decision: AI handles judgement, code enforces rules
We treated the AI as one component in a larger system, not the whole system. The AI makes judgement calls. Code enforces the rules that can’t bend.
Tender notices arrive in a shared inbox. The system flags genuine tenders, extracts key details (reference, title, closing date), updates a register, and drafts a reply. A person reviews and sends it. As a tender progresses, Slack reminders fire at key deadlines.
Five constraints shaped everything:
- Mail is never deleted.
- Tender replies must never be auto-sent.
- Costs stay predictable.
- Reminders go out on time.
- The AI model will change. The business rules won’t.
The design: filter first, restrict actions, automate deadlines
Three moves do most of the work.
Filter first. Simple rules sort the inbox before the AI sees anything. Known junk senders get set aside for free. Known tender portals get flagged as likely matches, giving the AI a head start. Everything else goes to the AI to decide, because we’d rather pay for a check than quietly miss a tender. The block list keeps that cost in line and is easy to maintain: every sender added is one less email the model has to read.
Restrict actions. The AI works through a defined set of approved actions, each with its own checks. The reply action can only save a draft, never send. Anything the system can send is limited to an approved recipient list, enforced in code, not in a prompt. Coloured Outlook labels let the team track progress, but the automation doesn’t depend on them, so a label changed by hand can’t break the workflow.
Automate deadlines. You could ask an AI to track due dates and fire reminders. But “three days before the quote is due” is plain date arithmetic. A scheduled job checks the register daily and triggers the nudge. The AI might help word the Slack message. It doesn’t decide when that message goes out.
The logic behind all three: an instruction can be bypassed by a cleverly worded email or an unexpected model update. A missing capability can’t.
The result: faster improvement
Splitting judgement from enforcement had a side benefit we hadn’t fully planned for: speed. Because the AI’s instructions and the system’s rules could be tuned independently, we dialled in classification fast. By the second week in production, complaints about misclassified tenders had all but stopped.
The gap: send and forward remain available
One gap remains. The AI can still send and forward emails, because the broader system supports other workflows, like follow-ups. For tenders specifically, nothing in code stops those actions. Only the AI’s instructions, backed by the approved recipient list, keep them out of scope.
The fix: remove those permissions
That’s not good enough long-term. An instruction isn’t a guarantee. A missing permission is a guarantee. Our next step is removing send and forward from the tender workflow entirely, so the gap closes at the same layer as everything else: the code, not the prompt.
The lesson: prompts guide, architecture guarantees
Prompts tell an AI what to do. Architecture decides what it’s allowed to do. Those are different jobs, and mixing them up is where agent projects become fragile.
A few things worth taking from this:
- Decide which tasks need judgement and which need guarantees, before anyone writes a prompt.
- Put cheap, simple rules in front of any AI handling a high-volume inbox.
- If plain code can do a job reliably, like deadline math, don’t hand it to the model.
- Check regularly which critical rules live only in a prompt, and move them into the system.
- When you change AI models, retest the guarantees, not just the output quality.
So ask yourself: if the model changed tomorrow, would your business guarantees survive it?
Let’s make your AI workflows safer
Building an AI workflow or already running one in production? We can help you decide what belongs in the model, what belongs in code, and where critical rules may still rely on prompts.
Contact us to talk through your use case.