Architecture
UX For AI: Hint — AI Doesn't Want To Browse To Get Shit Done
You built a search-then-select-then-checkout flow. For a machine. The machine would like a word.
Your AI agent walks into a booking system. It knows exactly what it wants: a 10x10 storage unit in Dallas, climate controlled, under $100, starting June 1st.
Your system says:
- “Great! First, search for available units.”
- “Here are 47 results. Please select one.”
- “Add to cart.”
- “Proceed to checkout.”
- “Enter payment details.”
- “Confirm.”
Six steps. The agent knew what it wanted in step zero.
You built a human shopping experience and made a machine use it. The machine doesn't want to browse. It doesn't want options. It doesn't want a cart. It doesn't want a checkout page. It wants to send ONE message and get ONE answer: executed or “here's what's missing.”
That's not how any existing system works. Every booking API, every commerce platform, every OTA follows the same pattern that's been unchanged for 60 years:
The Industry · 60 Years
- Steps
- 6–8
- Round trips
- 3–5
- Failure modes
- At every step
- Agent time
- Seconds to minutes
Now do the math. A modern agent making a booking spends most of its life waiting on protocol overhead, not thinking:
The Latency Budget · Per Transaction
- Round trips
- 6
- Latency / hop
- 200 ms
- Retry multiplier
- 1.6 ×
- Total per booking
- 1.92 s
Here's what an agent actually needs:
This Dispatch
(or: exactly what's missing + how to fix it)
- Steps
- 1
- Round trips
- 1
- Failure modes
- Zero
- Agent time
- < 2 seconds
One message in. One outcome out. If the message is complete, the transaction executes. If it's incomplete — and this is the whole game — the system doesn't return an error code. It returns the next move. The agent acts on it. Done.
Not “400 Bad Request.” Not “missing required field: unit_size.” Not a diagnostic error that the agent has to parse, interpret, and guess how to fix. The whole 60-year pattern of return-an-error-let-the-caller-figure-it-out is the bug.
The agent doesn't search. Doesn't browse. Doesn't select. Doesn't add to cart. Sends one message. Gets one answer. Either the transaction happened, or the agent already has its next move. That's it. Patent pending mechanism.
For 55 years — from Hoare's precondition checking in 1969 to Stripe's payment intents in 2024 — every system has treated incomplete requests as ERRORS. Return a code. Let the caller figure it out. That's how OTA's 889 error codes work. That's how every 422 Unprocessable Entity works.
Nobody asked: what if incomplete isn't an error? What if it's a resolvable state?
Not the booking systems. Not the payment processors. Not the API standards bodies. Not even the agent-native protocols — Google's A2A, Anthropic's MCP, OpenAI's ACP, Stripe's ACP — all built in 2024–2025, all specifically for AI agents. Every single one: search, then transact, then handle errors.
The most experienced protocol designers in the world, building specifically for the use case that needs it most, didn't build it. They replicated the 60-year-old pattern.
We did build it. One message. Execute or instruct. No search. No browse. No cart. No error codes.
Because AI doesn't want UX. AI wants to get shit done.
Patent pending. Many of them, actually.
Dispatch 002 · Architecture · Sour Lemon Labs