Foyer — Daniel Wu

Background & Challenge

Commerce tooling was built for human shoppers—people who look at images, hesitate, and respond to persuasion. But by 2026 a growing share of orders no longer comes from a human at a keyboard; they come from AI shopping agents that parse catalogs, evaluate products programmatically, and place orders on behalf of the human behind them. They don’t respond to a lifestyle photo or a “limited-time offer.” They want structured product truth, machine-readable return rules, and explicit trust signals.

Merchants have no surface built for any of this: no way to decide which agents to trust, what each is allowed to buy, when a human should intervene, or what actually happened afterward. The payment protocols (Visa, Mastercard, Stripe × OpenAI, Google AP2) solve “how does an agent pay,” but “how does a merchant govern the agents coming in” is open space—no one has built it as a complete, well-crafted product. Foyer is that control plane, sitting on the merchant’s side to receive and govern inbound agents.

I chose this subject deliberately, to add the most forward-looking piece to my portfolio: one step past “can you design a B2B system”—designing for a non-human user, an AI agent—turning “From UX to AX” into a product with real screens, real flows, and an argument that lands in one interaction.

Foyer overview dashboard: agent-driven GMV, active agents by trust tier, the auto-approved vs. human-gated ratio, and a feed of flagged events — The control plane at a glance — agent-driven GMV, agents by trust tier, the auto-approved vs. human-gated split, and the events that tripped a gate.

Research & Design Decisions

The research deliberately set up three personas, one of which isn’t a person: Mara (the merchant’s agent-channel manager, the primary human user), Maple (an AI concierge agent shopping on a real person’s behalf—the non-human user we design for), and Dana (the human principal behind Maple). The fact that one user isn’t human shaped the entire product.

Signature interaction

Human ↔ Agent ↔ Diff: one product, two information designs

The memorable moment of the project is the view toggle on the product page. The human view is the familiar storefront—hero imagery, scent story, ratings, badges—designed for an eye that can be persuaded. The agent view turns the same product into a structured credential card—GTIN, machine-readable price and stock, returns as explicit rule fields, authenticity and MAP-compliance flags—that reads like a customs document. The diff view places the two side by side and marks, field by field, “this one is for humans / this one is for machines,” each with the design rationale. One interaction proves the thesis: designing for agents isn’t building an API—it’s giving the same information two entirely different information architectures for two fundamentally different readers.

Product page diff view: human surface on the left, agent surface on the right, each field annotated with its design decision — The signature interaction: the same product's human and agent views side by side, each field marked 'for humans / for machines' with the design rationale—amber = human-only, green = agent-only.

Agent directory: a roster of agents sorted into four trust tiers, each with a trust score and recent activity — The agent directory — every agent carries an identity and a trust score, sorted into four tiers (Verified Concierge → Anonymous), each calibrating how much oversight applies.

Policies page: a per-agent override for Maple Concierge with spend caps, MAP enforcement, and an approval threshold — The rule-authoring surface — spend caps, a MAP floor, approval thresholds and more, set per tier and overridable per agent. Maple's override tightens its per-order cap to $2,000.

Transaction detail's three-column layout: agent intent, event timeline with the HITL gate, and the trust evidence panel — The hero transaction: a three-column decision desk—agent intent on the left, a live timeline and the HITL gate in the center, trust evidence on the right. The $4,200 order exceeds the cap and waits here for a human to approve, decline, or modify.

Outcome & Reflection

The result is a deployed interactive prototype of nine pages: Overview, agent directory and detail, the agent-readable product page (Hero 1), the policy builder, a live activity stream, the transaction detail with its HITL gate (Hero 2), returns and disputes, and settings and onboarding. The human/machine duality is carried by typographic treatment: the human view is familiar e-commerce layout, while the agent view switches to uppercase micro-labels, wide tracking, tabular-aligned figures, and hairline ledger rules — so the same information reads like a spec sheet or a customs form. One confident green accent color carries every trust signal, and light/dark themes are driven by CSS variables.

Agent credential card (light): canonical ID, GTIN, structured attributes, machine-readable price and stock — The agent credential card: the same product as a machine-readable, structured credential that reads like a customs document; light and dark themes are driven by one set of design tokens.

Agent credential card (dark) — The agent credential card: the same product as a machine-readable, structured credential that reads like a customs document; light and dark themes are driven by one set of design tokens.

Engineering followed the controlled-demo approach: freeze the types and mock-data contract first, TDD the pure logic (trust scoring, the policy engine, the HITL gate reducer), then compose the pages and gate everything on build, unit tests, and Playwright hero flows. Every “AI behavior” is a scripted, deterministic fixture rather than a live model—so the demo runs identically every time and stays quality-controlled (the $4,200 order that trips the gate has to exist “just so” for the story to hold).

The boundaries are just as clear: no real payments, no real LLM, no real backend—everything is bounded by “the clickable prototype that best shows AX design thinking.” But the point of this case isn’t to ship an agent-commerce product; it’s to demonstrate one thing—when the user is no longer human, the UX problems of information design, trust, and human-in-the-loop still hold; the audience has simply become a machine.