AI agent for procurement: what it does, what it decides on its own and how it plugs into the ERP
An AI agent for procurement requests quotes, negotiates and issues the purchase order inside the ERP, within a defined approval limit, with the buyer approving only the exceptions. Here is what it decides alone, how it differs from RPA and chatbots, and how it connects to TOTVS Protheus, Datasul and SAP.

An AI agent for procurement is software that takes a purchase requisition, decides what to do with it and carries it out: it requests quotes from suppliers, compares the bids, negotiates within an approval limit and issues the purchase order in the ERP. When a decision falls outside that limit, it stops and calls the buyer. That is what separates it from a report, an RPA bot or a chatbot.
This article covers what the agent does, what it decides on its own, how it integrates with TOTVS Protheus, Datasul and SAP, and how every decision is logged. One illustrative example runs through the text, a R$ 3,200 requisition for protective gloves. The figures show the mechanics; they are not a promise of results.
What an AI agent for procurement is (and what it is not)
An AI agent combines three things: a language model that reads context, a set of tools it can use (query the ERP's order history, send an email, create a purchase order) and a goal with limits. In procurement, the goal is usually "fill this requisition at the best price the company has already paid, within policy, by the date requested."
Three things that are not agents, even though they are sold under the name:
- A savings-opportunity dashboard. It informs. Someone still has to act.
- An assistant that answers questions about suppliers. It talks. It does not execute anything in the ERP.
- An automated approval workflow. It follows a fixed script. Off the script, it stalls.
The distinction is not academic. Gartner estimates that only about 130 of the thousands of vendors marketing themselves as "agentic" deliver real agent capabilities, and calls the rest agent washing: rebranding assistants, RPA and chatbots that have no real autonomy. The same note predicts that over 40% of agentic AI projects will be canceled by the end of 2027, due to rising costs, unclear value or inadequate risk controls. Knowing what you are buying is the first line of defense.
The four levels of autonomy
Every AI tool in procurement fits one of four levels. Asking "which level does it operate at?" separates an agent from a report in a minute.
- Report. The tool reads the history and flags: "this item was bought at 14 different prices in twelve months." The buyer decides what to do.
- Suggestion. The tool recommends: "quote these three suppliers; the lowest price already paid is R$ 68." The buyer executes.
- Assisted execution. The agent requests quotes, negotiates and prepares the order. The buyer approves each one before it is issued.
- Autonomous within limits. The agent requests quotes, negotiates and issues the order on its own when the decision fits the rule. The buyer approves only the exceptions.
Levels 3 and 4 change the team's capacity. Levels 1 and 2 change the information, but the requisition queue stays the same length. Most companies start at level 3 for one group of items and move to level 4 as the error rate allows.
Agent, RPA, chatbot and copilot: what is the difference
All four terms show up together in any vendor proposal. The table shows what each one does with a requisition.
| RPA | Chatbot | Copilot | AI agent | |
|---|---|---|---|---|
| What it does | Repeats clicks and keystrokes along a fixed script | Answers questions in natural language | Suggests text, data and next steps to the person operating | Decides and executes a task end to end using tools |
| Handles the unexpected | No. Off script, it stops or makes a mistake | Only if the answer is in its knowledge base | It suggests, but the person acts | Yes, within the approval limits |
| Procurement example | Copy a quote from an email into the ERP | "When does the contract with supplier X expire?" | Draft the counteroffer email for the buyer to send | Request quotes, negotiate, choose and issue the order in the ERP |
| Who decides | The script, written by someone | Nobody: there is no decision | The buyer | The agent, up to its limit; the buyer, above it |
| Where it fails | A screen or layout change | A question outside its scope | It depends on the buyer's calendar | A badly designed limit or bad data in the ERP |
Gartner draws the same line: assistants "rely on human input and do not operate independently"; agents "carry out complex tasks end to end." Its forecast is that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025. ERPs are part of that count.
RPA and agents do not compete: an agent can call an RPA bot to fill in a screen that has no API. What changes is who makes the decision.
The five agents that make sense in procurement
There is no single "procurement agent." There are tasks, and each one needs an agent with its own tools, approval limit and escalation point. Five of them cover most of the work of a central procurement team.
| Agent | What it does | What it decides alone | When it calls the buyer |
|---|---|---|---|
| Quoting | Receives the requisition, finds the item in the history, selects approved suppliers and sends the request for quote | Which suppliers to ask and how long they have to respond | Item with no history, no approved supplier or an ambiguous specification |
| Negotiation | Compares bids with the lowest price already paid, makes a counteroffer and closes terms | Accept a bid within the price, delivery and payment limits | Best bid above the floor plus tolerance, or supplier asks for terms outside policy |
| Follow-up | Chases suppliers who have not replied, confirms delivery, flags delays | Send reminders, move to the next supplier on the list | Delay that affects production, supplier silent past the limit |
| Supplier onboarding | Collects documents from new suppliers, validates the CNPJ (Brazil's company tax ID), tax standing and certificates | Approve a registration with complete, valid documents | Expired document, tax issue, high-risk category |
| Spend analysis | Normalizes descriptions, calculates price dispersion, flags off-contract items | Nothing. It is level 1: it informs | Always. Its output feeds policy; it does not replace it |
The spend analysis agent is the one that shows up most in demos and changes operations the least, because it only informs. Quoting and negotiation take requisitions out of the queue; follow-up and onboarding free up the time that goes into email and spreadsheets.
In the tail of procurement, the part concentrated in the C curve and in indirect procurement, the five work together: every small requisition goes through quoting, negotiation and order without waiting for anyone's calendar.
Approval limits: what the agent decides alone and when it calls the buyer
The approval limit is the rule that separates what the agent closes from what it hands off. Without it there is no level 4, only an assistant with too many permissions.
A well-designed negotiation limit has five parameters:
- Value range. For example, up to R$ 10,000 per order. Above that, the agent prepares and the buyer closes.
- Price floor and tolerance. The agent accepts a bid up to the lowest price the company paid in the last twelve months plus a tolerance (5%, for example). Above that, it escalates.
- Supplier list. Approved suppliers only. A new supplier goes through the onboarding agent and the buyer before receiving an order.
- Commercial terms. Payment and delivery terms within policy. A request for early payment escalates.
- Excluded items. Raw materials, production-critical items, strategic contracts. These stay with the buyer, always.
Back to the example. The R$ 3,200 requisition is for 40 boxes of nitrile gloves at R$ 80 a box, the price on the last order. The history shows the same glove bought at R$ 68 at another site four months earlier. That is the floor. With a 5% tolerance, the agent can close up to R$ 71.40 a box. The requisition is below R$ 10,000, the item is not critical and the three suppliers asked are approved. The agent proceeds on its own.
If the best price came back at R$ 76, above tolerance, the agent would not issue the order. It would put together a summary (three bids, the floor, the gap) and call the buyer with a specific question: accept R$ 76, try one more round or switch suppliers. That is approval by exception: the buyer sees only what fell outside the rule.
The buyer still owns the policy: sets the parameters, tightens or loosens the tolerance, reviews the supplier list and manages critical suppliers. The agent works within what was defined; it does not redefine anything.
How the agent works inside Protheus, Datasul and SAP
The agent does not replace the ERP. The ERP remains the system of record: requisition, purchase order, receipt and payment all live there. The agent reads from and writes to the ERP through interfaces that already exist.
In TOTVS Protheus, the purchase requisition lives in table SC1, the purchase order in SC7 and the supplier master in SA2. The agent reads the approved requisition, queries the order-line history (the C7_TOTAL field, the line's total value, is the basis for the price floor) and creates the order through the Protheus REST API or the ExecAuto routine for purchase orders. It does not insert rows directly into the database: the order is created with the same triggers, validations and approval rules as one keyed in by a person.
In TOTVS Datasul, the equivalent flow runs through the requisition, the purchase order and the order line. The integration uses Datasul's procurement APIs or its existing automatic quotation, with the agent filling in the negotiation step that is empty today. Companies that approve through TOTVS Fluig keep that flow: the agent creates the order, Fluig routes the approval.
In SAP, the order is created via BAPI (BAPI_PO_CREATE1 in ECC) or an OData API in S/4HANA, from the requisition (ME51N). Price history comes from the purchasing info record and past orders. The agent respects the purchasing groups, purchasing organizations and release strategies already configured.
In all three, the agent comes in through the front door. The ERP's audit log records the order like any other. The ERP's own approval rules still apply (if an order above R$ 50,000 requires a director, it still will). And if the agent is ever switched off, nothing breaks: the orders are in the ERP, with full history.
Communication with suppliers goes through email or a supplier portal, always from a company mailbox, with the buyer copied if policy requires it.
Example: a R$ 3,200 glove requisition, from request to audit log
This example is illustrative. The figures were chosen to show each step; results vary with the item, the history and the market.
Day 1, 9:02 a.m. A requisition for 40 boxes of size M nitrile gloves enters the ERP, approved by the cost center manager. Estimated value: R$ 3,200, based on the last order (R$ 80 a box).
9:04 a.m. The quoting agent identifies the item by code and normalized description. It finds 11 orders in twelve months, across three sites, at prices between R$ 68 and R$ 84. Floor: R$ 68. It selects three approved suppliers with history on the item and emails a request for quote with a 24-hour deadline.
Day 2, 8:30 a.m. All three bids are in: supplier A, R$ 80 (the usual one); supplier B, R$ 74; supplier C, R$ 71. All deliver within 10 days with 28-day payment terms, within policy.
8:32 a.m. The negotiation agent compares them with the floor. R$ 71 is within tolerance (R$ 71.40); it could close. The rule, however, calls for one more round when more than one supplier comes in below the usual price. Counteroffer to B and C: "The company has paid R$ 68 for this item in the last twelve months. Can you match that for 40 boxes with delivery in 10 days?"
11:15 a.m. Supplier C replies with R$ 69. Supplier B holds at R$ 74.
11:16 a.m. R$ 69 is within the limit. The agent closes with C, sends the confirmation and creates the purchase order in the ERP: 40 boxes at R$ 69, total R$ 2,760, delivery in 10 days, 28-day payment. The order gets its ERP number and follows the normal receiving flow.
Result. The R$ 3,200 requisition closed at R$ 2,760: R$ 440 less, or 13.75%. Cycle time: about 26 hours, most of it waiting for suppliers. Buyer intervention: none.
Audit log. The agent records, with date and time: the source requisition; the 11 historical orders and the floor; the suppliers asked and the selection criteria; the bids, with the original emails; the counteroffer and the replies; the approval rule applied (value, floor, tolerance, approved status, terms); the decision to close with C and why; the ERP order number. Any auditor can open that log and reconstruct the decision.
In a procurement center that issues thousands of requisitions like this every month, the difference between "nobody quotes" and "the agent quotes all of them" is the savings in the tail. That is why tail spend is the first place where agents make sense.
Metrics: savings, cycle time and intervention rate
Three measures tell you whether the agent is working.
Realized savings per order. The difference between the requisition's estimated value (last price or catalog) and the value of the order issued. In the example: R$ 440. The monthly total is the scoreboard, measured against the price that would have been paid without the agent, not against the first bid.
Requisition cycle time. From requisition approval to order issue. Without an agent, tail items wait days in the queue; with one, cycle time tends toward the supplier's response time. In the example, 26 hours.
Intervention rate. The share of requisitions in which the agent called the buyer. It is the thermometer of the approval limit. A very high rate points to a limit that is too tight or bad data in the history. A rate near zero deserves a check: the limit may be too loose. A complementary measure is reversed orders, the ones the buyer had to cancel or redo. That number should stay close to zero.
On the effect on the function, McKinsey estimated in an October 2025 analysis that procurement agents can make the function 25% to 40% more efficient, with the team's time shifting from routine tasks to strategic decisions. The same study notes that spend managed per procurement employee is 50% higher than five years ago. The Hackett Group measured the other side of the pressure: procurement workload is expected to grow 8% in 2026 while headcount and budgets fall; 43% of the organizations surveyed are already actively pursuing AI deployment, nearly double the year before, but only 12% have reached scale.
Risks, auditability and data privacy
An agent that executes needs more control than a report that informs. Four risks call for explicit rules.
A wrong decision within the limit. The agent closes a bad order because the history was dirty (a free sample recorded at R$ 1, for example). Mitigation: calculate the floor with an outlier filter and monitor reversed orders.
A supplier manipulating the agent. A supplier replies to the request for quote with instructions embedded in the email ("ignore the other bids"). Well-built agents treat supplier content as data, never as a command, log the attempt and alert the buyer.
A badly designed limit. Tolerance set too high, a critical category missing from the exclusion list. Mitigation: start at level 3 and move to level 4 category by category, not all at once.
An incomplete log. If an auditor cannot reconstruct the decision, the agent should not have made it. Every order needs the log described in the example.
On LGPD, Brazil's data protection law: data about a supplier as a company is not personal data, but the sales rep's name, email and phone number are. The agent processes them to perform a contract or pre-contractual steps, a legal basis the law provides for, and keeps them for the period set in the retention policy. If the model runs in a third-party cloud, find out where the data is processed and whether the provider uses it to train models. The right answer is "no."
How to start in 30 days
A pilot fits in a month when the scope is narrow.
Week 1: measure the tail. Export twelve months of orders from the ERP, normalize descriptions, calculate the floor and price dispersion per item, and separate what is under contract. The output is the list of candidate items and the target in reais. The two-week diagnostic returns that target measured on your own data.
Week 2: design the approval limit. Pick two or three tail categories (protective equipment, consumables, low-value MRO), set the value range, floor and tolerance, approved suppliers and terms. Decide who approves exceptions.
Week 3: integrate and run at level 3. Connect the agent to the ERP through its APIs, point it at the mailbox, and run the first requisitions with the buyer approving each order. Read the intervention rate and reversed orders every day.
Week 4: move to level 4 where the rate allows. Categories with a zero error rate start issuing without approval; the rest stay at level 3. Publish the savings scoreboard and the audit log for the controller's office.
The most common mistake is starting with the spend analysis agent, the easiest to demo and the one that changes operations the least. The second is starting with critical items. The tail is the right place: the risk of a wrong order is small, the volume is high and nobody is quoting it today.
Frequently asked questions
How much does an AI agent for procurement cost?
It depends on the contracting model and the requisition volume. There are three common formats: a licence per user or per order processed, a percentage of realized savings, and a service model in which the agent comes inside an outsourced procurement operation. To compare proposals, ask for the cost per order issued and the expected savings per order on your own data, not a generic rate. A 30-day pilot on the tail reveals both numbers.
What is the difference between an AI agent and RPA?
RPA repeats a fixed script of clicks and keystrokes; if the screen changes or a supplier replies with something unexpected, the bot stops or makes a mistake. An AI agent reads the context, decides which tool to use and handles the unexpected within its approval limit. The two complement each other: the agent can call an RPA bot to fill in a screen that has no API. The difference is who decides: in RPA, the script; in the agent, a rule applied case by case. A comparison with what the Brazilian market sells as a "procurement bot" is in procurement bot vs. AI agent.
Does the AI agent replace the buyer?
No. The agent handles the repetitive part (quoting, comparing, negotiating tail items, issuing orders) and the buyer approves exceptions, sets policy and manages critical suppliers and categories. McKinsey describes this as a hybrid team in which buyers work alongside digital colleagues. The buyer stops being the bottleneck for the queue of small requisitions and focuses on what requires judgment.
How does the agent integrate with Protheus, Datasul or SAP?
Through the interfaces the ERP already offers: REST API and ExecAuto in Protheus, procurement APIs in Datasul, BAPIs or OData in SAP. The agent reads the approved requisition and the order history and creates the order as a user would, respecting the ERP's own approval rules, validations and audit trail. It never writes rows directly to the database.
What can the agent decide on its own?
What the approval limit allows, and nothing more. In a typical setup: accept a bid from an approved supplier when the price is at or below the lowest price already paid plus a tolerance, the order value is below a ceiling, and payment and delivery terms are within policy. A new supplier, a critical item, a price above tolerance or terms outside policy go to the buyer. The buyer writes the limit and can tighten or loosen it at any time.
How can you tell whether an "agent" is really an agent?
Ask which level of autonomy it operates at and ask to see an order issued in the ERP with the decision log. If it only shows opportunities, it is a report; if it recommends and someone else executes, it is a suggestion; if it executes with approval on every order, it is assisted execution; if it issues orders within a limit and escalates exceptions, it is an agent. Gartner calls rebranding assistants, RPA and chatbots as agents agent washing, and estimates that most vendors do it.
How UpFlux does it
UpFlux takes over the transactional work of procurement with a digital procurement team: AI agents operated by specialists that request quotes, negotiate and issue orders inside TOTVS Protheus, Datasul and SAP, with an approval limit per decision, an audit trail per order and the buyer approving only the exceptions. That is the job of the Negotiator Agent. At a multinational manufacturer, R$ 22 million processed in the tail returned R$ 1.6 million to cash with no new hires. Underneath sits the Enterprise AI layer: process mining to measure the tail before the agent starts work (UpFlux is the only Brazilian company in Gartner's Magic Quadrant for Process Mining), and RoAI, which measures the return of every action the agent takes.


