How to let an AI agent act on your customers without losing control
governance · · 5 min
Let the agent propose and never execute. A separate decision engine answers permit, hold or deny against rules you wrote, and only a clean permit reaches your systems. If the engine times out or errors, nothing runs. Run the rules in shadow mode on real traffic and read the verdicts before you enforce any of them.
Why the agent should not hold the keys
An AI agent that can both decide and act has one failure mode: whatever it gets wrong, it does. Asking the model to be careful does not change that, because the model is the thing being constrained. The fix is structural. The agent holds no credential and no connector, and the only thing it can do is name an action.
On OnDuty that is the whole contract. An agent calls one function, propose_action, with six fields: the abstract action, its structured parameters, the agent's id, the workspace id, the context it saw, and an idempotency key. The action is never a vendor name, and the parameters are validated, so the model does not invent a payload for your systems. What comes back is a verdict, not a result.
The four stages, always in this order
Propose
The agent names an action and nothing more. It cannot reach a connector or a credential, and a test in the suite fails if an agent is given a way to build an executor.
Evaluate
The decision engine, Selah, checks the proposal against your policies and answers permit, hold or deny. It never executes. OnDuty never decides. Neither side can do the other's job, which is the point.
Execute
Only a clean permit reaches the connector. Retries carry the same idempotency key, so a delivery sent twice runs once.
Record
Every verdict, permitted or refused, goes to an append-only, hash-chained trail with a verify endpoint. Refusals count as much as permits, because what the system was stopped from doing is the evidence a reviewer wants.
What happens when something fails
A governance design is judged by its failure paths. These are the rows on the how it works page, each one runnable there.
- The engine times out, errors or is unreachable: nothing executes and the verdict is recorded as a deny. A slow answer is not a permit, and an error means no rules were applied.
- The verdict is hold: the action waits for a person, with the proposal, the context and the rule attached. A hold nobody answers for a day becomes an insight, so it surfaces rather than ages, and nothing expires into being sent.
- The verdict is deny: the action stops and is recorded as denied.
- The connector fails after a permit: three tries with a backoff, then the dead letter. The decision was clean, only delivery failed.
- The connector refuses for good: one try, then the dead letter, because a retry cannot fix a refusal.
What a person sees when an action is held
A hold carries the proposal, the context the agent saw and the rule that held it, so the reviewer decides on evidence rather than on a notification. Approving releases that one action and resumes it without a second trip to the engine. Rejecting or letting it expire sends nothing.
Writing the first rules
Start narrow. A wrongly held action costs a person a minute, while a wrongly permitted one reaches a customer, so a rule's decision is always hold or deny, never permit. A rule can tell a customer conversation from a team one, and it can read the workspace's local hour and weekday. A transport detail such as the WhatsApp number never reaches the engine, so a rule cannot treat one provider differently from another.
Shadow mode: prove a rule before you enforce it
A rule that has never met real traffic is a guess. In shadow mode the engine evaluates every action against your rule and writes down what the rule would have said, but answers permit, so the action runs exactly as it would have without the rule. Shadow is not a dry run, and anyone who calls it one is telling you nothing will execute when something will.
The pilot on the enterprise page is built around this. Week one scopes one workflow, its allowed actions and the guardrails. Weeks two to four connect read-only and run in shadow. Weeks five and six turn shadow off on the agreed workflow only, and from then the rules hold and deny. The record of those weeks is what you hand to whoever approves the rollout.
Until shadow is off, no workspace is called governed in production. We say that on purpose.
Who is allowed to say yes
A person. No permission anywhere on the platform accepts a decision, answers a hold or executes, and that holds for an outside assistant connected over the Model Context Protocol too. An assistant such as Claude or ChatGPT can read the Brain, add a memory with evidence and propose a decision. It cannot approve one.
That boundary is built and tested. The sign-in flow from Claude and ChatGPT has not been exercised against a live connection, so the honest word is built, not proven.
What is not done
There is no SOC 2 or ISO 27001 audit, so we do not call these controls certified. Agents answering from inside your network are not built: a runner can register on your machine, but conversations are still processed in OnDuty's cloud. On Enterprise, we write the actions and guardrails with you, and until they exist, rules propose only human work.
Questions
Can an AI agent be fully autonomous with this design?
The agent itself never executes. A permitted action runs without a person when your rules permit it, a held action waits for a person, and a denied action stops. Autonomy is earned per action, and the record of every verdict is kept.
What happens when the model is uncertain?
A confidence score is not a permission. Your policy permits, holds or denies, and a held action goes to a person with the full proposal.
What happens if the decision engine is down?
Nothing executes. A timeout, an error and an unreachable engine are all recorded as a deny, because governance is never traded for speed.
Does shadow mode protect me while I test?
No. In shadow the engine answers permit and the action runs as it would have without the rule. The rule's verdict is only written down. Shadow tells you what a rule would have done, so read a week of it before you enforce anything.
How long does it take to set up?
Starting is free and needs one system and one person. Governing a real workflow is a pilot: six weeks, one workflow, one team, with success criteria written before week one.
What does it cost?
Which plans carry the gate is in the compare table on the pricing page, and prices are read live from Stripe rather than repeated here. Enterprise is negotiated, because residency and guardrails are written with you.
When would you tell me not to use it?
If you need the agent to answer from inside your own network, that is not built. If you need a third-party audit report before you can sign, there is none yet. And if your agent only answers a fixed list of questions and never acts on anything, a gate is more than you need.
Updated