What this covers
- An agent is defined by what it completes, not by the model behind it: a request read, checked, acted on in a system of record, and logged.
- The hard part is almost never the language understanding. It is the master data, the business rules and the point where the agent has to stop.
- Operational work suits agents when it is high volume, rule-governed and currently done by a person moving information between a document and a system.
- A deployment that cannot show you what it did, line by line, is not ready for work that touches customers or money.
A sales engineer opens an email at 09:14. Attached is a specification sheet with eleven line items, most of them written in the customer's own part numbers. She finds each part in the catalog, checks what this customer is contractually entitled to pay, confirms that the quantities can ship by the date they asked for, and assembles a quote. It takes her forty minutes. She does it nine more times that day.
Ask a language model to help and it will summarize the email beautifully. It will not find the parts, because it cannot see the catalog. It will not price them, because it does not know the contract. It will not check stock. At the end you have a summary of a request you had already read, and the forty minutes are still there.
Agentic AI is the name for systems built to close that gap. The model is still the component that reads and reasons, but it sits inside something larger: a defined workflow, access to the systems where the answers live, rules about what it may and may not do, and a point at which it hands the case to a person. What the business buys is not the model. It is the completed transaction.
The working definition
Strip away the marketing and an agent is a piece of software with four properties. It takes in work that arrives in whatever form the sender chose. It decides what has to happen next without a person scripting each branch. It acts in systems of record rather than producing a draft for someone else to key in. And it accounts for every action it took, in a form an auditor could read.
Each of those four properties rules something out. The first rules out anything that needs a structured form at the front, because customers do not send forms, they send email. The second rules out a decision tree, because a decision tree needs every branch drawn in advance and operational reality supplies new branches weekly. The third rules out a chat window, because a chat window ends with a person doing the typing. The fourth rules out any system that cannot say why it did what it did.
What the work looks like, step by step
The same seven-step shape shows up whether the work is a quote, an incoming order, a supplier invoice or a customer question. It is worth walking through, because the interesting problems are not where people expect them.
- 01Read
Take the request in the form it arrived: an email body, a PDF specification, a scan of a purchase order, a spreadsheet of line items. Extract what was actually asked for, including the parts a human reader infers from context.
- 02Identify
Resolve the sender to an account in the systems of record, and pick up everything that account brings with it: contract terms, payment terms, pricing tier, credit status, open items.
- 03Match
Map what was asked for onto what the business actually sells or buys. This is where customer part numbers, legacy codes, free-text descriptions and unit-of-measure differences get resolved against master data.
- 04Check
Apply the rules: pricing, tolerances, availability, credit, approval thresholds, anything the business would want verified before it commits.
- 05Decide
Conclude one of two things. Either every check cleared and the agent can complete the work, or something did not, in which case the case stops and goes to a person with the reason attached.
- 06Act
Write the result into the system it belongs in: a quote, a sales order, a coded invoice, an updated record, a reply to the customer.
- 07Log
Record what was read, what was matched, which rules were applied, what was written, and where a person intervened.
Steps one and six are the ones people imagine are difficult. They are the ones that are largely solved. Reading a scanned purchase order and writing a sales order are engineering problems with known answers. Steps three and five are where deployments succeed or fail, and neither is an AI problem in the usual sense.
Why matching is the real work
A customer writes "AX440 stainless, 60 off". Your catalog calls it AX-440S. A second customer has been ordering the same item for nine years under a code that came from a supplier you stopped using in 2019, and it is still in their purchase order template. A third sends a description with no code at all. All three are ordering the same thing, and all three are routine.
Language understanding gets you to the sentence. Master data gets you to the part number. Only one of those is in the model.
An agent resolves these the way an experienced person does, by combining the text with everything else it knows: what this customer has bought before, what the description implies about material and size, what is actually in the catalog. And when the evidence is thin, it does the other thing an experienced person does. It stops and asks, showing the two or three candidates it was choosing between.
This is why a deployment is scoped around your data rather than around a model. The reasoning is general. The catalog, the customer history and the unit conventions are yours, and they are what a working agent is actually built on. How it works sets out which parts are built before a project starts and which are configured against your systems.
Where the agent has to stop
Every operational workflow contains decisions a business should not delegate to software, and the list is specific to the business. A price below a floor. A customer on credit hold. A new account nobody has approved terms for. A quantity ten times larger than anything that account has ordered before. A tolerance breach on an invoice line.
Designing those stopping points is the part of a deployment that most deserves argument, because they set the line between useful and dangerous. Set them too loose and the agent commits the business to things it should not. Set them too tight and everything ends up in a person's queue, which is where it started. There is a longer treatment of this in designing the point where an agent stops.
Which work is worth automating
Not all of it, and the filter is not difficulty. Four properties predict whether a workflow will repay the effort.
| Property | Why it matters | A bad sign |
|---|---|---|
| Volume | Fixed setup cost is amortized over every case the agent handles. Frequency, not complexity, drives the return. | A dozen cases a month, each one different. |
| Rules exist | If a person can say what makes a case correct, an agent can check it. If correctness is a judgment call, it cannot. | Nobody can explain the pricing logic without exceptions. |
| Data is reachable | The agent needs live access to the catalog, the customer record, the pricing and the stock position. | The authoritative price list lives in someone's spreadsheet. |
| An outcome is defined | There has to be a state the work ends in: a quote issued, an order created, an invoice posted. | The workflow ends in "someone takes a look". |
Quoting, order entry, purchase order handling, invoice processing and repetitive customer requests score well on all four, which is why they are where this work usually starts. Choosing your first workflow goes through the selection in more detail.
What to ask a vendor
Most demonstrations are built on clean inputs and a sample database. The questions that separate a demonstration from a deployment are unglamorous.
- Show me a case the agent got wrong, and what happened next.
- Which of our systems does it write to, and what stops it writing something incorrect?
- Where does it run, and where does model inference happen?
- What does the log show for a single transaction, from arrival to completion?
- What proportion of cases do you expect to end with a person, in month one and in month six, and what moves that number?
- What happens when our catalog changes?
A vendor who answers the fifth question with a number and no conditions is guessing. The honest answer is that it depends on your data quality and your rules, and that the first weeks of a deployment are partly spent finding out.
The short version
Agentic AI is worth the attention it gets, for a narrow reason: it is the first form of this technology that removes work rather than adding a step to it. But the value does not come from the model. It comes from connecting a capable reader to your master data, your rules and your systems of record, and being explicit about where it stops.
If you want to see what that means for a workflow you actually run, the practical next step is to trace one. Take a real request from the inbox it arrived in to the record it ended in, and count how many of those steps needed a person and why. That is what a Workflow Review does.