Chat will always be just an interface. Agents are not, and the design work has moved to the contract underneath your product.
The first wave of AI in products was chat, a box where a person typed and read the reply, and teams staffed for it right down to arguing about where the stop button should sit.
The second wave takes the person out of the moment. An agent makes the same request with no box, no session, and nobody watching the response come back, and it is arriving in volume: DataDome’s AI Traffic Report Q2 2026 counted 17.7 billion AI agent requests in April, May, and June, up 45% from the quarter before.
I have designed for this user before. When MySpace opened its platform to outside developers in 2007, I designed its developer documentation website, and the developers using that product never saw our screens.
They saw endpoints, field names, and error messages, which made the documentation the interface.
The difference now is who is reading it.
Headless AI is the plain name for that difference. The UI becomes a client rather than the product. What you ship is the contract underneath it, so when someone else’s agent assembles the experience, you end up supplying parts of a product you did not design.
Here is how to take it back, starting in your own logs.
Find the Users You Cannot See
Pull 30 days of requests and sort them into browser sessions, your own clients, and everything else, and the third pile is the one no team owns.
What is in that pile matters more than its size. Cloudflare’s one-year report on the agentic Internet found that 52% of crawler requests were for AI training as of June 2026, up from 22% in spring 2025, while pure search crawling stayed small and kept shrinking, which means most of that traffic did not come to bring you a customer.
Then stop counting and start sequencing. When you group the calls by token and put them back in order, you get a journey map of search, fetch detail, check availability, create draft, and abandon, and those five calls tell you what the person behind the agent wanted and where your product stopped helping.
Volume tells you an agent came. Sequence tells you what it wanted.
The patterns are the ones a usability study would find: a retry loop is confusion, a call that always precedes an abandon is a dead end, and an undocumented path used more than the documented one is a design opinion expressed by software.
Sequencing needs something stable to group on, which shared service accounts, per-integration keys, or a missing trace ID all take away. If that describes you, it is the finding, and fixing it comes before anything else.
Map Every Door Into Your Product
Amazon’s API mandate is the analogy worth keeping. In the account that made it famous, Steve Yegge describes Jeff Bezos ordering every team to expose its data through service interfaces with no back doors, a rule that turned a retailer into a platform company.
It went like this:
His Big Mandate went something along these lines:
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
- It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care.
- All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
- Anyone who doesn’t do this will be fired.
- Thank you; have a nice day!
Headless AI does the same to your product, except Bezos doesn’t send the memo. And frankly, it’s just good software design which is good design, period.
Write the list yourself, covering the web app, mobile clients, your chat assistant, public and partner APIs, webhooks, bulk export, and the MCP server someone built at a hackathon.
For each door, note who comes through it, what they can do, what they see when it fails, and whose name is on it.
Write it knowing it is wrong, because some doors are invisible from where you sit:
- A partner reselling your API
- An endpoint built for one customer years ago
- An MCP server built against your public docs.
Its job is to turn unknown doors into known ones and show the remainder to whoever owns risk.
The uncomfortable finding is the doors that allow more than the interface ever did. Your screens enforced rules for years through a confirmation step, a disabled button, or a hidden field, and an agent calling the endpoint sees none of it. The constraint lived in the interface, which means it was never really a constraint.
The product manager who ordered the steps now decides which capabilities exist, and the designer who owned the flow now owns a contract that other people’s flows consume. Headless content management did this to content teams and platform engineering did it to infrastructure teams, and both times the work gained leverage while losing visibility.
Design the Service, Not the Screen
Tesler’s Law says complexity is conserved and the only question is who absorbs it. For 20 years your interface did the absorbing, and now the work lands in one of three places: the agent absorbs it and guesses, the customer absorbs it and gets a confident wrong answer, or your contract absorbs it deliberately. Only the third is a design decision.
Removing the screen did not remove the work. It moved it.
None of this should feel new. Understanding how a system gets used was always the job, and information architecture and content strategy have worked below the pixels for decades. Product work narrowed to screens because a mockup can go on a wall and be argued about by eight people while a schema cannot, so agents did not create that gap so much as make it expensive.
The craft this takes is not conversation design, which assumes a conversation, but service design. A service blueprint, in sarah gibbons’ NN/g definition, maps customer actions against frontstage and backstage actions and the line of visibility between them, exactly what a journey through steps you do not operate needs.
Andy Polaine, Lavrans Løvlie, and Ben Reason wrote the practical version in Service Design: From Insight to Implementation, and where you cannot see a step, draw what you know and mark what you infer.
The other half is API literacy, meaning scopes, rate limits, status codes, and what a 409 means to the thing receiving it. You do not need to write the endpoint, but you do need to argue about the contract while it is being set.
That literacy buys you a choice. A supplier exposes whatever gets asked for, while a partner decides what the product will not do through an API and defends it, the authority design once exercised by declining to build the screen.
Write the Contract Before You Draw the Screen
Content strategy solved a version of this already.
In Adapting Ourselves to Adaptive Content, Karen McGrane made the case for NPR’s Create Once, Publish Everywhere, structuring content once and letting each channel present it, and NPR’s structure outlived every device it was written for.
Your contract is that structure one layer down: field names, enum values, scopes, and the one-line tool description a model reads before deciding whether to call you. A developer confused by documentation could at least file a support ticket, but a model just guesses.
MCP handles the connection — we have to handle meaning.
An agent that reaches your endpoint still has to decide what counts as an active customer and whether revenue is booked or recognized, and unless you answer that in one place, every agent answers it differently.
That place is the semantic layer, where metrics and entities are defined once and served everywhere. Snowflake, Salesforce, and dbt Labs launched the Open Semantic Interchange with a dozen competitors in September 2025, and dbt published the first spec in January 2026. Competitors do not standardize vocabulary for fun.
Holding definitions steady is information architecture, work you can do without knowing your full surface. Then hand a model your schema and a real task and watch where it goes wrong; that is a usability study.
Design the Failure States Agents Will Actually Hit
Chat had a recovery path, a person reading a wrong answer and typing again, and headless removes it. Josh Clark and Veronika Kindred devote a chapter of Sentient Design to defensive design, and without a person in the loop the error string becomes the entire recovery experience. Return “invalid request” and the agent retries until it gives up; return the field that failed and the format expected, and it fixes the call.
The error string is the only recovery interface an agent will ever see.
Postel’s Law says be precise in what you send and tolerant in what you accept, which here means taking the date in three formats and returning one shape every time. Agents generate their input from language, so the variance arriving at your endpoint is wider than any form ever produced.
Tolerance has a limit, though. If you silently coerce an ambiguous input, the agent never learns it guessed, so accept generously and then say what you did: this date was read as the order date.
Three failures are worth designing first.
Handle partial success on batches so the agent knows which records landed, and make writes idempotent so a retry does not duplicate an invoice; Stripe saves the first response and returns it for every retry of the same key. Then require explicit confirmation for anything irreversible.
That last one is the question Christopher Noessel raised in 2017 in Designing Agentive Technology, about what software should do unattended and when it should check back, and it now lives in your API.
Instrument the Traffic You Do Not Control
Your analytics assume a browser, so page views, funnels, and session replay never fire when the customer is a model calling an endpoint.
That blind spot is growing fast: Fastly reported in June 2026 that AI traffic grew about 6.5 times faster than human traffic on its network between January and May.
Measure completion instead: tasks finished without human rescue, correct data, no duplicate writes. Then watch the sequences change over time, because a journey that took four calls and now takes nine got harder without anyone shipping a regression.
Define what a good agent session looks like before someone outside your company does.
Policy comes next, and the clock is already running. Cloudflare changed its defaults on September 15, 2026, blocking training and agent crawlers on ad-bearing pages for new domains unless owners opt in, so decide which agents get in before your vendors decide for you.
Own the Platform You Already Are
The screen is not going anywhere, and chat will keep its place wherever a person wants to think out loud with your product. What changed is that the screen stopped being the only place your product gets used, so a design practice that ends there covers a shrinking share of the experience.
That shift costs something. Time on error payloads is time not spent on the feature leadership can see, but I would still take that trade over learning the answer in an incident review.
Designing documentation for developers taught me that people who never see your screens are still your users, and that the words describing your product are part of the product. Understanding how a product actually gets used was always the work, and we narrowed it to screens because screens fit on the wall. Agents just stopped letting us get away with it.
Action Items
- Sort your traffic, then read it in order. Separate agent traffic by purpose and rebuild ten sessions as journeys, and if you cannot group the calls, fix that first.
- Map every door, including the ones you cannot see. List each way in along with who owns it and what it allows.
- Name who absorbs each rule your interface enforced. Decide whether the agent, the customer, or the contract carries it, because anything undecided falls to the customer.
- Settle your definitions. Put what an active customer is and how revenue is measured into one semantic layer.
- Apply Postel’s Law and fix three failures. Accept messy input, report every coercion, and handle partial success, idempotency, and confirmation.
- Name an owner for the contract. Someone has to hold it the way a designer holds a screen.
Headless AI will make every product a platform. Here’s what to consider when designing for this. was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.