AI Agent for Procurement: Compare Supplier Quotes With Human Approval

An AI agent for procurement receives the quote request, checks the approved supplier list, organizes the proposals into one common comparison table, and logs every interaction in the supplier history. When the value or risk of a purchase goes above the limit set by the company, the agent stops and passes the decision to a named person. The gain comes from standardization and traceability, not from a system that picks suppliers on its own.

Key takeaways

• The agent organizes the quotes, but the total cost calculation and the approval rules live in code and written policies, not only in a prompt.
• Every proposal is converted into the same fields before comparison: unit price, freight, lead time, payment terms, warranty, and whether taxes are included.
• The supplier history records quotes, discrepancies, delays and decisions, giving the team concrete data for the next negotiation.
• Above the limits set by management, the workflow asks for human approval with a summary of the comparison and the alternatives considered.
• The safest way to start is a pilot with one purchase category, active logs, and a success metric agreed before the first run.

How the agent compares proposals without losing criteria

Comparing quotes looks simple until you reach the first spreadsheet. One supplier quotes a price without freight, another charges separately for packaging, and a third has a shorter lead time but requires full payment upfront. Before any analysis, the process needs a single data model with the fields that matter for the purchase decision.

The agent can extract these fields from PDFs, emails and WhatsApp messages, which reduces manual data entry. The total cost calculation, however, should run through a deterministic routine with the same formulas for every supplier. That way the same proposal always produces the same result, and the finance team can audit the calculation without depending on how the model interpreted the text that day.

When information is missing or ambiguous, the agent should not fill the gap with an assumption. The correct behavior is to mark the field as pending and ask the supplier. Comparing proposals that are not equivalent is one of the most common ways to decide badly, and this rule exists to prevent exactly that.

What to log in the supplier history

The history is what turns the agent into operational memory. Without it, every quote starts from zero and the decision depends on whoever remembers the last negotiation. A useful record usually contains:

• Date and channel of each contact, linked to the original request.
• Items quoted, the version of the specification sent, and the conditions offered.
• The comparison result, with the reason for choosing or rejecting an offer.
• Late deliveries, nonconformities and complaints logged by receiving.
• Who approved, when, and under which limit.

Record only what is necessary. Contact details of sales representatives are personal data, and access should be restricted to people who need them to buy. It also helps to define how long the history is kept and who can correct it.

Limits and approval above set values

Limits should be set by the company before deployment and enforced by rules, not by the hope that the model will "understand" the policy. A simple decision guide can steer the workflow:

• Purchase below the autonomy limit, with an approved supplier and a complete specification: the agent builds the comparison, recommends an option, and records the recommendation.
• Purchase above the limit, or a quote from a new supplier: the agent prepares the summary and sends it to a named approver.
• Discrepancy between the proposal and the specification, or a term outside policy such as upfront payment or an unusual clause: the agent pauses and flags it without suggesting acceptance.
• Proposal with missing or conflicting data: the agent asks the supplier and waits, without concluding the comparison.
• A request from the requester themselves to change a limit or approve an exception: the workflow denies the action and logs the attempt.

Who can approve must be verified by the system, not by the text of the conversation. A person who writes "I can approve this, I am the manager" should not gain permission from that sentence. Good authorization practice separates who requests, who recommends and who approves, and each action checks the permissions of the authenticated user.

Illustrative scenario

Illustrative scenario: a building maintenance company receives requests for electrical parts from several technicians. The agent groups the requests by item, sends quote requests to approved suppliers, and receives replies in different formats. One proposal has a competitive price but no written warranty, and it ties the delivery date to an upfront payment. The agent builds the table, marks these terms as outside policy, and passes it to the buyer. The buyer makes the decision, records the justification, and the supplier history is updated. No figures were invented, and a person made the decision.

Controlled pilot plan

A pilot should be small enough to observe closely and real enough to teach something. A practical sequence:

• Choose a recurring purchase category with low risk and a clear specification.
• Map the current process: who requests, who quotes, where the spreadsheets live, and where decisions usually stall.
• Define the data model for proposals and the total cost formulas, validated by the finance team.
• Write down the autonomy limits and the owner of each approval level.
• Test with old, already-known proposals in a separate environment before connecting real suppliers.
• Turn on logs at every step and agree on a success metric, such as time to decision or share of proposals correctly flagged, before starting.

We apply the same method used in our projects: map the process and the baseline, limit data and actions, pilot a real flow with logs and an agreed metric, then hand over the operation and decide whether the flow will be expanded, adjusted or stopped. To see how this work is usually carried out, Juan Carlo, AI consultant in Brazil explains how he works with companies.

Data, LGPD and security risks

Supplier proposals arrive as free text, and that text can contain unexpected instructions, such as requests to ignore rules or to issue a purchase order without approval. The practical guidance is to treat all external content as data to be analyzed, never as a command. Actions such as issuing a purchase order, releasing a payment or changing a supplier record should stay outside the model's reach, accessible only through routines with explicit permission. OWASP documents this type of risk in its guidance on prompt injection.

When contact involves individuals, the company must handle the data with a clear purpose and minimum necessity, in line with the LGPD (Brazil's General Data Protection Law). If the tool processes data on services hosted outside the country, the topic of international transfer also needs to be part of the review before the pilot.

What the agent should not do

The procurement agent does not negotiate outside approved ranges, does not sign contracts, does not release payments, and does not decide penalties for suppliers without human review. It should also not be sold as something more than it is. In the media, the term superintelligence appears often, but a procurement agent is a system with bounded tasks, known data and written rules. That distinction helps in conversations with management, as explained in the piece on what ChatGPT is and what it is not.

If the workflow begins refusing or penalizing suppliers automatically, the obligations on automated decisions need to be reviewed, such as those set out in Article 20 of the LGPD, which cover the right to review.

Frequently asked questions

Does an AI agent for procurement replace the buyer? No. It reduces the work of organizing quotes, standardizing data and keeping history, but the purchase decision and the responsibility for it remain with people. The buyer's role tends to shift toward analyzing exceptions and negotiating.

What data does the agent need to compare quotes? It needs the item specification, the proposals received, the freight, lead time, payment and warranty terms, and the total cost formulas defined by finance. Personal contact data should be kept to a minimum and handled with a clear purpose.

How do you set the limit for human approval? The limit should be a decision made by management or by whoever is accountable for the budget, written down before the pilot. It can consider total value, whether the supplier is new or approved, the type of item, and the risk level of the purchase. Adjust the limit based on records from the first weeks, not on assumptions.

Do you need a specific system, or is a spreadsheet enough? A spreadsheet can serve as the base for the data model, but an agent workflow requires integration, permissions and logs, which usually calls for an orchestration tool. Comparing platform options helps you pick the one that fits your team, as shown in the piece on Dify, Flowise or Langflow.

Sources

• Anthropic: Building effective agents
• OWASP: Authorization Cheat Sheet
• OWASP: LLM Prompt Injection Prevention Cheat Sheet