Common Table

• 

  The kitchen marks Nordique unavailable. The €70 cart stays unchanged, making the conflict visible before repair.

• 

  WebMCP preserves four lines and replaces only Nordique with Forestière. Total: €68.50. All four group constraints remain satisfied.

Inspiration

A group order can satisfy everyone's needs—until the kitchen runs out of one ingredient.

The person coordinating the order must then find a replacement without breaking the budget, losing dietary preferences, or discarding choices that still work. That fragile moment inspired Common Table: a storefront where a human and an agent collaborate on the same visible cart.

The goal is simple: repair what changed, preserve what still works, and leave the final decision to the person.

What it does

Common Table demonstrates a complete, reproducible scenario:

1. An agent calls build_group_order to create five meals within a €70 budget, including two vegetarian meals and no declared peanuts.
2. A person simulates a kitchen stockout. Nordique becomes unavailable, but the existing cart remains unchanged so the conflict stays visible.
3. The agent calls repair_unavailable_cart_items without increasing the budget.
4. Four cart lines are preserved. Only Nordique is replaced, with Forestière. The total falls to €68.50, and all four group constraints remain satisfied.

The agent cannot place or pay for an order. The final review remains a human action.

How I built it — with Codex agents

One human, a team of Codex agents.

I built Common Table as a solo developer, working with Codex agents on implementation, testing, evidence review, and demo production. I made the product decisions and reviewed the final result. The demo narration is my own voice.

The page registers two narrowly scoped, typed tools through document.modelContext.registerTool. Both tools use the same deterministic domain functions as the visible fallback controls. People and agents therefore operate on one shared in-memory state.

Tool results expose cart and catalog revisions, constraint checks, and explicit changes. The repair result identifies preserved items, removed and added items, the number of changed lines, and the price difference.

The application uses JavaScript, HTML, and CSS, has no runtime dependencies, and runs on GitHub Pages. The public repository includes an MIT license, run instructions, syntax checks, and six automated tests.

Challenges

The main challenge was defining what an agent is allowed to change.

A repair must preserve available cart lines, respect the active group constraints, and never silently relax the budget. Invalid inputs or impossible repairs must fail without mutating the cart.

Making those boundaries understandable was equally important. Common Table keeps the unavailable item visible, shows the constraint checks, and records the effect of each action.

Accomplishments and learning

The key result is measurable: four lines preserved, one replaced, and a valid cart restored.

Common Table goes beyond generating a shopping basket. Its focus is the next interaction: recovering from a change while preserving the valid choices already made.

I learned that WebMCP becomes especially useful when a site exposes meaningful operations with explicit effects—not just another way to click its buttons.

Deliberate boundaries

This is a synthetic demonstration using eight fictional menu items. There is no backend, merchant or customer data, real order, payment integration, or production connection.

Dietary filtering uses declared synthetic attributes only; it is not a medical guarantee. The demonstrated result is a reproducible technical proof, not evidence of real-world adoption.

What's next

The challenge scope is intentionally frozen around this working demonstration. A future evaluation could test the same repair approach with larger catalogs, multiple simultaneous stockouts, and more varied group constraints, while retaining the human decision boundary.

Built With

• css
• github
• html
• javascript
• node.js
• openai-codex
• webmcp