Trailhead Outfitters: The Merchant's Agent

Inspiration Every demo of agentic commerce stops at the same frame: an AI clicks "buy." Real merchants know the sale starts at checkout and ends when the money is settled, the parcel is tracked, the dispute is answered, and the seller is paid. We asked: what does commerce look like when an AI agent doesn't just pay, but stands behind the sale? PayPal already owns the hardest part of that lifecycle: buyer protection, dispute tooling, tracking, payouts. We built the agent that puts all of it to work.

What it does Trailhead Outfitters is a small outdoor-gear storefront whose only employee is Avo, an AI merchant's agent powered by GLM 5.3 Flash (Z.ai) with PayPal as the money rails:

Sells. Avo searches the catalog, compares pay-in-4 vs financed monthly costs with real amortization math, and creates PayPal orders from conversation. The customer approves with PayPal Buttons, including Pay Later and Venmo, in-context.
Confirms. Completed captures are reflected in the shop's order rail with live PayPal status.
Stands behind the sale. Avo knows PayPal's dispute system: it maps each dispute reason to the exact evidence PayPal requires (proof of fulfillment, proof of refund, carrier and tracking numbers) and assembles the response payload. The dispute-evidence and shipment-tracking clients ship in the repo today, unit-gated; their automatic webhook triggers are the next build.
Is itself agent-addressable. The storefront runs its own MCP server: any external AI agent can browse the catalog, create PayPal orders (receiving a live approve URL), check order status, and process refunds.
Is durable and safe. Orders and chat sessions survive restarts (SQLite locally, Cloudflare D1 in the cloud); chat is session-isolated; mutating surfaces are session-bound or bearer-gated; the hosted Worker runs on Cloudflare's always-on runtime.

How we built it

PayPal is the protagonist. Orders v2 (create/approve/capture), JS SDK buttons with Pay Later and Venmo funding, Add Tracking API, Disputes API reason-to-evidence mapping, refunds, all against the PayPal sandbox, with every demo payment verifiable in the sandbox business account's activity.
GLM as the merchant's brain. Avo is a tool-calling loop over GLM 5.3 Flash (Z.ai): search_catalog, compute_financing, create_order, get_order, with a permanent scope gate so the event path that renders the PayPal button cannot silently regress.
MCP on both sides of the checkout. Our storefront exposes an MCP server (catalog, orders with live PayPal approve URLs, refunds), while PayPal's own hosted MCP server exposes the same orders from their side, cross-verifiable through their native agentic protocol.
Zero dependencies, kept running. The server is pure Node built-ins (no npm, no frameworks); state is a storage seam over SQLite/D1 with first-class webhook idempotency; every behavior has a mechanical gate and a smoke suite; the Worker deploys via a pure-Node Cloudflare REST script.

Challenges we ran into PayPal's sandbox redirect approval can trigger a phone-verification wall (with a fake SMS that never arrives), so we moved to the in-context popup flow. Sandbox REST app credentials can ship a dead secret key; PayPal's per-app dual-key rotation saved us. Agentic event plumbing has a nasty failure mode where the payment succeeds but the button never renders; we turned that exact bug into a permanent regression gate. And an open MCP endpoint must never mean an open refund endpoint: mutations are token-gated, captures are session-bound.

Accomplishments we're proud of The full lifecycle arc in under three minutes: conversation, pay-in-4 math, PayPal approval, capture, tracking, dispute evidence, payout readiness. The same orders visible through PayPal's own hosted MCP server: our books and PayPal's agree, verifiable in Postman during the demo. Zero third-party code dependencies; the whole shop is auditable in an afternoon.

What we learned Thorough PayPal integration is cheap: each lifecycle surface (tracking, disputes, payouts) is roughly one endpoint. The win is composing them into an agent that actually runs the store. Agentic commerce needs the boring half of commerce: the buy button is the demo, the dispute template is the product. Session isolation and mutation gating are not security theater for a hackathon; judges will open two browser tabs.

What's next Payouts close-out for multi-seller markets, subscriptions for recurring revenue, and the Agentic Commerce Protocol once it doesn't require a separate processor relationship. Giving every small merchant a one-file agent: drop server.js on any host, paste two sandbox keys.