You start most mornings the same way. Forty emails, half of which need something looked up before you can answer. Three systems open in tabs: the job software, the accounting package, the shared calendar. An hour and a half of reading and cross-referencing before a single decision gets made, and most of those decisions, once the facts are in front of you, take about five seconds.
That hour and a half is what an AI operations agent is for. Not to make the decisions. To do the reading, the looking-up, and the cross-referencing, and to put the facts and a proposed action in front of you so that the five-second decision takes five seconds.
This article explains what an operations agent is, how to build one that you can actually trust, the ladder it climbs from “only reads” to “acts alone,” the tools it gets and does not get, and the logs that make the whole thing defensible.
What this actually is
An AI operations agent is a large language model (an LLM, the kind of AI that reads and writes text) that has been given a goal, a set of tools it may use, and a schedule. The tools are things like “read the inbox,” “look up a customer in the CRM,” “fetch open invoices,” “check the calendar,” and “draft an email.” On its schedule, or when something arrives, it works through what is new, uses the tools to gather what it needs, and produces a proposal: here is what came in, here is what I found, here is what I suggest.
The analogy is a good operations assistant on their first month. You would not let them send money or promise a customer anything on day one. You would let them read everything, pull the file, and put a note on your desk saying “the Hendersons are asking about the delayed delivery; the shipment left Tuesday and tracking says Thursday; suggested reply attached.” Over months, as their notes proved reliable, you would let them send the routine ones themselves. The agent works the same way, except that the trust decisions are explicit settings rather than instincts.
The distinction between this and a plain workflow automation is laid out in AI Agents vs Automation: Which One Your Business Needs. The short version: a workflow follows a fixed script; an agent decides which tools to use based on what it finds. That flexibility is the point, and it is why the guardrails below exist.
How to build one that earns trust
1. Define the job narrowly before you define the agent
“Handle operations” is not a job. “Every weekday morning, read the shared inbox, identify anything about a delayed order, look up the order and the shipment, and draft a reply for approval” is a job. Start with one narrow, frequent, annoying task where the facts live in systems the agent can reach and the decision is usually obvious once the facts are gathered.
A narrow job has a short list of tools, a small set of possible actions, and a clear definition of done, which means it can be tested, logged, and judged. Broad agents fail broadly.
2. Climb the trust ladder one rung at a time
This is the core of the whole design. There are four rungs, and the agent starts on the bottom one.
Read only: the agent reads and reports. It tells you what it found and what it would have done, and does nothing. You compare its proposals to what you actually did. This rung lasts until you stop finding surprises, typically a few weeks.
Draft: the agent prepares the action (the email, the work order, the calendar entry) and a person approves, edits, or rejects each one with a single click. Most operations agents should live here for a long time, and many should live here permanently.
Act with approval: the agent executes routine cases within tight limits (this category, under this amount, to these recipients) after a person approves a batch, and a person reviews a sample of what was done.
Act alone: the agent executes without review for a narrow, well-understood class of task with a long track record. Few tasks earn this rung. Anything involving money, commitments to customers, or deletion should not.
Promotion up the ladder is a decision you make from the logs, not one the vendor makes from confidence. Demotion should be one setting away.
3. Give it read tools freely and write tools grudgingly
A tool, in this context, is a specific capability the agent is allowed to call: look up a customer, list open invoices, read a calendar, search the inbox. Reading tools are low risk and should be generous, because the value of the agent comes from how much context it can gather. Give it the CRM, the accounting package’s read access, the calendar, the job system, and the inbox.
Writing tools are where the risk lives, and each one should be added deliberately, on its own rung of the ladder, with its own limits. “Draft an email” is safe. “Send an email” is a rung higher. “Issue a refund” may never be granted at all, with the agent instead proposing it to a person who holds that power. The standard way to connect an agent to tools across many systems is MCP, explained in MCP (Model Context Protocol) Explained for Business Owners, and the permission model for those tools is in AI Agent Permissions: Least Privilege for Business AI.
4. Make every proposal a structured form, not a paragraph
The agent’s output should be fields, not prose: what it is about, which customer, which record, the proposed action from a fixed list, the draft text if any, and a confidence level. The mechanics of getting a model to return reliable fields are in LLM Structured Output and Tool Calling, Explained Plainly.
Structured proposals make three things possible. A person can scan twenty of them in a minute. Rules can check them before anything happens (the amount matches the invoice, the recipient is a real customer, the action is on the allowed list). And they can be counted, so you can see over a month how often the agent was right, which is how you decide about the next rung.
5. Give it your rules in writing, and keep them where you can read them
The agent needs to know how your business works: what counts as urgent, who handles what, which customers get special treatment, what tone to use, what it must never say. These go into its standing instructions, a plain-language document that is part of the system and lives in version control (a history of every change, so you can see what was said to the agent when).
Write these instructions as you would a memo to a capable new hire. Be concrete. “Never quote a delivery date the shipping system has not confirmed” is a rule the agent can follow. “Use good judgment about dates” is not. When the agent does something wrong, the fix is very often a sentence added to this document, which is why you want it readable by the owner, not buried in code.
6. Build the approval surface where the person already works
The agent’s proposals have to land somewhere a person will actually look: a morning email digest with approve and edit links, a channel in Slack or Teams, or a simple page in your internal tool. Approving should be one click, editing should be easy, and rejecting should ask for a one-line reason that gets fed back into the log.
If approving is slower than doing the task by hand, nobody will use it. In our experience the digest-with-buttons pattern is the one that sticks, because it fits a morning routine that already exists.
7. Log what it saw, what it did, and why
Every run should record: the trigger, every tool call and its result, the agent’s reasoning, the proposal, what the person did with it, and what actually happened. This is the audit trail, and it does three jobs. It answers “why did it do that” when something is odd. It provides the evidence for moving up or down the ladder. And it is what you show a customer, an accountant, or a regulator if anyone ever asks.
In the systems we build, the log exists before the agent does anything real, and a non-technical person can read it.
8. Put hard limits outside the agent’s reach
Some limits should not be instructions the agent is asked to follow; they should be walls it cannot cross. A cap on how many emails it can send in a day. A rule that any amount over a threshold goes to a person, enforced by the workflow around the agent, not by the agent’s good behavior. A kill switch that stops it entirely. A separate login for the agent in every system, so its actions are distinguishable from a person’s and its access can be cut in one place.
The reason is that a model can be talked into things, including by text inside an email it was asked to read. The walls hold even when the model does not.
Picture a business like this one
The business below is a composite of the kind of company that writes to us, not a client. The numbers describe the shape of the problem, not a case study.
Picture a business like this one: a regional electrical contractor with 45 staff, an office manager, and a shared operations inbox that receives quote requests, scheduling changes, supplier confirmations, and customer questions. The office manager spends the first two hours of every day reading, looking things up, and answering. Routine questions (“is my job still on for Thursday,” “has my invoice been paid”) are the majority, and each one needs a lookup.
A contractor like this would build an operations agent in stages:
- Read tools first: the inbox, the job schedule, customer records, and invoice status, all read-only, through a connection the office manager can see and revoke.
- Standing instructions written with the office manager: how to tell urgent from routine, what may never be promised, the tone of a reply, which customers go straight to the owner.
- Rung one for three weeks: each morning the agent produces a digest of what came in overnight with a proposed category and, for routine questions, a draft reply built from the actual schedule and invoice data. The office manager compares it to what she would have done.
- Rung two: the digest gains approve and edit buttons; approved drafts are sent from the office account. Scheduling changes become draft entries in the job system for approval. Nothing is sent or changed without a click.
- After two months of logs, routine confirmations of schedule and payment status move to rung three: sent automatically, capped at a daily number, with a sample reviewed weekly. Quotes, complaints, and anything mentioning money stay on rung two indefinitely.
What changes: the office manager’s two hours become twenty minutes of approvals, customers get answers before nine, and every reply the agent ever drafted, with the data it used, is in a log she can search.
What it costs to run
The model is the main usage cost, and for this kind of work it is modest. An agent that processes a few dozen messages a day, each with a handful of lookups, typically costs somewhere in the tens of dollars a month with the current mainstream models, more if it reads long documents every time.
Around the model: a small server or workflow platform to run it on ($10 to $50 a month), whatever your existing systems charge for API access (most CRMs and accounting packages include it; some charge for the tier that has it), and a transactional email service if the agent sends mail, which is often free at low volume. Add a few hours a month of a person reviewing logs and adjusting instructions.
The mistakes we see most
Starting at the top of the ladder. An agent that acts alone from day one has skipped the only phase where its mistakes are free.
A broad job. “Handle the inbox” gives the agent a hundred possible actions and you no way to judge any of them. Start with one task.
Write access by default. Every tool the agent can call to change something is a door. Add each one on purpose, with a limit.
Instructions buried in code. The owner should be able to read and change what the agent has been told. A one-sentence fix should be a one-sentence fix.
No log, or a log nobody can read. The log is the safety mechanism, the promotion evidence, and the answer to “why did it do that.”
When to bring in help
The read-only rung of a narrow agent is within reach of an off-the-shelf tool. Several inbox and CRM products now offer a summarizing assistant, and the inbox-specific version of this pattern is in AI Email Triage: Classify, Route, Draft, Approve Without Regret. If your systems are common and your needs are simple, try that first.
The moment the agent needs to gather from several systems, propose structured actions, live inside an approval flow, and climb the ladder with real limits and a real log, it is a build. That is developer work, and the walls in step 8 in particular are not something to improvise.
Levelbrook builds operations agents for businesses this way: narrow job, trust ladder, structured proposals, approval surface, full log, hard limits, at a fixed price from a written scope, running in accounts you own. If your mornings start with an hour of looking things up, the form below is how a conversation starts.