Agentic Design

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, including at three in the morning when nobody’s at the keyboard, will be an agent, sent by whatever assistant the person talked to, increasingly the operating system itself. And almost everything we’ve built was designed for the old user. Apps are destinations, you go to them, they show you a finished answer, and you leave. An agent can’t really use a destination, since it doesn’t go anywhere, it just asks for what it needs.

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 doesn’t work this time, since there’s no surface to rebuild for and nobody can predict what agents will want, which is kind of the point of them.

So I’m thinking of it as 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 can’t know every use up front, so you make the parts honest and the composition cheap. That’s the same spot we’re in with agents.

I’d break it into 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 and confirmed against the actual device rather than a cached guess. The rule that matters most is that a primitive that can’t confirm something says so instead of estimating. When the reader is a model that’s going to build a plan on top of whatever you hand it, it needs to hear “I don’t know” when that’s the truth.

Loops. A loop is a fixed rule: sense, act, verify, record, the same way every time. It might run a small fixed model (camera framing, say), but it never improvises or generates anything, and someone in IT can read and audit it like any other config. “Set up my workspace when I dock” is a loop, and so is “check the room before the meeting and fix what’s broken.” This is the layer most people building for agents skip, and I think it’s the one that makes the rest safe.

Intelligence. Any agent comes through one door, whether it’s the assistant, the model vendor’s agent, the customer’s own, or yours. Intelligence runs loops and never touches primitives directly. 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.

That maps pretty cleanly to atoms, molecules, and organisms, but the mapping isn’t the interesting part. Parts in a design system for people only need to be consistent, and for agents they need to be honest too, which changes how you build everything above them.

Here’s a concrete one: “Get me ready for my 9am.”

In the system I’ve built, that’s one intent and four loops: run the readiness check and fix what fails, switch to the meeting setup, route audio to the headset, and 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, since 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 of this that you don’t 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, and agents read it to decide what to do, and more importantly when to stay quiet. What you see at your desk at 9am isn’t what you see in a conference room at 2, and nobody had to set that up.

The second is trust. Raw audio, video, and identity stay where they were captured, and only records leave. An agent gets “at the office,” never a coordinate. Permission is checked before a verb runs and a receipt is written after, so the OS logs what an agent asked for and the receipt shows what actually happened. None of it is a separate feature, the layers enforce it on their own.

For a designer, a lot of the work shifts from screens to contracts: what a primitive promises, what a loop guarantees, who gets through the door and what they’re allowed to do once they’re in. The screen becomes one of several surfaces, and on some fleets there’s no screen at all, just a background service and the door.

The timing’s hard to call, but I’m pretty confident about the shape: parts with contracts, assembled later into things nobody drew in advance. Design systems already work that way, this is just the first time the main user isn’t a person.