Build it with AI
Create an AI operator that works inside a bounded business workflow.
Build the interface and operating context for AI that can understand connected information, propose actions, and participate in traceable execution.
Introduction
What an AI operator has to hold.
Most teams end up with an AI operator the same way: AI used to draft text, with a person still performing every action it suggests. A general assistant is useful for drafting and analysis indefinitely. It stops being enough the moment the valuable part is the action rather than the answer, because an answer still leaves the work to be done by a person.
The model produces a suggestion and a human does the work, so the time saved is drafting time rather than operating time. There is no defined set of actions the operator may take, no precondition on each, and no record of what it did that a human can review afterwards.
What follows covers building an AI operator: the records it holds (the tasks delegated, the context each needed, the action taken, and the review decision), the systems it reads (CRM and Email), and what it does not fix.
The problem
Chat that can explain the work but not do it.
Chat interfaces model the conversation and treat tool use as an extension, so the action space is implicit and unbounded. Workflow tools define actions precisely and cannot handle a request phrased in a way the designer did not anticipate.
The records are the tasks delegated, the context each needed, the action taken, and the review decision, and the authoritative copy of most of them already lives in CRM or Email. The operator reports the task complete, the downstream system shows no change, and the difference is a failed call that was summarised as a success.
The cost is not the inconvenience: AI spend buys faster drafting and no change to throughput.
You're likely here because
- Every useful answer ends with a person doing the actual work
- The model produces a suggestion and a human does the work, so the time saved is drafting time rather than operating time.
- When it is wrong, AI spend buys faster drafting and no change to throughput
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Operator interface
- • Action queue
- • Audit views
Operated through Grow
- • Follow-up actions
- • Scheduling
- • Pipeline execution
Systems it reads
- • CRM
- • Calendar
The record model
What the action space has to define.
- Enumerated action
- Each action the operator may take, listed. An implied action space is one you discover in production rather than one you designed.
- Precondition per action
- Held as a condition rather than as an instruction in a prompt, so the constraint holds regardless of how the request was phrased.
- Reversibility note
- Per action, because reliability on reversible actions is not evidence about irreversible ones and the costs are not comparable.
- Confirmation state
- What awaits a human and what does not, with the confirmed-without-amendment rate driving any change to that boundary.
- Acting-for identity
- The operator holds exactly the access of the person it acts for. Anything broader is an access-control bypass wearing a productivity costume.
- Downstream effect, verified independently
- Because a confident summary of a failed call is the characteristic failure and it is invisible from the conversation.
- Audit record
- What was done, by whose authority, with what effect — so expanding scope is a decision based on evidence rather than impression.
How it runs
From conversation to a bounded action space.
Step 01
Describe what an AI operator has to do
Enumerate the actions the operator may take and the precondition for each. The action space is the design; the conversation is an interface to it.
Step 02
Connect the systems of record
The systems the operator acts on are reached through governed, permission-scoped connectors, so the operator holds no more access than the person it acts for.
Step 03
Build the operating surface
An operator interface, an action queue where proposals await confirmation, and an audit view showing what was done, by whose authority, and with what effect.
Step 04
Start narrow
One action, with its precondition, its confirmation step, and its audit record. A single well-bounded action in production teaches more than a broad agent in a demonstration.
Step 05
Route the exceptions
Anything outside the defined action space or failing a precondition escalates to a person with the reasoning attached rather than being attempted.
Step 06
Measure tasks completed without a human performing the execution step
Measure the share of proposed actions confirmed without amendment. It is the direct measure of whether the operator understands the job, and it is available from day one.
Implementation path
Giving an operator a job with edges.
- 01
Write the action space down before anything else, with a precondition and a reversibility note against each action. Unbounded action spaces are the reason these projects are stopped rather than the reason they fail.
- 02
Baseline how much time goes into the doing rather than the deciding for the target workflow. That is the recoverable portion.
- 03
Require confirmation on everything initially, and remove it only for actions where the confirmation rate has been high and the action is reversible.
- 04
Verify the downstream effect rather than the operator’s report of it. Reporting success on a failed call is the characteristic failure mode and it is invisible from the conversation.
- 05
Build the narrowest useful version first: one bounded, reversible action executed end to end with review before it lands.
- 06
Writing the action space with preconditions and reversibility is the design and takes a day or two. One action, confirmed, in production is two to three weeks. Independent verification of downstream effects is not optional and should be built alongside the first action rather than added when something goes wrong.
- 07
After one action runs confirmed for a month, add the second and consider removing confirmation on the first if it is reversible and the amendment rate is low. Scope expands one action at a time, on evidence.
Controls
Controls that matter.
Control 01
An explicit action space with a precondition per action, so capability is defined rather than emergent
Control 02
Permissions scoped to the person the operator is acting for, never broader, so an operator cannot become a route around access control
Control 03
Downstream effects verified independently of the operator’s own report, since a confident summary of a failed action is the standard failure
Examples
Three tasks that get genuinely handled.
The answer that still needed doing
A bounded action space means the operator completes the task rather than describing it, which is the entire difference between an assistant and an operator.
The action that should not have been available
Preconditions on the action rather than instructions in a prompt mean the constraint holds regardless of how the request was phrased, which is the only version of a constraint that is worth anything.
What did it do last week?
An audit view of actions with their authority and effect is what makes expanding the operator’s scope a decision based on evidence rather than on impression.
How it goes wrong
Three ways operators cause damage.
Tools are attached and the capability is whatever emerges from them.
Enumerate the actions with preconditions. An emergent action space cannot be reviewed, cannot be bounded, and is discovered by the incident rather than by the design.
The operator reports success and the downstream system shows no change.
Verify effects independently. The operator’s own account of what it did is the one piece of evidence that cannot be used, and it is the one most systems rely on.
Confirmation is removed across the board after a good month.
Remove it only for reversible actions with a high confirmed-without-amendment rate over real volume. Irreversible actions keep confirmation permanently, whatever the track record.
Limitations and considerations
What an operator should not be given.
- An operator should not hold permissions beyond the person it acts for. Anything else turns a productivity tool into an access-control bypass, and it will be used as one.
- Confident summaries of failed actions are the characteristic failure of this pattern. Verify effects downstream; never treat the operator’s own report as evidence that something happened.
- Irreversible, destructive, or externally visible actions warrant human confirmation regardless of how reliable the operator has been. Reliability on reversible actions is not evidence about irreversible ones.
- If the valuable part is the answer rather than the action, an assistant is the right tool and the action space is unnecessary risk. If the workflow is irreversible or externally visible throughout, the confirmation overhead will exceed the saving.
- Connector coverage varies: CRM, Email, Calendar are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build an AI operator: common questions.
How is this different from a chatbot with tools?
The action space is enumerated with preconditions rather than implied by whichever tools happen to be attached. That distinction determines whether capability is something you designed or something you discover in production.
How much should it do without confirmation?
Start with none, and remove confirmation only for reversible actions where the confirmed-without-amendment rate has been high over real volume. Irreversible actions keep confirmation permanently, whatever the track record.
What access should it have?
Exactly the access of the person it is acting for, scoped to the records the workflow needs. An operator with broader permissions than its user is an access-control problem wearing a productivity costume.
How do we know it is working?
By the share of proposed actions confirmed without amendment, and by verifying downstream effects independently. The operator’s own account of what it did is the one piece of evidence that cannot be used.
What should the first version contain?
One bounded, reversible action executed end to end with review before it lands. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure tasks completed without a human performing the execution step against the baseline taken before anything changed.
Related pages
Keep exploring
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build an AI operator around the process you actually run.
Enumerate the actions and their preconditions first, confirm everything initially, and verify effects downstream rather than trusting the report.