A 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
Solution Studio Order Support Agent
Order questions and in-policy returns are settled in the chat, and every case that needs judgment reaches a person with the evidence attached.
WISMO, a post-purchase support agent on the retailer's own site that settles what policy allows and hands everything else to a person.
What the agents do
Resolves order questions and in-policy returns itself, and hands damage claims, delivery disputes and anything outside policy to a person.
- Contributed by
- MACH Alliance (Reference implementation)
- Industry
- Retail
- Audience
- B2C
01
The problem
Why this exists
Most post-purchase contacts are routine: where is my order, can I return this, it arrived damaged, it never arrived. Each one still needs someone to look up the order and the carrier record, and to apply the return policy correctly.
Read more
A chatbot that only answers questions leaves the customer waiting for a person anyway. One that is allowed to grant refunds from the conversation lets the model decide money, which no retailer will accept. The hard part is deciding exactly which outcomes an agent may settle alone, and making sure everything else reaches a person instead of an empty promise.
02
Outcomes
What this demonstrates
- Tracking answers come from the order and carrier records, never from the model's memory.
- Returns within the policy's window and refund ceilings are approved on the spot, with a return label, from a single conversation that can cover chosen items on a multi-item order.
- Damage claims and delivery disputes always reach a person, with the customer's photo, the conversation and the policy rule that sent the case there. A live countdown shows the customer the case is with someone.
Read more
- The decision policy is shown in plain English, can be changed through a Policy Helper, is validated before it goes live and keeps every earlier version for rollback.
03
How it works
Architecture
Three apps: a retailer storefront with the chat widget, an agent API built on Hono and Mastra, and the Escalation Desk, the rep's console. The storefront is a fictional outdoor-gear retailer.
Read more
The chat agent runs on Claude and works through tools that look up orders and shipments and request refunds. Who the customer is comes from the server-side session, and every order, amount and carrier fact comes from the order system. The server keeps its own copy of each conversation, so a forged history from the browser changes nothing.
A refund, return or delivery dispute opens a case, which is one run of a Mastra review workflow. The workflow asks a versioned policy document what may happen. Deterministic code evaluates it: restrictions first, then explicit approve or decline rules, and the fallback is always a person. If the policy allows an automatic outcome the case resolves there; otherwise the run suspends, and the suspended runs are the Escalation Desk queue. There is no separate queue database.
A rep can approve, reject, change the amount, ask the customer a question or escalate to support, which resumes the same run. The customer's open chat updates over server-sent events and a stubbed email goes out. A case nobody answers within the response window opens a support ticket automatically.
Money moves through one function, which re-checks the policy and other open cases on the order under a per-order lock. A spending ceiling outside the policy caps automatic approvals, and no policy edit can raise it. Replies are checked so that amounts, dates and case IDs must appear in a tool result or the customer's own words. Orders, payments, carriers and notifications run against local fixtures behind the interfaces a live system would use.
Open standards used
REST APIs
Tech stack
MastraClaude (Anthropic)HonoLibSQLVercel AI SDKNext.jsassistant-uiServer-sent events
Everyone credited on this solution
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 settling routine post-purchase support without losing the human fallback, 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.
Related solutions
Shoppers get an answer on the product page in under a second, grounded in documents the brand controls.
Solution Studio Product Insights Agent
Solution StudioInbound purchase orders are read and routed automatically, with people reviewing only the uncertain ones.
Solution Studio: B2B Order Intake Reference Pipeline
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.
What this page does not establish
- Measured results. The prototype runs on fictional demo data, and nothing has been measured in a live deployment.
- Production readiness. The repository lists what is out of scope, including authentication, a real ticketing system, limits on what a customer can send and legal review, and documents how to close each gap.
Where this came from
Written from the public repository README and its setup, production-considerations and implementation guides. It is a reference prototype on fictional demo data, not a production deployment.
Status: Reference prototypeAdded Nov 2, 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.