SaaS design in 2026 can no longer assume a single human clicking through a screen. Products now have at least two types of users — human users + agent users — and the core UX is shifting away from "what happened (state)" toward "what is happening right now (presence)." This piece walks through what designers and product teams need to build in order to treat agents as trustworthy collaborators.
1. Why "Drawing Screens" Is No Longer the Job
The piece opens by observing that many designers are still polishing interfaces for one human user at a time — and then argues that this stopped being the real job about six months ago.
The turning point is the emergence of a second user in SaaS products. That second user is not human — it's an agent. Agents actually log in, click buttons, call APIs, and often arrive before the human to do prep work, waiting only for approval. That's why the author states that "most of the features shipping next year will be used by something that isn't a person."
"Most designers are still 'painting' screens for one user at a time. That stopped being the job roughly six months ago." "If you're designing SaaS in 2026 and haven't added a 'second user' to your personas, you're designing the wrong product. That second user is an agent."
The piece also directly pushes back on the popular claim that "SaaS is dead and agents will replace it." The conclusion: SaaS isn't dying. In fact, the user base is growing — because each human user now comes with a small team of agents. Those agents might be owned by the user, by the company, or even by a vendor the user has never heard of.
"The popular take is 'SaaS is dead,' and it's wrong. SaaS isn't going away. The user base is about to 10x."
2. Five Design Requirements for Agent Users
Moving into what needs to change, the author asks you to first "accept the obvious": most features going forward will be triggered by agents, not humans.
Agents don't care about your hero image or your typography. Instead they call tools, read schemas, and check state.
"Agents don't see your hero image. They don't care about your typography. Agents call tools, read schemas, and check state."
From there, the piece lays out five things the "second user (agent)" needs — a critical checklist:
- Discoverability: Can an agent find every action in your product without a screenshot?
- Reliability: Does the same input reliably produce the same output at 3 a.m.?
- Idempotency: Does retrying break anything? (e.g., no duplicate data from re-runs)
- Auth, not CAPTCHAs: Scoped tokens, agent-specific permissions, audit trails
- Receipts: Does every action return a structured response the agent can interpret?
"If you can't answer these five, your product isn't ready for agent users."
An important nuance: designers don't have to build all of this themselves. Just as designers once worked with engineers to define responsive grids, they now need to co-design this agent layer with engineers.
3. It's Not an API Problem — You Need an Agent-Facing Product Surface
The author is firm: don't reduce this to API docs or an engineering ticket. What agents encounter is still a "product surface," and that surface is a design problem.
Questions that now need answers:
- What does an agent see when it queries the list of available features?
- What hints does help text give an agent?
- What does an error message tell an agent when it gets stuck?
The argument is that agent-facing surfaces deserve to be treated like UI — with the same care given to human UI.
"The product surface for agents is a real design problem." "Treat that surface like UI. It deserves the same level of care as the UI you build for humans."
Going forward, winning companies will run two design systems:
- A human design system
- An agent design system
The crossover point between the two is where the new craft lives.
4. The Biggest UX Shift: From State to Presence — and Trust 🧭
The piece declares that "the biggest change in new SaaS UX is presence."
Old SaaS was state-centered — questions like "where am I, what did I do, what happens next."
New SaaS is presence-centered — "what is the agent doing right now, what decision did it just make, why did it decide that, can I stop it?"
"Old SaaS was about state. New SaaS is about presence." "What is the agent doing right now? What did it just decide? Why did it decide that? Can I stop it?"
Notably, the author is emphatic: if humans can't watch an agent's actions in real time, you've built a black box. People don't trust black boxes — they trust glass boxes. And a stop button on the front builds even more trust.
"People don't trust black boxes. They trust glass boxes. And they trust them even more when there's a stop button on the front."
Five Patterns That Already Work
The piece also catalogs concrete patterns that generate trust:
- Activity stream: Every agent step shown in plain text in real time, with timestamps, tools called, and results
- Plan & progress: A checklist of the plan shown before execution, each step flipping from pending to done, with the ability to pause between steps
- Confidence signals: Confidence level shown per step; if low, the agent automatically requests human approval
- Receipts & undo: Every action is logged, and anything reversible has an undo option right there
- Stop: One button — always visible, always functional, never buried in settings
"These patterns matter not for aesthetics, but for trust. When people can see what an agent is doing, they delegate more."
A pointed diagnostic question follows: if an agent feature exists but the only place humans can see what it's doing is "the chat log," there's still work to do.
"Where can a human see what the agent is doing? If the answer is 'the chat log,' you have work to do."
5. The Limits of Chat UI and the Choreography of Multi-Agent Systems 🎛️
The piece then warns against letting the chat box calcify as the default pattern. Chat is fundamentally a 1:1 pattern — one person, one model, one thread — but real work doesn't run that way.
Real work runs many agents simultaneously: a research agent gathers material, a writing agent drafts, a fact-checker reviews, an editor refines, a publisher schedules. They run in parallel, pass context between each other, and sometimes disagree.
"Chat is a 1:1 pattern. But real work runs many agents at the same time."
The author proposes patterns that "didn't exist a year ago":
- Multi-agent dashboard: Like an air traffic control tower — one screen showing every agent's task, elapsed time, and status, with the ability to deploy new agents
- Hand-off legibility: When one agent passes work to another, humans see a diff — what context was compressed, dropped, or added
- Specialization tags: Agents labeled by capability; users choose, or the system routes — closer to an org chart than a chat list
- Group review surfaces: A document-style screen (think Notion page + comment column) where outputs from multiple agents are compared and a human picks one, rather than a chat thread
- Quiet by default: Only surface moments that need human intervention; everything else goes to a log
All of this is summarized in one line:
"Work is choreography. Most products are still designing for a soloist."
6. Human UI Isn't Going Away — Synchronizing Two Layers 👀
One thing often missed in "agent UX" discussions, the piece notes, is that the human interface is not disappearing. It's becoming more visual, not less.
The reason is simple: the more agents do, the smaller, denser, and more decision-focused the human-facing screen becomes.
The interface splits into two layers:
- Machine-readable layer: Schemas, APIs, structured tool definitions, action receipts (for agents)
- Human-readable layer: Dashboards, decision moments, presence streams, stop buttons (for oversight and approval)
The key is that both layers must sync in milliseconds. When an agent acts, it reflects immediately on the human screen. When a human intervenes, the machine layer accepts the override and can explain it back to the agent.
"The seam between these two layers is now where the craft of product design lives." "Get it right and the product feels alive. Get it wrong and it feels haunted."
A small example is offered: when an agent edits a document, how do you show the changes?
- As a diff, like a code review?
- As comments, like Google Docs?
- As version history, like Figma?
That single choice changes the entire feel of the product — and it's not a technical decision, it's a design decision.
7. For Junior Designers: This Is Your Opportunity 🚀
The author tells designers early in their careers this shift is "some of the best news you'll hear in a while." Because no one has ten years of experience in the agent layer yet.
"Even the most 'senior' agent designer on earth started six months ago."
Five action steps are proposed:
- Spend a week using one agent product: Try Cursor, Claude Code, Cora, v0, Lovable — observe friction, unclear receipts, missing stop buttons
- Redesign one real screen you actually used: Not a concept — a real screen, before-and-after, with your reasoning
- Build something small with an agent: Even a personal tool — feel firsthand where things break when you're both designing and using it
- Document patterns: Record presence patterns, hand-off patterns, trust signals — this field needs a vocabulary
- Publish quickly under your own name: Don't let it sit in your portfolio — post it the day you finish it
And the message closes with: the people who ship artifacts weekly become senior the fastest.
8. Three Things Product Leaders Should Add to the Roadmap This Quarter
For people running teams, the piece gets concrete about what to do in the next 90 days:
- Add an "agent persona" to the design system: Document what the agent reads, what it can do, and what it returns
- Audit activity and async surfaces: Every background operation must be visible to users, and must have stop + undo
- Build one multi-agent flow: Pick a high-step workflow, design it so two or three agents run in parallel, and figure out what the human screen needs to look like
"Do these three things in 90 days and your product will be in the top 5% for agent UX."
9. Closing: From Watching One Screen to Conducting a Team
The piece closes with the observation that "the era of one human staring at one screen is closing, and the era of one human watching a small team work is opening." And that 2026 will be looked back on as an early-mover moment — the way early Figma designers felt in 2012.
"The era of one human staring at one screen is ending. The era of one human watching a small team work is beginning." "Get positioned. Start now."
The key concepts to carry forward: agent personas, trust (glass box + stop button), presence UI, multi-agent orchestration, and tight synchronization between the machine and human layers.
