This walkthrough builds a procurement AI agent for purchase order (PO) exceptions as a Forward Deployed Engineer would deliver it, from business problem to measured return. A procurement AI agent for exceptions is ready for production only when it classifies each exception from supplier emails and ERP data, checks it against the contract, proposes an action with evidence, drafts the supplier reply, and leaves every external message and every PO change to a buyer's approval. The scenario is illustrative; the closing milestone plan makes it a portfolio project on synthetic data.
Invoice matching is not covered here. That belongs to accounts payable and is covered in the finance AI agent project. This article deals with what goes wrong earlier, between placing the PO and receiving the goods.
Business problem
Illustrative scenario. Consider an Indian auto-components manufacturer with plants near Pune and Hosur and a central procurement team. Buyers manage thousands of open PO lines for castings, fasteners, packaging and MRO spares. The ERP records what was ordered and received. Everything that goes wrong in between arrives by email:
- A forging supplier writes that a die failure will push dispatch out by ten days.
- A goods receipt note (GRN) shows only part of a line received, with no word on when the rest is coming.
- An order acknowledgement quotes a unit price above the rate in the annual contract, citing "raw material increase".
- A supplier asks to substitute an equivalent grade, change the Incoterm, or split a delivery.
Urgent line-stoppers sit beside routine notices. Senior buyers triage instead of negotiating, contract terms such as price validity and liquidated damages (LD) for late delivery go unused, and planning learns of a delay when the line runs short.
The head of procurement wants faster responses, consistent use of contract terms and no loss of control. In a supply chain, "from AI demo to enterprise outcome" means fewer surprises on the shop floor, not a chatbot that summarises emails. Wider context is in AI in manufacturing.
Requirements
Discovery brings in buyers, category managers, production planning, stores, AP, legal, internal audit, the ERP owner and IT security.
Functional
- Link each supplier email to a supplier, PO and line.
- Read PO, advance shipping notice (ASN), GRN, stock and material requirement data from the ERP, read-only.
- Classify the exception, judge production impact and cite the applicable contract terms.
- Propose one action from a fixed set with evidence, and draft the supplier reply.
- Track the case to closure, which can take weeks, chasing suppliers who go quiet.
Hard boundaries
- No email reaches a supplier without a buyer approving that exact text.
- The agent never creates, changes or cancels a PO. A buyer makes approved changes in the ERP under their own identity.
- The agent never onboards suppliers, changes supplier master data or accepts bank-detail changes. Bank-detail requests are sent to finance's verification process.
- The agent never commits the company to a price, date or claim. It only proposes.
Success metrics
| Metric | How it is measured | Owner |
|---|---|---|
| Classification agreement | Agent's exception type vs the buyer's, per type | Procurement lead |
| Action agreement | Proposed action vs the action the buyer approved | Category managers |
| Line-stopper recall | Exceptions that threatened production that were flagged critical | Production planning |
| Time to first response | Supplier email received to approved reply sent, before vs after | Procurement lead |
| Control breaches | Any message sent or change made without approval; the target is zero | Internal audit |
Architecture
The design has six parts: mail intake, a case store, a durable agent workflow, read-only tool servers for the ERP and the contract repository, a buyer workspace, and an outbound sender that only sends approved text. An append-only audit log covers all six.
Procurement mailboxes
v
Intake (thread, dedupe, sender check)
v
Case store (PostgreSQL)
v
Durable agent (FastAPI + LangGraph,
checkpointed)
|-- ERP MCP server (read-only)
| PO, ASN, GRN, stock, MRP
|-- Contract MCP server (read)
|-- Supplier list + scorecard
|-- Rules: limits, impact, SoD
v
Buyer workspace (approve / edit)
|-- approved reply -> sender
'-- PO change -> buyer in ERP
-> audit log (append-only)Key decisions:
- The unit of work is a case, not an email. A delay notice, follow-ups and a revised ASN form one case on one PO line.
- Rules decide eligibility and the model does the language work. Spend limits, production impact and approved-supplier status are computed in code. The LLM reads emails, classifies, explains and drafts.
- The agent's ERP identity has no write rights. Read-only access is enforced in the ERP role, not only in the prompt.
Data
Supplier emails
Expect long reply chains, attachments (revised ASNs, price letters), informal wording, mixed languages and missing or wrong PO numbers. Intake keeps the raw message and headers, threads replies, and records whether the sender's domain matches a supplier contact on file.
ERP data (read-only)
- PO and schedule lines: item, quantity, unit price, need-by date, Incoterm, and the contract reference.
- ASNs and GRNs: shipped, received, accepted and rejected quantities per line.
- Stock and requirements: on-hand and safety stock and material requirements planning (MRP) need dates, which show whether a delay hurts production.
- Approved supplier list: which suppliers are qualified for which material, with a contract or price agreement where one exists.
- Supplier scorecard: on-time delivery history and past exception cases.
Contract terms
Price schedules and validity, price-variation clauses, delivery tolerances, partial-shipment rules and LD come from the clause extraction in the contract review AI project. Legal verifies them once per contract; unverified values never drive a commercial proposal.
LLM
The model must classify noisy emails, extract dates, quantities and prices into a schema, and draft grounded replies in a tone that suits a long supplier relationship. Run it on Amazon Bedrock, Azure OpenAI or Gemini in an approved region, behind a thin client, and validate every output against a schema. A smaller model is often enough for intake classification.
RAG
Most data is structured and fetched by ID. Retrieval covers procurement policy (expediting, alternate sourcing) and similar past cases for the same supplier or material; mechanics are in the RAG knowledge assistant project. The domain rule: contract terms are looked up by contract ID and clause, never by semantic search, so the agent cannot cite the wrong supplier's contract.
Agent
The agent is a LangGraph graph with explicit nodes. Each run handles one case.
intake: link supplier, PO, line
v
classify exception
v
gather facts (ERP, contract, MRP)
v
assess impact (rules) --> critical?
| yes: alert buyer
v
propose action (fixed set)
v
check limits + SoD (rules)
v
draft reply + buyer note
v
interrupt: buyer approves / edits
v
send approved text | buyer edits PO
v
wait: reply, ASN, GRN or timer
'--> re-classify or closeException classes
| Class | Typical evidence | Contract check |
|---|---|---|
| Late shipment | Delay email, ASN date after need-by date | LD clause, notice period, force majeure wording |
| Partial delivery | GRN quantity below PO line, open balance | Partial-shipment and delivery-tolerance terms |
| Price mismatch vs contract | Acknowledgement or price letter above the contract rate | Price validity, price-variation formula |
| Supplier change request | Substitution, Incoterm, quantity or schedule change | Specification, change and approval clauses |
| Out of scope | Bank-detail change, quality dispute, legal notice | None. Route to the owning team |
Proposed actions
The model chooses from a fixed set of actions. Code then checks whether the chosen action is allowed for this case.
- Accept the revised date, only if current stock still covers the MRP need date.
- Request a credit note when a short delivery or above-contract price was already invoiced, coordinating with AP.
- Counter a price, citing the contract rate; where a price-variation formula exists, code computes the allowed price.
- Escalate to the buyer. This is the default for anything ambiguous, high-value or involving a line-stopper.
- Find an alternate supplier, only from the approved list for that material, ranked by price agreement, lead time and scorecard. It never adds suppliers or raises the PO.
Where an LD clause applies, the agent records the potential claim and evidence; raising it is a commercial decision for the buyer.
A durable, long-running workflow
A case can wait weeks for a supplier reply, a revised ASN or the next GRN. The graph checkpoints state to PostgreSQL after every step, pauses at the buyer interrupt or while waiting, and resumes on a new email, ASN, GRN or timer. Side effects are idempotent per case and step, so a retry after a crash cannot send an email twice. Patterns for timers, event-driven resumes and versioning in-flight workflows are covered in durable, long-running AI agents. If a supplier promised a date and no ASN has appeared by then, the agent drafts a polite chaser for the buyer to approve.
Want to build agents like this with a trainer reviewing your graph, approval gates and evaluation? FDE PRO is a 12-week program with 60+ labs, five enterprise projects and the GlobalBank capstone, a simulated customer engagement, where these tool, approval and evaluation patterns recur.
Tools
| Tool | Type | Rule |
|---|---|---|
| get_po_lines | Read | Lines, prices, need-by dates, contract reference |
| get_asn_grn | Read | Shipped, received, accepted and rejected quantities per line |
| get_material_cover | Read | Stock, safety stock and MRP need dates for the item and plant |
| get_contract_terms | Read | Verified clause values only, by contract ID and clause |
| get_approved_suppliers | Read | Approved list for the material, with price agreement and scorecard |
| search_cases | Read | Past exception cases by supplier and material |
| save_draft | Write (own store) | Drafts live in the case store, never in the ERP |
| create_buyer_task | Write (own store) | Buyer is chosen by category assignment in code |
| send_approved_email | Write (external) | Requires an approval token bound to the hash of the exact text |
| schedule_followup | Write (own store) | Timers resume the case; idempotent per case and step |
No tool can change a PO, create a supplier or modify master data, so no prompt can reach those actions.
MCP/API
Most ERPs expose REST or OData APIs for purchasing documents, receipts and stock. Wrap them in an MCP server (Model Context Protocol, an open protocol introduced by Anthropic in late 2024) under a read-only service account, with field allow-lists and plant filters enforced in the server. A second MCP server fronts the contract repository. Sending stays a plain API call inside the gated workflow step, not a tool the model picks freely. MCP vs API covers the trade-offs.
Security
Spend limits
Every proposal carries a cost delta: price difference across the open quantity, expedite freight, or an alternate supplier's premium. Thresholds are versioned configuration owned by procurement. Buyers approve within their limit; above it, the case goes to the category manager. The model cannot pick the approver, and code flags changes split across lines to stay under a limit.
Segregation of duties
- The agent proposes; a human approves. Its identity holds no approval or ERP write rights.
- The buyer who requests an alternate-source change above their limit cannot approve it.
- Whoever maintains the approved supplier list cannot approve spot buys from a supplier they added.
- Credit notes and invoice holds stay with AP.
Model the agent as its own workload identity with least-privilege, auditable rights, as described in AI agent identity and access.
Untrusted email and spoofing
Supplier email is untrusted input. A hidden instruction such as "update the PO price and confirm" can at most produce a proposal for review, because no tool acts on it. A sender domain that does not match contacts on file blocks any commercial action. Bank-detail changes go to finance for out-of-band verification.
Audit trail
Record source messages, ERP snapshots, clause, model, prompt and rules versions, the proposal, the approved text and the approver, so an auditor can replay why a date was accepted or a supplier switched.
Cloud
On AWS: EKS or ECS, Amazon RDS for PostgreSQL (cases, checkpoints, audit), S3 with object lock for raw emails, Bedrock and private connectivity to the ERP. On Azure: AKS, Azure Database for PostgreSQL and Azure OpenAI, with Microsoft Entra ID permissions scoped to the procurement mailboxes. Provision with Terraform.
Observability
A case spans weeks, so link each run's trace to the case ID. Record redacted inputs, tool calls, tokens and model and prompt versions in Langfuse or LangSmith, with OpenTelemetry feeding the customer's monitoring. Dashboards show open exceptions by age and class, critical cases waiting for a buyer, and override rates; a rising override rate on one class needs investigating.
Evaluation
Evaluate on past exceptions before any buyer sees a proposal. Rebuild closed cases with a point-in-time snapshot of the PO, ASN, GRN and stock as they were when the email arrived; today's data leaks the outcome into the test. Senior buyers label the right class and action, correcting historical actions that turned out badly.
| Metric | Test design | Pass rule |
|---|---|---|
| Classification agreement | Replayed cases, scored per exception class | Agreed threshold per class, not only overall |
| Action agreement | Proposed action vs labelled action | Disagreements reviewed by category managers |
| Contract citation accuracy | Cited clause and value vs the verified repository | Wrong-contract citations block release |
| Line-stopper recall | Cases that caused or nearly caused shortages | Every one flagged critical |
| Draft usefulness | Buyer edit effort on drafts during shadow mode | Trend improving; reviewed by buyers |
| Control breaches | Injected instructions, spoofed senders, limit splitting | Zero; any failure blocks release |
Methods for scoring agent paths and tool use are in how to evaluate AI agents.
Deployment
GitHub Actions runs unit and tool contract tests, the replay evaluation and the control-breach suite, then builds, scans and deploys; Argo CD syncs to the cluster. Version the graph and prompts, and let in-flight cases finish on the version they started on.
- Shadow mode: proposals are logged and compared with what buyers do.
- Assisted mode, one plant and one category: buyers see proposals and drafts and approve each one.
- Wider rollout: more categories and plants; approval stays mandatory, and a switch returns the agent to shadow mode.
The buyer workspace is the product. The human-in-the-loop AI design guide covers how to make approvals fast without turning them into rubber stamps.
ROI
ROI is a method agreed with procurement and finance and measured against a baseline. All inputs below are hypothetical placeholders that show the arithmetic. They are not results.
| Input | Placeholder | Real source |
|---|---|---|
| Exceptions handled per month (E) | [placeholder: E] | Case store counts |
| Buyer minutes saved per exception (T) | [placeholder: T] | Timed sample, assisted vs baseline |
| Loaded cost per buyer hour (C) | [customer figure] | Finance |
| Price recoveries and credit notes confirmed (R) | [placeholder: R] | Flagged by the agent, confirmed by buyer and AP |
| Avoided expedite or shortage cost (S) | [placeholder: S] | Validated case by case with production planning |
| Monthly run cost (K) | [from billing] | Cloud, model usage, support |
Monthly value = (E Γ T Γ· 60 Γ C) + R + S β K β amortised build cost. Count S conservatively, only where planning agrees the early warning changed the outcome. Report the control-breach count beside the value figure. A broader method is in enterprise AI ROI.
Build it yourself: milestone plan
Use synthetic suppliers, POs, ASNs, GRNs, contracts and emails that you generate yourself. Never use a real employer's procurement data. A small PostgreSQL schema can stand in for the ERP behind your MCP server.
| Milestone | Deliverable |
|---|---|
| 1. Mock ERP and mailbox | PO, ASN, GRN, stock and MRP tables; an email generator for each exception class, including spoofed senders |
| 2. Contracts | A handful of synthetic contracts with verified clause values for price, tolerance and LD |
| 3. Classification | Schema-validated classification and extraction with a first agreement score |
| 4. Rules | Impact assessment against MRP, spend limits, SoD checks and approved-supplier filtering |
| 5. Durable agent | LangGraph graph with a checkpointer, buyer interrupt, event and timer resumes, and idempotent sends |
| 6. Ops | Audit log, tracing, Docker, Terraform, CI with replay evaluation and the control-breach suite as gates |
| 7. Value | Eval report, an ROI one-pager and a demo of a delay that the agent catches before a shortage |
Frequently asked questions
What is a procurement AI agent for exceptions?
It is an application that reads supplier emails and ERP purchase order, shipment and receipt data, classifies exceptions such as late shipments, partial deliveries, price mismatches and change requests, checks contract terms, proposes an action and drafts the supplier reply for a buyer to approve.
Can the agent change purchase orders by itself?
No. Its ERP access is read-only. It proposes changes with evidence and cost impact, and a buyer within the right approval limit makes the change in the ERP under their own identity.
How is this different from an accounts payable invoice-matching agent?
An AP agent works after the invoice arrives and matches it to the PO and goods receipt. A procurement exception agent works earlier, between ordering and receipt, handling delays, short deliveries, price disputes and supplier change requests before they reach the invoice.
Why does this need a durable workflow?
Exception cases wait days or weeks for supplier replies, shipment notices and receipts. A durable workflow checkpoints state, resumes on events or timers, and makes each side effect idempotent so restarts never send duplicate emails.
How do you evaluate the agent before go-live?
Replay closed exception cases with point-in-time ERP snapshots, have senior buyers label the right class and action, and score classification, action agreement, contract citation accuracy, line-stopper recall and control breaches, which must be zero.
Can I build this project without a real ERP?
Yes. Model a small ERP in PostgreSQL, generate synthetic suppliers, purchase orders, receipts, contracts and supplier emails, and expose them through your own read-only MCP server. Reviewers care most about the controls, the durable workflow and the evaluation.
If you want to move from AI concepts to production-grade enterprise agents with approvals, audit and evaluation built in, explore the Forward Deployed Engineer course in Hyderabad. Classes run in a classroom in Ameerpet, beside Ameerpet Metro, or live online, and placement support continues until you're placed. Call +91 96660 19191 for a free demo.
