From Chat to Completion: The Missing Links in Agent-Driven Procurement Workflows

The article opens with a concrete failure: a purchasing manager posts "Warehouse No.1 bearing replenish 60 pieces, process per this" in a chat group. The assistant replies "Received." Half an hour later the purchaser finds no document in the system. Developers discover the formal approval flow passed and the approval content includes Warehouse No.1, but the parameter passed to the creation tool omitted the warehouse code. The flow stalled at pre-submit while the UI still showed "Processing."

The previous article discussed what to delegate to the system; this one continues: after manual approval, how does the work actually continue? The same hypothetical case — Warehouse No.1, SKU6204, 60 pieces, supplier SUP01 — is used. The process and checklist have not been tested in a customer system.

What "Done" Really Means

Agreement for this run: create a purchase order in the original procurement system, verify details match the approval, reach the agreed status, then hand over the document and result to the purchaser. Supplier acceptance and goods receipt remain the purchaser's responsibility under the original process.

If the interface only creates a draft, agree upfront that this run stops at draft creation and verification. If the business needs formal submission, the later steps must be completed — do not hand over a draft number at delivery. Define the endpoint first; otherwise every step can claim "I'm done" while the whole thing stalls.

Next Step Needs More Than "Agreed"

Record the suggestion as REPL01 with product, warehouse, replenishment period, quantity, rules, and source. Submission for approval must include supplier, amount basis, and the target step. Approval targets a specific version; the creation request links that version and the valid approval. The chat message "process per this" is communication; real submission must find the formal approval record and verify what it approved. The original approval system already has an approval ID — link directly, don't invent a new one for the assistant; the purchase system's returned document number is kept as-is.

Handoff Checklist

Form suggestion — Needs: verified product, warehouse, records, replenishment rules. Passes: versioned suggestion with calculation basis.

Request approval — Needs: product, quantity, unit, supplier, amount basis, target step. Passes: authorized personnel's approval or rejection record for this version.

Prepare execution — Needs: approval record, corresponding parameters, current business conditions. Passes: checked creation parameters; if something missing, leave pause reason.

Call procurement API — Needs: this request ID, parameters, execution identity, approval basis. Passes: what was sent, when, what receipt received.

Verify result — Needs: original request, trusted receipt or original system query. Passes: whether document matches approval, what remains unclear.

Hand back to purchaser — Needs: document, verification result, follow-up items. Passes: actionable processing record; exceptions routed to appropriate role.

Existing process systems can connect these steps; the Agent helps understand, organize materials, and call tools — not every step needs an intelligent agent. Before handoff, check what the next step needs. Missing price basis? Pause before submission, assign to price owner. Warehouse code mismatch? Pause before submit, notify integration owner; don't let the model fill randomly. After fixing mapping, confirm it still matches the approved Warehouse No.1. Pauses must be visible: record step, reason, assignee, deadline; show reason on page. If overdue, notify designated owner. A backend log "parameter missing" leaves the purchaser waiting.

After "Processing", Must Be Able to Query What Happened

The assistant can show statuses: pending materials, pending approval, pending submit, processing, pending verification, created and verified. Names are not important; each change must have evidence. No approval record? Cannot write "approved." Parameters not ready? Show pause reason, not "processing." Assistant task progress differs from approval system "passed" and purchase system "draft/submitted" — each system speaks its own state. Assistant shows "pending verification," purchase system may not have that state; approval passed does not mean purchase order created. Use OPM (Object Process Methodology) with business to separate these records and changes. Ontology clarifies: which approval targets which suggestion version, which creation bases on which approval, finally which document generated. Program follows these links to update progress. These links and processing records must persist. Reopen session, different person takes over, must find same task. Cannot have LLM read chat and guess step.

Approved Yesterday, Still Check Before Submit Today

Example: 60 pieces approved, but another purchaser already replenished, or product suspended. Original suggestion was fine then; now may need recalc or cannot proceed. Before submit, re-check mutable conditions per agreement. Quantity, supplier adjustments — check if within original approval scope; exceed scope requires re-approval. Approval withdrawn, operator permissions changed — catch here. Two people check simultaneously, both think "not yet replenished." Original system checks must remain; for same demand, only one in progress? merge? cumulative quantity control? Processing program must coordinate per business agreement. Distinguish: same request resent twice — idempotency at execution end prevents duplicate document; two people submit two different requests — even without retry, may duplicate purchase. Latter needs demand-level check.

Interrupted Midstream, First Check What Step Completed

Assume document created, details verified, only notification failed. Fix: resend notification, not create new order. If creation request not sent, re-check current conditions and approval, continue from submit. Hardest: request possibly sent but no clear result. Program restart finds no success record — cannot assume not created. First trace original request, verify; if unclear, keep "pending verification," don't restart with new number. Specific query/retry in next article (07). User cancellation: distinguish how far processed. Block further submissions, but original system may have received request. If document generated and business requires revocation, follow original system permissions/conditions. This "reverse operation to offset prior effect" is "compensation." Microsoft Compensating Transaction pattern: considers business rules and intervening changes, not necessarily restore original state. Here, revocation success must check purchase system; cannot delete assistant task record and claim document revoked.

Deliberately Break It, Can Someone Else Take Over?

Test normal flow in test env: get valid approval, create and verify document, hand to purchaser. Then arrange missing materials/interruptions, check where program pauses, if responsible personnel can take over.

Test Scenarios and Expected Handling

Missing price basis before submission — Pause at material completion, assign to price owner; do not seek vague approval first.

Approval done, creation parameters missing warehouse code — Pause and notify integration owner; after fixing, still verify it matches approved Warehouse No.1.

Product suspended after approval — Detect at pre-submit, pause with reason.

Process exits after creation request sent — Retrieve original request, continue verification; do not create new request.

Creation completed and verified, notification failed — Keep document result, only resend notification.

User cancels while original system still processing — Block new submissions, continue verifying original request.

Exceeded agreed verification time, result still unknown — Keep unknown, hand materials to designated owner, record whether taken over.

Handoff: provide task and request IDs, corresponding approval, confirmed results, unresolved items, where to continue. Allowed operations clarified. Assignee should follow records, not read hundreds of chat messages. Test with uninvolved person taking a task, see what materials missing, which step still requires asking project team.

Summary

Back to the stuck replenishment: besides fixing the warehouse code, the process should timely tell the purchaser "paused before submit, finding who handles" and give the assignee the original suggestion and approval. After fix, continue from the appropriate point. The purchaser waits not for "received" but to know if document created; if not, tell where stuck and who handles. Records must update on resume. Remaining question: whose permissions are used to query data, create orders? Next article discusses.

References

Microsoft Learn, Compensating Transaction pattern. Explains compensation after cross-step failures is business-relevant and need not restore original state; purchase status and handoff tables in this article are author-designed.

https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction