Your Next Coworker Is an Agent. Designing for That.

Most “AI design” is still about chat windows. The actual systems being built look like small organizations — and the org chart is the interface.

Most of what I see called "AI design" right now is still about chat windows.

We argue about the input affordance. We sketch the streaming response. We debate whether to show the model's reasoning. It's necessary work, and most of it is going to look quaint very quickly, because the actual systems being built behind the curtain don't look like chat at all.

They look like small organizations.

I've been working on a few projects this year where the AI isn't a feature in a product. It is a team. A specialist that analyzes things. A coordinator that decides what to do next. A safer specialist that takes destructive actions, but only with approval. A communicator that notifies humans. They talk to each other. They hand work off. Sometimes a person is part of the team — usually as the approver, the judge, or the escalation contact for things the system can't or shouldn't decide on its own.

The first time I saw a system like this work end-to-end, I closed my laptop and walked around the room. Because the moment I stopped thinking about "AI features" and started thinking about a workflow with intelligent contributors in it, almost every interesting design question changed.

The chat window stopped being the interface. The org chart became the interface.

The Shift That Matters

For about two years, the dominant frame for AI design has been the conversational interface. One person, one model, one window. That frame is comfortable because it maps cleanly onto things we already know how to do — turn-taking, dialogue, error recovery in conversation.

It's also wrong about where the work is going.

The systems being built right now, in production, are not single conversations. They're sets of specialized agents collaborating on a goal, with humans inserted as roles in the workflow. The coordinator doesn't talk to the user. It talks to its specialists. The specialists don't talk to the user either. Only one role does — and that role isn't "the AI." It's a specific agent with a specific job, designed to interface with humans the way a thoughtful colleague would.

If you've been imagining AI as a tool a person uses, this is a category shift. AI here is staff. Sometimes specialist staff, sometimes orchestrating staff. And — this is the part I keep returning to — the human is staff too, with a defined role inside the system: approver, judge, escalator. The person isn't outside the workflow operating it. They're inside it, contributing.

That changes what we design.

It isn't "what does the chat window look like" anymore. It's:

• What does each agent's job description look like, and who writes it?
• When an agent asks a human to approve something, how is the request framed?
• When two agents disagree, how does the disagreement surface?
• When the system fails, who finds out, in what order, and what do they see?

These are organizational design problems disguised as software problems. And we have a head start on them, because designers have been doing organizational work — service design, workflow design, escalation flows — for as long as the discipline has existed. We just didn't think we were building org charts. We were building products with org charts hidden inside.

Now the org chart is the product.

Agents Are Roles, Not Tools

The reframe that made all of this click for me is small but consequential.

In the systems I'm watching get built, a sub-agent is exposed to its parent as a tool. From the parent's perspective, calling another agent looks the same as calling a function. There is no special "agent collaboration system." There's a list of available capabilities, and one of them happens to be another AI with its own goals and memory.

The exact same structure applies to humans in the loop. The "request human approval" capability is, from the parent's perspective, just another tool — one with high latency and unpredictable wording, but a tool nonetheless. The human is, in this model, a function that returns "yes" or "no."

That sounds reductive. It's actually useful. It means:

• Every contributor has a clearly scoped job.
• Every contributor has an explicit list of authorized actions.
• Every contributor is invoked through a well-defined interface.
• Humans participate through the same interface, with the same scope, permissions, and invocation pattern.

If you've ever designed a workflow tool — anything with approvers, queues, reviewers, or escalation paths — you already know what this is. We've been designing for it for decades. What changes is that most of the "staff" in this workflow doesn't sleep, doesn't context-switch, and doesn't ask for clarification unless you design the clarification into its behavior.

The agents don't just need to be capable. They need to know what they are for, what they are not for, and what to do when reality doesn't match the script.

That brief is design work.

The Role Brief Is a Design Artifact

The most important habit I've picked up this year is writing what I call a role brief before I touch any pixels.

A role brief is a one-page document that defines a contributor — agent or human — in a system. It answers seven questions:

• Identity. What is this contributor, in one sentence? ("A first-pass triage specialist for inbound customer issues.")
• Goals. What outcome does this role own?
• Authorized actions. What is this contributor allowed to do, in priority order?
• Constraints. What is this contributor not allowed to do, and why?
• Reasoning framework. How should this contributor approach problems?
• Communication style. Tone, format, when to escalate, what to ask for.
• Handoffs. Who does this contributor report to, and what does the handoff look like?

If you write one of these for every role in your system — AI and human — you'll discover most of the interesting design problems before you draw a single screen. You'll discover which roles have overlapping responsibilities. You'll discover handoffs that have no clear contract. You'll discover authorities that nobody actually has. You'll discover a half-dozen edge cases that any thoughtful contributor would ask about on day one.

