The hardest document in an ai247 engagement is not the architecture. It is one page that says what the agent is never allowed to do.
We write it before anything is built, and getting it agreed usually takes longer than the client expects — because it forces a conversation the organisation has been comfortably avoiding.
Three questions, and none of them are technical
What may it do with no human in the loop? Answering a question is different from issuing a refund, which is different from writing to the ledger. The line is a business decision, not an engineering one, and the person who owns the consequence should draw it.
What must it refuse, even when it is confident? Confidence is not the safeguard people assume it is. A support agent handling clinical questions is unacceptable regardless of how good the answer is, so the refusal is enforced in the guardrail layer, not left to the model's judgement in the moment.
What happens when it is unsure? "Escalate" is not an answer. Escalate to whom, with what attached, and what does the customer see in the meantime? An escalation path that drops someone into an unattended queue is worse than no agent at all.
Why it goes first
Write capability first and the guardrails become subtraction. Every constraint feels like losing something, and the conversation turns into negotiation against a system that already exists in everyone's head.
Write guardrails first and capability becomes addition. You start from what must be true and build up to what is useful. The same final scope arrives with much less friction, and the boundary ends up somewhere the client actually chose.
There is a design consequence too. Constraints written first get enforced structurally — in the tools the agent is given, the permissions it holds, the approval gates in the path. Constraints written after tend to get enforced in the prompt, which is to say, hopefully.
The part that gets skipped
Escalation summaries.
When an agent hands a case to a human, what it writes is the whole experience of working with it. A bad handoff is a ticket that says "customer needs help" and forces someone to read the entire thread. A good one states the question, what has been established, what was tried, and why it stopped.
Support teams routinely tell us the agent's handoffs are better than the ones they get from other humans. That is not a model capability. It is a spec somebody bothered to write.
What it looks like when it works
On one engagement, the guardrail document said the agent could not rebook a freight lane or take any action with a cost implication without a controller approving it.
That constraint held for the entire engagement. It is on the case study as a result — zero rebookings made without approval — which reads like a strange thing to be proud of until you consider the alternative: a system that was mostly careful, and an operations team that could never quite stop checking.
An agent your team has to double-check has not saved anyone anything.