Agentic Design
Point of view Design practice Sep 2026
The main user of the software we build is about to stop being a person.
Not entirely. People will still open things. But the user that shows up most often, asks for the most, and runs at three in the morning when nobody is at the keyboard will be an agent, sent by whatever assistant the person talked to, increasingly the operating system itself. And almost everything we have built was designed for the old user. Apps are destinations. You go to them, they show you a finished answer, you leave. An agent cannot use a destination. It does not visit. It asks.
Every platform shift so far, we answered by rebuilding the apps. Desktop to web, web to mobile, each time a new surface and a new pile of finished features. That does not work this time. There is no surface to rebuild for, and nobody can predict what agents will want. That is the whole point of them.
This is not a product problem. It is a design system problem.
Brad Frost’s atomic design gave us a way to stop drawing every screen from scratch: atoms, molecules, organisms, parts with rules for how they combine, assembled later into things nobody drew in advance. That last part is what matters here. A design system is a bet that you cannot know every use up front, so you make the parts honest and the composition cheap. That is exactly the situation with agents.
There are three layers.
Primitives. A primitive does one thing and tells the truth about it. Docked or not. In a call or not. Battery, mute, whether the camera is framing anyone. Small, boring facts, each behind a permission check, each confirmed against the actual thing rather than a cached guess. One rule matters more than the rest: a primitive that cannot confirm something says so. It does not estimate. When the reader is a model that will build a plan on top of whatever you hand it, “I don’t know” is a feature.
Loops. A loop is a rule, not a guess. Sense, act, verify, record, the same way every time. A loop might run a small fixed model, camera framing say, but it never improvises and it never generates. Someone in IT can read it, version it, and audit it. “Set up my workspace when I dock” is a loop. “Check the room before the meeting and fix what’s broken” is a loop. This is the layer most people building for agents skip, and it is the one that makes the rest safe.
Intelligence. Any agent, one door. The assistant, the model vendor’s agent, the customer’s own, yours. Intelligence runs loops. It never touches primitives directly. Adaptive on top, predictable underneath. And whatever it produces gets written back down as a primitive, so today’s meeting summary is something tomorrow’s loop can act on without asking a model again.
Atoms, molecules, organisms. But the mapping is not the interesting part. In a design system for people, the parts only need to be consistent. In a design system for agents, the parts need to be honest. That is the twist, and it changes how you build everything above it.
Make it concrete. “Get me ready for my 9am.”
In the system I have built, that is one intent and four loops. Run the readiness check and fix what fails. Switch to the meeting setup. Route audio to the headset. Surface the prep. It works because every loop reports what actually happened, so the agent knows step two succeeded before it tries step three, and every step leaves a receipt.
It also costs less, and the reason is structural. The loops run outside the model. The agent spends tokens on one intent and four results, not on every sense, act, and verify inside them. When the OS does the planning, and every OS vendor is heading there, the loops are the verbs it plans with.
Two things fall out that you never have to design on purpose.
The first is that the product becomes contextual instead of configured. The primitives are the situation: docked or mobile, in a call or free, five minutes before a meeting or deep inside one. Loops read the situation to pick how to behave. Agents read it to decide what to do, and more importantly when to stay quiet. What you see at your desk at 9am is not what you see in a conference room at 2. Nobody set that up. The situation decided.
The second is trust. Raw audio, video, and identity stay where they were captured. Records leave, streams don’t. An agent learns “at the office,” never a coordinate. Permission is checked before a verb runs and a receipt is written after. The OS will log what an agent asked for. The receipt proves what actually happened. None of that is a feature you bolt on. The layers enforce it, which is the only kind of trust that holds.
What changes for a designer is what you are designing. Fewer screens, more contracts. What a primitive promises. What a loop guarantees. Who gets through the door, and what they are allowed to do once they are in. The screen stops being the product and becomes one of several surfaces, and on some fleets there is no screen at all, just a background service and the door.
The timing will vary. The shape will not. Parts with contracts, assembled later into things nobody drew in advance. We have done this before. We have just never done it for a user who asks instead of visits.
Tags
- Applied AI Product Design Designing for models that are good, wrong, or weird. Often on the same screen. I care more about trustworthy and unobtrusive than flashy.
- AI Agents Agents that act on the world need guardrails before they need cleverness.
- Design Systems A good one removes a hundred small arguments a month.
- Product Strategy Figuring out what should exist and why, not just what to ship next quarter.
- Information Architecture The shape of the thing before the pixels. Get this wrong and nothing else lands.
- Enterprise Software Designing for people who didn't choose the tool and can't opt out.