Shortage-response agents over live SAP data

A global manufacturer ran materials planning across nine plants out of SAP ECC. Planners spent their mornings reading MRP lists (the MD04 screen) trying to work out which of tens of thousands of material-plant combinations would actually go short, and buyers chased suppliers by hand when forecasts moved.

What we built

Two agents on a shared foundation. The shortage agent reads the projected stock balance for every purchased part, finds where it crosses zero within the planning horizon, checks whether an advance shipping notice exists for the receipts that are supposed to cover it, and ranks the results by dollar exposure and how many parent assemblies depend on the part. The supplier-messaging agent compares monthly forecast snapshots, finds volume swings inside and outside each part's lead time, and drafts the supplier email for the buyer to review and send.

Architecture

SAP Data Services extracts to BigQuery on a timestamp delta. A set of curated views encodes the business rules (which MRP elements count, how safety stock is treated, how transit time is added to lead time). An MCP Toolbox service on Cloud Run exposes nineteen fixed tools over those views; the agent runtime has no BigQuery access of its own, so the toolbox is the only data path. Vertex AI Agent Engine hosts the agent and Gemini Enterprise is the user surface.

What made it work

• Requirements written down and signed. Seven revisions of a business requirements document, each one recording which decision changed and who made it. When the business reversed a factor definition mid-build, the register showed it.
• Snapshot discipline. The QA environment was a system copy; MRP kept running but no business documents were created after the copy date. Diagnosing that early stopped a false "the feed is broken" theory from derailing week three.
• Evaluation before pilot. 190 unit tests, 25 data invariants checked against production, 40 business prompts, plus a faithfulness check that caught the model narrating a wrong answer and led us to pin the model version and add a verbatim rule.
• Change-advisory-board ready. Functional and technical specs written for the client's CAB, with a planned back-out and an explicit "no automatic model fallback" statement.
• The pilot ledger proved it, not the demo. Twenty pilot interactions were reconciled against live SQL: four confirmed defects, six basis disagreements, two tool gaps, three wins, five out of scope. Worst find: a planner asked about missing shipping notices and was told none, though a dozen were unconfirmed. Only one of five defects pinned on a model upgrade was actually fixed by it.
• The toolbox was validated, not assumed safe. Fifteen automated tests, gating every deploy, check the views against the raw balance and refuse a bad dataset, a write, or malformed SQL — proof that "the toolbox is the only data path."

Outcome

The shortage agent went to production on schedule and a pilot group of planners started the following Monday. The daily view is now "the single most critical shortage per plant" for the morning plant-manager call. The supplier-messaging agent followed in the next gate, draft-only by design until the security team approved the mail integration.

Two operations runbooks, one per agent, list only failure modes that actually happened: nine for the shortage agent, eleven for the messaging agent, since it drafts outbound mail and human approval is contractual. Both were walked through with the client's IT team and marked accepted the next day — a draft under active negotiation, but enough for the client's own team to triage and roll back without us on the call.

All case studies