Agentic AI in Procurement: Who Is Allowed to Press Buy?

The interesting question is what an agent may commit

An AI procurement assistant can summarize quotations without changing a purchase. An agent that selects a supplier, negotiates a delivery date, or releases an order changes the business process itself. Those activities should not be treated as a single feature called automation. Each has different evidence requirements, possible failure modes, and recovery costs. In a manufacturing network, the important boundary is often the moment a software recommendation becomes an external commitment. Designing that boundary deserves more attention than making a demonstration feel conversational.

The subject is timely without assuming that every factory has adopted autonomous purchasing. NIST's 2026 manufacturing AI workshop agenda includes agentic behavior, autonomy, coordination, physical AI, and interoperability among its discussion themes. An agenda establishes research interest; it does not prove a production success rate. NIST manufacturing AI workshop agenda. This article examines how a manufacturer could evaluate an agent using explicit permissions, evidence checks, and reversible trial activities. It provides an original design analysis rather than a report from an operating DiSC deployment.

Divide the workflow into observable decisions

Start by writing the existing procurement workflow as a sequence of decisions. A buyer receives a requirement, identifies qualified suppliers, requests quotations, compares responses, resolves exceptions, and obtains authorization. A single natural language instruction may cover several of those stages, but the system should still record them separately. That separation makes it possible to ask what information was available at a particular step and whether the agent had permission to proceed. Without it, a fluent final explanation can conceal a missing technical review.

Consider a hypothetical requirement for machined housings. The buyer specifies a material grade, a drawing revision, a quantity, and a delivery window. The agent may search a supplier catalog and prepare a comparison. It should not infer that a similar material grade is acceptable or that a supplier's estimated lead time is a firm reservation. Those are different assertions. The workflow should expose any substitution and identify the role authorized to approve it. A recommendation becomes useful when a human can inspect the assumptions that shaped it, not merely the resulting ranking.

Give tools narrower authority than the conversation

An agent's tools should enforce its actual permission boundary. A read only quotation search tool can return relevant offers. A separate draft order tool can prepare a document. A release order tool can require an authorized approval reference and reject a request without one. Those distinctions belong in the integration layer rather than only in a paragraph telling the model to be careful. A conversational instruction can be misunderstood; a constrained interface can prevent an unsupported action from becoming a valid transaction.

Set limits around supplier eligibility, currencies, quantities, total exposure, delivery destinations, and contract templates. Limits should be checked against authoritative business data, not against the agent's recollection of that data. Also decide how combinations of individually acceptable actions are controlled. Ten small draft purchases can create a material commitment when considered together. A useful permission model therefore examines cumulative exposure and related orders. It should also provide a clear response when a limit is reached, allowing the agent to request review without inventing a workaround or splitting the task to avoid the rule.

Treat incoming documents as evidence, not instructions

Quotations, supplier emails, and catalog descriptions are business inputs. They should not be able to redefine the agent's permissions. A document might include misleading instructions, accidental boilerplate, or deliberate text designed to influence an automated reader. The agent needs a process that extracts proposed commercial facts while keeping the operational rules under the control of the buyer's system. A supplier's statement that an order is preapproved is not itself an approval from the organization that would be paying for it.

Test this distinction with deliberately adversarial examples. Put an instruction to ignore a price limit in a quotation's notes. Add a delivery address that differs from the approved site. Include two conflicting totals, one in a table and another in an attachment name. The desired response is a flagged discrepancy with a traceable source location. The test is not passed because the model gives a reassuring explanation. It is passed when the workflow prevents an unauthorized commitment and presents enough evidence for a reviewer to understand why the request stopped.

Preserve the difference between facts and derived judgments

A quotation may state a price of twenty thousand euros and an estimated shipment date. The agent may derive a normalized unit cost and judge the offer to be operationally attractive. Keep the quotation facts, the calculations, and the judgment in separate fields. Record the source document and revision for the facts, the formula and inputs for the calculations, and the decision criteria for the judgment. This makes it possible to correct an input without pretending that the original conclusion was based on the corrected information.

