Before you connect an agent to your ERP there are two things to settle: what it is allowed to touch, and in what order. There are three rungs, read, alert and execute, and each one saves you more and can cost you more. What follows comes out of four systems we run and keep running: one in public use, two in production and one being rolled out.
What an agent is allowed to touch at each rung
Three questions separate one rung from the next, and not one of them is about the model.
Who starts it. The first agent starts when you ask it something. The second and the third start on their own: a clock, or a message arriving.
What it leaves behind. The first leaves an answer. The second leaves a warning, addressed to whoever runs that account or that shift. The third leaves the work done.
How long its list of allowed actions is. For the first, a short list the company wrote down in advance, or none at all. For the second, one item: it opens the incident and stops. For the third, the whole job except the last step. Each one is allowed one thing more than the one before, and in every case somebody wrote the list before the agent ran.
| starts on | leaves behind | may do | |
|---|---|---|---|
| Read | you asking | an answer | a short list, or none |
| Alert | a clock | a warning | open the incident |
| Execute | a clock or a message | the work done | all but the last step |
That is the entire difference. A real system can carry more than one of those three permissions, and three of our four do. That is what the table of the four systems, further down, shows, and it is also where the order for granting them comes from.
How what the AI knows about a company gets written down is a separate text. This one is about the other half: what it is allowed to do once it knows.
Read: the agent answers and touches nothing
A query agent answers questions about a company with that company's data in front of it. That is the whole job, and the interesting part is what "in front of it" means: it is connected to the ERP and to the rest of the systems live, so the question is answered where the data lives rather than from a document somebody wrote months ago.
That changes what can be asked of it. A general-purpose model is good at what the world already knows. It cannot answer anything that depends on your customers, your catalog or your warehouse, because it has never seen them.
The B2B sales book has one inside its dashboard. It answers in plain language with the same figures the screens show, and every answer shows where each number came from.
It is the class everyone has seen in a demo. In its pure form it changes nothing, and that is why it needs no permission. It also carries the limit that matters most: it does nothing until somebody asks. If nobody asks about the order that got stuck, the order stays stuck.
Ours runs at a specialty retailer and is open to any visitor on the shop's own site, with no sign-up. Its published limit reads, in our translation from the Spanish original: "The agent operates inside the shop. It answers about its products and conditions and launches only the procedures defined by the company."
What an agent that only reads is used for
A query agent serves two different audiences, and they are worth keeping apart. Facing inward, the one in the B2B sales book answers whoever runs the operation. Those are the two conversations shown above: questions that cross several systems and that nobody can answer from memory.
Facing outward, in our public case, it answers any visitor to a specialty retailer: terms, lead times, warranties, and the status of an order; it finds and shows the catalog without sending anyone to a search box; and it answers compatibility questions, which the case page calls the typical question in that industry.
It does a fourth thing that goes beyond answering, which is the reason this agent is not purely the first class: it starts a return. That is a procedure launched inside the company's own systems, connected to its ERP, and the shop decided in advance which procedures it may launch.
So this system is two classes at once: it answers, and it has been allowed one action. Two others of ours stack classes too. The warehouse one does not: it only alerts. The table of the four systems, further down, puts them one beside the other.
Who computes the figure, the code or the model
The obvious objection to a query agent is that the model makes the number up. That has a checkable answer, and what gives it is where the arithmetic is written.
In the B2B sales book dashboard, which is the system we measured, the arithmetic sits outside the model. We counted it on August 29, 2026, in the code that renders that dashboard, treating as an operation each aggregation that produces one of the figures on screen: 87 operations, and not one that talks to a model.
And there is a check you can run yourself, without opening our code.
Every answer shows where each number came from. The table and the chart come out of those operations, and the text alongside them is written by the model, so the figure that counts is the one in the table. Anyone can hold one against the other right there on screen.
Alert: the agent watches and moves nothing
A monitoring agent does not wait for the question. It checks a condition on a schedule and, when the condition holds, it tells whoever runs that account or that shift.
That condition is the product, and it cannot be bought off the shelf. In a manufacturer's B2B sales book, the buying rhythm belongs to each customer and is measured over that customer's own last two years. When an account goes twice its own rhythm without ordering, the alert fires, ranked by amount.
The arithmetic is small enough to write out. Take a customer whose orders over two years land about every 18 days: the alert for that account waits until day 36. Take another that orders every 90 days: the same rule waits until day 180, and says nothing on day 36. Those two numbers are there as an example; the rule they run through is the published one.
There is no single number that means "this customer is leaving." A customer that orders weekly and a customer that orders twice a year are both healthy, and both are in trouble at completely different points on the calendar. The threshold has to be personal.
Personal means computed from each account's own history and recomputed as that history moves.
In that same nightly pass, each customer also gets a health score from 0 to 100 with its reasons: recency, frequency, amount, trend, and regularity. A monthly snapshot is frozen, so the score can be read as a trajectory.
The sales book also answers: the query agent described earlier lives inside this monitoring one, in the same dashboard.
The case page publishes the size of what is watched: more than 14 million sales lines and 840,000 profiles recalculated a month. That is the surface swept every night. And what comes out of sweeping it is the alert: it reaches the salesperson with the customer, the reason and the amount already prepared, before anybody asks for it.
What an agent that only alerts is used for
In the warehouse it is the same idea aimed at a different object. Twenty-four rules ship as standard and run over the warehouse's live data. Four of them are named publicly: orders on hold, abandoned picking and open replenishments. The fourth is orders that exist in the ERP and never reached the warehouse. The figure above shows a fifth: locations that do not square.
That last one is the interesting one, and neither system is wrong on its own. The ERP is right that the order exists. The warehouse management system is right that it has nothing to do. The order only appears as missing when somebody puts the two side by side.
Before the shift starts nobody does. The agent does it without rest, and each incident it opens comes with the exact list of affected orders, with the record and an export. The detection is done by the data; the write-up is done by the model, for whoever has to read it. The alert is logged in the warehouse system and addressed to the shift manager, who decides what to do with it.
It also watches shipping, which is where the same trick gets harder: carriers slow to pick up, shipments stopped or lost, destinations running past their usual transit time, returns above normal. And it separates what was paused on purpose from what is genuinely late, which is the difference between a useful alert and noise that people learn to ignore.
The limit is published and it is strict, again translated from the Spanish: "The agents detect, explain, and warn. They do not move an order or change a priority: that stays in the hands of the warehouse."
The thresholds of those twenty-four rules come from measuring each warehouse's own data, so they are different in every installation and there is no single number to print.
Execute: the agent does the work and stops where it is written
An execution agent does the work. It reads the email, assembles the case file, drafts the reply. Then it stops where it has been told to stop, which for almost every kind of case is short of signing.
It is worth telling it apart from the two things it gets confused with, because all three are sold with the same words.
A copilot suggests. It drafts, it completes, it proposes, and the work still passes through you. Its limit is that it never acts.
RPA repeats. It replays a fixed sequence of clicks and fields. It is fast and it is cheap, and it breaks the day a screen moves or a form gains a field, because it matches shapes rather than meaning.
An execution agent does the work and stops where a written rule tells it to stop, not where its ability runs out. For almost every kind of case that point is the signature. For the ones a company has raised to the top level, the stop moves behind the send: the reply goes out and is checked afterwards. What never moves is that the point was written in advance.
The difference from a copilot is not power. It is where the limit sits, and it was written down before anybody bought anything.
What governs it is the autonomy level, and the level belongs to the type of case, not to the agent. At the low end, the agent leaves a suggested draft and a person reads it and sends it. At the high end the reply goes out without passing through anyone and is verified afterward. The rule that moves between those two ends is asymmetric: levels rise only with approval, and lowering one requires none.
That asymmetry is the thing worth demanding from anyone. An automatic rise is how a system ends up sending something nobody agreed it could send. An automatic fall is how it stops before the complaint arrives.
Two conditions go to a person whatever the level says: a negative tone and any mention of a legal matter.
What an agent that executes is used for
One minute, as the case page publishes it. An email in Italian asking about an order arrives at 9:12. In that same minute the file is assembled: customer record, order, and tracking. At 9:13 the reply is drafted, in Italian. And at 9:13 the delivery commitment inside that reply is already being tracked against the carrier.
The last line is the one that is easy to skip. The agent read its own draft, found the date it had just promised, and put that promise under watch. If the shipment slips, the customer hears from us before they think to complain. That is a monitoring agent's job done inside an execution agent's action, which is what "the classes stack" means when it stops being a diagram.
None of that is the hard part. Before it, the email had to be understood: marketing email and auto-replies filtered out, the language detected, the text translated, summarized in two lines, and classified by intent and urgency. Then the customer identified, and the orders, shipments, and amounts named in the message pulled live from the ERP. The person who opens that case opens it with the record, the order, and the tracking already in front of them.
And then it stops, which for this kind of case is short of sending.
Where each agent stops, and what it connects to
| system | answers | alerts | executes |
|---|---|---|---|
| Retailer assistant (in public use) | yes | no | only what the shop defined |
| B2B sales book (in production) | yes | yes | no |
| Warehouse (in production) | no | yes | no |
| Support mailbox (in rollout) | yes | yes | with a level per case type |
An execution agent carries a query agent inside it, and a monitoring one as soon as the work calls for it. That is also why the third is the easiest of the three to fake, because a demo of the first looks the same from the outside.
The other half of the question is plumbing, and each case page publishes its own answer. It is what decides whether any of this can be assembled inside a particular company.
- The retailer assistant reads the shop's catalog, the ERP, and the management procedures, returns included.
- The B2B sales book reads the ERP as a read-only replica, the B2B e-commerce platform, the warehouse management system, and the company's email.
- The warehouse reads its management system live, the ERP, the carriers' data, and the commercial master data.
- The support mailbox reads the company's email, the ERP and the e-commerce platform through a connector, plus carrier tracking.
Two of those four connections are worth more than the rest. The sales book reads a read-only replica: the agent watching 14 million lines cannot write to the ERP even if asked, because it is not looking at the ERP. And the warehouse reads its management system live, which is what lets an alert at seven in the morning be about seven in the morning rather than about yesterday's close.
How long that connection takes depends on the system at the other end, and it is one of the first things pinned down in a conversation.
Where you start, and why you start by reading
Go back to the table above for a moment. Only two of the four systems execute anything, and they do not do it the same way.
The support mailbox executes with an autonomy level per kind of case. That is the open form, and it is the last of the four to reach production: exactly the order we recommend. The retailer assistant executes in public use, but it runs only the procedures the shop defined in advance: a closed list, written before it was switched on.
Across our four systems the pattern is the same: open execution is the only thing not yet in production, and the one already in public use is fenced. Every rung adds something that has to be agreed before it is switched on: reading needs a connection, alerting also needs a threshold somebody accepts as their own, and executing needs a written rule saying where it stops and who answers for what comes out.
The first is settled with a read permission. The last is settled with no permission at all.
So we start by reading, and what decides where is which system you can read from today. Once the reading works, the first threshold shows up, and it is almost never the one imagined in a meeting. And once the alerts have been right for a while, you know what an agent would be executing against, which is the thing you do not have on day one.
Skipping rungs has a specific cost. An agent executing against a threshold nobody has checked does real work on the wrong cases, and it does it fast. A read-only replica does not check the threshold. It removes the question, because an agent that cannot write cannot act on a bad threshold at all. It is the rung turned into plumbing, where it no longer depends on anybody remembering it.
The list you can pull this afternoon
Nothing has to be bought to find out whether a monitoring agent would be worth having. The sales-book rule can be run by hand, once, against your own ERP, and what comes out is exactly the alert the agent would raise tomorrow.
Pull your customers' orders for the last two years. For each customer, the number of days that usually pass between one order and the next. Use the median, not the mean: one odd order moves the mean and leaves the median alone. Then the days since the last one. The ones past twice their own figure are the list, and the ones that also have an overdue payment go first.
Anyone who can pull a report out of your ERP has it in an afternoon, and it does not have to be you.
Two readings of the result. If names appear that you did not expect, you have just watched money leaving with nobody looking at it. And if the list comes back empty or full of noise, that is also something learned: your business does not buy on a cycle, and this rule is not yours.
What that afternoon does not give you: a watch. It gives you a snapshot. It does not run again tonight, it does not rank the list by amount, and it does not know which of those names also have an overdue payment. That is the distance between a report pulled by hand and a monitoring agent, measured inside your own company.
When you do not need a monitoring agent
Three cases where a monitoring agent will give you nothing.
If you sell projects rather than replenishment. A buying rhythm does not exist when every order is a different contract. The rule fires on noise, people learn to ignore the alerts, and that is worse than having none.
If your customer base fits in one person's head. With thirty accounts and a salesperson who knows them, nobody needs a system to say who has gone quiet. This starts to earn its place when the book no longer fits in one person's memory.
If your orders live in spreadsheets and email. There is nothing to connect to. The first thing would not be an agent: it would be putting the order somewhere it can be read from.
What this is called elsewhere
These three classes are not our own vocabulary. They are a different cut through one that already exists, and the equivalences are worth having in front of you before you sit down to compare vendors.
The split most often cited by the people who build these systems is Anthropic's, which separates workflows, where the model and its tools are orchestrated along paths written in advance, from agents, where the model directs its own process. Its test is not how many actions something is allowed, but who directs the process. On that test the first two classes here are workflows. The third sits on the line: the model decides what to look at and what to prepare, but it does not decide what it is allowed to do, because that was written before it ran.
Anyone who has to sign off on the risk uses a different axis: autonomy levels. A proposal published on the Cloud Security Alliance blog sets out a scale of six levels, L0 to L5. At L0 the AI informs and a person acts. On that axis, reading and alerting both sit at L0. Only the third climbs, and how far depends on the kind of case.
The third has had a name in the industry for years: human in the loop, with the point where it stops called an approval gate. When somebody offers you "the agent prepares and you approve", that is what they are offering, and the useful question is where that gate is written down.
| what we call it here | what it is on the orchestration axis | what the industry calls it |
|---|---|---|
| Read (query) | a workflow you start | question answering over your own data |
| Alert (monitoring) | a workflow a clock starts | detection and alerting |
| Execute (execution) | a workflow with allowed actions | human in the loop, with the approval gate wherever the rule puts it |
Translating it this way has a practical benefit: when a vendor uses one of those words, you already know which of the three rows it falls into.
What comes out of a first conversation
The first class is the only one that can be shown without connecting anything to anything. That is why it is almost always the one being shown, and why the third is worth seeing run.
There is nothing to prepare. Bring a process that is costing you money and tell us where your data lives.
What comes out of that conversation, in the names of your systems rather than ours: which of the three classes solves that process, the written rule that would govern it and where the agent would stop. All three, in writing.
And if you would rather not pull that list yourself, send us a dump of your last two years of orders and we will hand it back done and ranked by amount. With its limit written down, like the agents': that calculation needs no customer names, just an identifier, the order date, and the amount.
What people ask before deciding
- What is the difference between an AI agent, a copilot and RPA?
- A copilot suggests and you do the work. RPA replays a fixed sequence and breaks when a screen changes, because it matches shapes rather than meaning. An agent reads the state of the company's systems, applies a written rule and acts: it answers, it alerts, or it does the work and stops where a written rule tells it to stop.
- Can I start with one process or does everything have to be connected?
- With one. The four published cases connect different things and none connects everything: the sales book reads a read-only replica of the ERP, the warehouse reads its management system live. What decides where you start is which system can be read from today.
- Can an agent move up a level on its own?
- No. In our support mailbox the autonomy level rises only by explicit approval. Lowering one needs none, which is the asymmetry worth demanding. The case page publishes the trigger: levels drop on their own if quality falls. The exact number comes from each installation's own data, so there is no single one that fits them all.
- Do I have to start with an agent that only reads?
- Almost always yes, and not out of caution: without the reading working you do not know what would be alerted on, or what would be executed against. The classes also stack: an execution agent carries a query agent, and a monitoring one as soon as the work calls for it. What has to come before any of them is the audit of what data exists, what processes move it, and what rules govern it.
- Why are no threshold numbers published?
- Because they are derived from each company's own data. A threshold that is right for one warehouse is a bad default for the next. What is published is the shape of the rule: the buying rhythm measured over each customer's own last two years, and the alert at twice it.
- Where can I see each class running?
- In the four published cases, each with its figures, its status, and its declared limit: the specialty retailer assistant, the B2B sales book, the warehouse and the support mailbox.
Sources
- 1.Published case: a public-facing AI agent in specialty retail, with its declared limit. In public use (page in Spanish) ↩
- 2.Published case: the B2B sales book watched every night, with its figures, its rule and its declared limit. In production (page in Spanish) ↩
- 3.Published case: the warehouse watched in real time, with its 24 rules, its figures and its declared limit. In production (page in Spanish) ↩
- 4.Published case: the support mailbox turned into resolved cases, with its autonomy levels and its declared limit. In rollout (page in Spanish) ↩
- 5.Anthropic, "Building Effective AI Agents": the split between workflows and agents ↩
- 6.Proposal on the Cloud Security Alliance blog, "Autonomy Levels for Agentic AI": the six-level scale, L0 to L5 ↩