Designing for the Agentic Era

I built this website by delegating it. I described what I wanted, a coding agent wrote it, and I reviewed every change before it shipped. Somewhere along the way I noticed I had stopped designing screens. I was designing how much I trusted the thing doing the work: what it showed me before it acted, how I would know when it got something wrong, and how quickly I could take it back.

For thirty years software ran on a simple deal: you click, it responds. Our whole discipline grew up designing that moment, the button, the field, the flow. Agents break the deal. They don’t wait for the click; they act on what you meant by it. You stop operating software and start delegating to it, and the question changes from “how does this screen work?” to “how much do I trust this, and how do I stay in charge of what it does in my name?”

That isn’t a new component library. Three things change.

Describe the outcome, not the steps

Classic interfaces rewarded precision: the right control doing exactly one thing. Agents reward a good brief. You describe the outcome and the system works out the steps. So the new craft is helping people say what they want, well: set the scope, draw the boundaries and correct course, without dropping them back into the manual controls the agent was meant to replace. The best agentic interface feels less like a cockpit and more like briefing a capable colleague.

The rule: make the brief easy to write and easy to fix.

Showing your work beats looking good

Familiar software earns trust by behaving the same way every time. An agent can’t promise that, so it has to earn trust another way: by showing its work. What did it understand? What is it about to do? What did it actually do, and how do I undo it? A beautiful screen that hides the agent’s reasoning is worse than a plain one that shows it.

When the agent building this site proposed a change across many files, the most useful thing on my screen wasn’t the design. It was the list of files and a one-line reason for each. I could say yes, narrow it or stop it. Undo and a clear record of what happened aren’t edge cases any more. They are the product.

The rule: before it acts, show the plan. After it acts, show the receipt.

Design the loop

A screen is a stop. An agent runs in a loop: plan, act, observe, correct. Design one screen at a time and you miss where the experience actually lives, in the hand-offs between a person and a system over minutes, hours or days. Who has the initiative right now? When does the agent ask, and when does it assume? How does it fail, because it will?

The rule: spend as long on what happens when it’s wrong as on what happens when it’s right.

Four questions to ask of any agent you design

1. Can I see its plan before it acts, while disagreeing is still cheap?
2. Do I know exactly what it’s allowed to touch?
3. When it gets something wrong, will I hear it from the agent or from the damage?
4. How many steps is it from “that’s not what I meant” back to where I started?

If any answer is “not really”, that’s where the design work is.

What it means for designers

This doesn’t only change the interface. It changes the people who make it. For years the worry was that AI would carve design into thinner and thinner slices until nothing was left. I co-authored The Great Recomposition because I think the opposite is happening: the slices are recombining. When a designer can describe an outcome and have a system build it, the walls between design, engineering and product stop earning their keep.

The designers who do well now are builders, problem-framers and generalists. Builders, because the distance from idea to working thing has collapsed, so you can ship it instead of writing a spec for someone else. Problem-framers, because the scarce skill is no longer pushing pixels but describing a problem precisely enough that a capable system can run with it: the outcome, the limits, the guardrails and what done looks like. Generalists, because the value sits between disciplines, and the people who can move across the canvas, the codebase and the company can build a whole experience instead of handing off a piece of one. That’s the path I’ve been on, from craftsperson to the person who frames the problem, and it’s the one I’d bet on.

Why better models won’t save us

It’s tempting to treat this as a model problem that scale will solve. It won’t. A stronger model raises what an agent can do and what it costs when it gets something wrong. Power without visibility and control just makes confident software that people are afraid to use. The teams that win won’t have slightly better benchmarks. They’ll have made powerful systems feel trustworthy and easy to steer. That’s a design problem, and it’s the best one our field has had in a generation.

I get to work on it from both sides: leading design for agentic data tools at Google, and building AI companies where the whole company is the experiment. The principle underneath is old-fashioned. Technology earns its place when it makes people more capable without taking away their control. Agents raise the ceiling on capability. Our job is to make sure control comes with it.

A working note. I revise it as the work teaches me more. Reactions welcome: i.wooten@gmail.com.