The same discipline applies to confidence. A model saying that it is highly confident does not establish that a supplier certificate is current or that a manufacturing process meets a tolerance. Verification should use checks that are external to the model's narrative: matching identifiers, current certificate dates, approved capability records, and explicit responses from responsible people. Where evidence is insufficient, the output should say which fact is missing. A precise question to a supplier is more useful than a confident paragraph that quietly substitutes an assumption for the missing evidence.

Compare the agent with a meaningful baseline

An evaluation should begin with a collection of historical or synthetic cases whose intended outcomes have been reviewed. Include easy cases, missing information, conflicting documents, expired certifications, and out of policy requests. Define what counts as a successful result for each stage. Searching for candidate suppliers differs from selecting a qualified supplier; preparing a draft differs from obtaining an approved order. A single overall accuracy figure makes it difficult to see where the agent is useful and where it creates extra review work.

For illustration, suppose a trial contains one hundred cases. The agent prepares ninety drafts quickly, but twenty require correction and ten cannot proceed because information is missing. Reporting ninety percent automation would be misleading. Record first pass acceptance, correction effort, and unresolved cases separately. If seventy drafts are accepted without correction, first pass acceptance is seventy percent of the full sample. These are hypothetical values, not observed performance. Compare total buyer time and error consequences with the existing workflow, including the time spent reviewing plausible but incorrect outputs.

Make stopping and recovery practical

An agent should be able to stop without leaving the business process in an ambiguous state. A paused negotiation should show what has been communicated, what remains a draft, and whether any supplier is holding capacity. A failed order submission should be checked for duplicate creation before it is retried. The recovery design should account for uncertainty about the external system, rather than assuming that a network timeout proves nothing happened. This is ordinary transaction discipline applied to a new interface.

Provide an operational control that disables new external actions while preserving access to logs and drafts. Rehearse who uses it, how pending actions are reviewed, and how the workflow resumes. A stop control that only the departed developer knows how to operate is not a usable control. Similarly, rollback has limits: an email cannot reliably be unsent, and a supplier may already have acted on an order. Those limits should shape the agent's authority. Start with actions whose consequences are bounded and whose state can be inspected independently.

Use human review where it changes the decision

Human review works best when the reviewer sees a concise decision record: the requirement, the selected evidence, the alternatives, the exceptions, and the exact proposed action. Asking a busy person to approve a long generated narrative encourages superficial review. Highlight the decisions that require expertise, such as a material substitution or an unusual liability clause, and make the underlying source easy to inspect. Review should be a designed part of the workflow rather than a final button added to an otherwise autonomous system.

Assign responsibility by task. Engineering can review technical equivalence, purchasing can review commercial conditions, and an authorized approver can release the commitment. Do not imply that any one reviewer has verified all aspects simply because they clicked a general approval button. A structured record of who reviewed what is more useful than a single approval timestamp. It also helps identify whether an automated recommendation is repeatedly creating the same exception, which may indicate a poor data source or a flawed selection rule that should be corrected upstream.

A useful pilot has a stopping rule

NIST's AI Risk Management Framework offers a voluntary approach to considering trustworthiness throughout the AI lifecycle. It is a framework for risk management, not a certification of a procurement agent. NIST AI RMF. In a pilot, translate the general objective into a small number of decisions: which tools are enabled, what outcomes are measured, who reviews exceptions, and which failures stop the trial. Keep a versioned record of the model, prompts, tool permissions, and evaluation cases so that a later change can be compared fairly.

This article has not measured a commercial agent or claimed savings from a live factory. Its scenarios are designed to help a team build an evaluation that can distinguish useful assistance from misplaced autonomy. The first successful result may be a system that searches and drafts well while leaving commitment with a person. That is a meaningful capability if it reduces real work without hiding uncertainty. Expand authority only when evidence from the narrower workflow supports the next step, and retain the ability to explain each external action after the conversation has ended.