Order questions and in-policy returns are settled in the chat, and every case that needs judgment reaches a person with the evidence attached.
Solution Studio Order Support Agent
Solution Studio
Solution Studio: B2B Order Intake Reference Pipeline
Inbound purchase orders are read and routed automatically, with people reviewing only the uncertain ones.
Inbound purchase orders by email or EDI, extracted and routed by AI, with a human review queue for the edge cases.
What the agent does
Extracts a structured order from free-form mail, spreadsheets or trading documents, rates its own confidence, and pauses for review when it is low.
- Contributed by
- MACH Alliance (Reference implementation)
- Industry
- Manufacturing & Industrial
- Audience
- B2B
01
The problem
Why this exists
Inbound purchase orders arrive in whatever shape the customer sends them: a free-form email, a PDF, a spreadsheet, or a structured X12 850. Handling that variety is normally either manual re-keying or a per-format parser that breaks whenever a customer changes a template.
Read more
The harder part is what happens when the extraction is uncertain. A pipeline that fails closed sends everything to a person, and a pipeline that fails open puts wrong orders into the ERP. What is needed is a flow that can pause on the specific orders it is unsure about, survive a restart while it waits, and then carry on from where it stopped.
And underneath all of it: every integration point in this domain, the ERP, the mail provider, the EDI transport, the customer lookup, is a system the adopter already has and will not be replacing.
02
Outcomes
What this demonstrates
- Extraction covers free-form emails, PDFs, CSVs, XLSX spreadsheets, and X12 850 EDI documents, producing structured order entities with self-assessed confidence scores.
- Human review is a first-class state rather than an error path. LangGraph interruptBefore plus a PostgreSQL checkpointer pauses the graph at review, persists state across restarts, and resumes through the full pipeline when the operator acts.
- Formal EDI responses are generated automatically or on operator request: X12 864 Text Message for clarification and X12 855 Purchase Order Acknowledgment for rejection.
Read more
- Every integration point is swappable behind an interface. Changing INBOUND_MAIL_PROVIDER to sendgrid switches the pipeline from polling to webhook delivery with no graph changes.
- The React operator interface consumes the pipeline exclusively through REST endpoints, so the UI is fully decoupled from business logic.
03
How it works
Architecture
Two independent inbound channels feed the pipeline: an email channel that polls or receives webhooks and handles plain text and PDF, and an EDI channel that polls an inbox folder for X12 850, CSV, and XLSX. Adding a channel means one new adapter class.
Read more
The pipeline itself runs as a stateful LangGraph graph. Each order is a graph invocation with nodes for intake, extraction, validation, and routing. Making the flow an explicit graph is what makes it inspectable and resumable rather than a sequence of jobs. Routing has four outcomes: submit to the ERP adapter, clarify through the notification adapter, reject through the EDI outbound adapter, or hold for review.
Review is where the graph pauses. interruptBefore combined with a PostgreSQL checkpointer persists the graph state, so an operator can act hours later or after a restart and the run continues from the same point.
Eight adapters sit behind defined interfaces: ERP, inbound email, notification, customer lookup, SKU resolver, extraction, logging, and EDI outbound. Defaults are a database stub for ERP, Mailpit for mail, a JSON file for customer lookup, and Claude for extraction and SKU resolution. Each is selected by an environment variable, so swapping to SAP, NetSuite, Dynamics 365, SendGrid, SES, Postmark, Salesforce, Datadog, CloudWatch, a VAN API, or AS2 is configuration rather than code.
PostgreSQL 16 holds orders, the audit log, and the LangGraph checkpoints. An Express REST API under /api/v1 is the only interface the React Agent Control Interface uses, which is what keeps the UI headless: live feed, human review, submitted orders, and audit log all read the same endpoints an adopter's own front end would.
Open standards used
EDIREST APIs
Tech stack
ClaudeLangGraphPostgreSQL 16ExpressReactX12 850 / 855 / 864 EDI
Next step
Take the code
This one is published in full. Read it, run it, fork it. Nothing here is behind a conversation.
Request an intro
This one is the MACH Alliance’s own work. Ask about automating inbound order handling, and the people who built it will answer.
Not ready to talk to anyone? MACH Insider is the Alliance mailing list. New solutions, program openings, and the research behind them, once a month.
Everyone credited on this solution
- MACH AllianceReference implementation
Every organization named here has a page listing the rest of its work on the Hub.
Related solutions
In six weeks, Dr. Martens and Conscia built a prototype on-site shopping assistant for drmartens.com that could search, size, and add to cart.
Dr. Martens On-Site Shopping Assistant
AI Exchange HackathonA stated goal becomes a finished look, so a shopper who cannot phrase a query still gets a usable answer.
Solution Studio Shopping Greeter
Solution Studio
Verification
Public code
The implementation is published in full, so anything on this page can be checked against the repository. Anything the repository does not show is not established here.
Where this came from
Published as an open MACH Alliance Solution Studio reference implementation. It is a reference implementation rather than a production deployment.
Status: Reference prototypeAdded Jun 12, 2026A listing is an editorial decision, not a MACH Alliance certification.
Built something worth showing?
Put your agentic solution in front of the enterprise leaders who use the hub to decide what to build next. Submissions are open to MACH Alliance Members, Collaborators, or Ambassadors.