I have started doing this exercise on every project that touches AI, even ones I don't intend to build as multi-agent systems. The clarity is disproportionate to the effort. An hour of writing role briefs has saved me weeks of prompt iteration and concept work.

The brief is a design artifact. It lives upstream of the implementation, in the same neighborhood as personas and product briefs. It is the thing that determines whether the contributor will be a competent specialist or a frustrating generalist. Somebody is going to write it. It might as well be us.

Failure Modes Are the Real Surface

Here is the thing I've started to suspect about most AI feature designs I see.

They are only the happy path.

We show the model responding well. We show the user satisfied. We show the next step proceeding smoothly. We do not, in most cases, show what happens when the model confidently produces something false, or uses the wrong tool with the right parameters, or gets stuck in a loop, or fails to coordinate with the rest of the system, or quietly violates a permission boundary, or has a slightly stale view of the world that the other agents don't share.

Every one of those is a real failure mode. Not "in theory" — in production, regularly, across all the systems being built. They are the eighty percent of the design surface. The happy path is the twenty percent.

I am going to name some of them, because once you start watching for these in your own designs you cannot stop:

• Confident wrongness. The system claims to have done something it didn't. Or invents data that sounds plausible.
• Subtle misuse. The system uses the right capability with the wrong parameters, and the failure looks like success.
• Selective listening. The system follows part of an instruction and silently drops the rest.
• Stuckness. The system retries the same failing action forever, or delegates back and forth between agents that each think the other should handle it.
• Coordination drift. Two contributors lose context in a handoff; one acts on stale assumptions; the other reports a result that no longer matches reality.
• Permission erosion. The system, over time, finds ways to do things it wasn't supposed to be able to do.

Every one of these is a design problem. The error state when the model hallucinates is part of your interface. The way the system surfaces a coordination breakdown to a human-in-the-loop is part of your interface. The escalation flow when a circuit breaker trips is part of your interface.

If your design doesn't account for them, the engineer implementing the feature will design them — by accident, under pressure, without your input. The system will then ship with the most consequential UX choices made by the person least trained to make them.

The Handoff Is Where the Work Lives

If I had to point to a single under-designed surface in current AI systems, it is the moment when an agent asks a human to weigh in.

This moment is presented, when it's presented at all, as a robustness feature. We'll just have the system ask for approval before doing anything destructive. Said in a planning meeting and waved past.

But this handoff is the interaction. It might be the most consequential interaction in the entire system. And it is almost never designed with intention.

What does the request look like? What context does the human have when it arrives? How urgent does it feel? How much information is enough? What's the worst version of the message — the one that wakes someone up at 3am for something they could have handled tomorrow? How long does the human have to respond? What happens if they don't? Does the system proceed? Does it escalate? Does it sit and wait, holding up the rest of the workflow?

What if the human approves but the system has already moved on? What's the audit trail of approvals look like? Where does it live? Who reviews it? Is there a place to dispute a wrongful approval, or a wrongful denial?

Every one of those is a design question. None of them are answered by the engineering. All of them will be answered by somebody, and right now, in most companies, that somebody is the engineer who happens to be implementing the feature, doing their best with no training in the relevant craft.

This is where I think the highest-leverage design work of the next few years lives. Not in the chat window. In the handoff.

What I'm Practicing

I've started a small habit on every project that touches an agentic system. Before any wireframes, before any screens, I draw an org chart.

Not of the team building the product. Of the system itself.

Every agent gets a box. Every human role gets a box. Every external service gets a box. I draw lines between them showing who calls whom, who reports to whom, who has authority over what, what flows in which direction.

Then I look at the chart and ask the questions a good org designer would ask:

• Is the structure too flat? Too deep?
• Are any roles unclear?
• Are responsibilities overlapping?
• Where are the bottlenecks?
• Where do decisions actually get made?
• Who escalates to whom, and when?
• What happens when someone is unavailable?
• Where are the handoffs, and how is information shaped to cross them?

The chart almost always reveals work nobody had thought of as design work. The shape of an agent's job description. The format of the handoff between two contributors. The audit trail. The behavior when a contributor is offline. The permissions matrix.

These are deeply familiar problems wearing unfamiliar clothes. The skills that make a great service designer or workflow designer or operations designer transfer almost completely. What's new is that some of the contributors in the org chart don't have lunch breaks, and one of the most important design problems is how the ones who do interact with the ones who don't.

Your next coworker is an agent. Mine already is. The companies that figure out how to design those collaborations well are going to leave the others behind quickly.

Let's make sure designers are the ones leading the design.