In the previous issue, I argued that AI experience design is service design, using the front stage (human-AI collaboration), back stage (agentic experience), and the line of visibility concepts. In this issue, I want to build on that and articulate the backstage.
When we interact with Claude Code, we are conversing with an orchestrator agent through a chat interface. When you open the hood and look underneath, you will see that the orchestrator is managing an array of coworkers who execute specific tasks. Typically, the backstage is designed by technical partners.
I mapped out a backstage like this recently for a project I was part of — a hierarchical agent team. I drew the diagram to understand how agents work well enough to make a case for changing the system prompts. Once I could see where each agent’s instructions were landing, I realized those prompts were doing more to shape the experience than most of the interface decisions I’d been weighing.
We used to shape interaction patterns and UI. That work is still important, but now our work is expanding into a new territory. As designers, we are tapping into defining how a model behaves, deciding what each agent is for and what it’s told to prioritize — in a way the medium has changed, and so has the material.
Once the backstage spread across more than one agent, someone decided how they’d be arranged. Who talks to whom? Who reports upward? Whether anyone is allowed to disagree. That decision is usually made in the first weeks of a project, by whoever built the prototype or by whichever framework was picked. It is rarely decided by a designer. Those decisions, however, show up in the experience.
Service designers have a name for the place where this becomes visible: the line of visibility. Above it is what the person sees. Below is the work that makes it possible. In agentic systems, the line runs between the orchestrator you’re talking to and everything it coordinates. What crosses that line is a design decision in which the agent exposes its internal reasoning in the UI.
When we look more closely at the backstage, we see different configurations of agents. Let's look at the three main ways to organize these teams.
Hierarchical Teams
Hierarchical agentic teams mimic a traditional org chart, there’s an orchestrator that interfaces with the people and then distributes the tasks across the coworker agents. Salesforce shipped this as Agentforce Multi-Agent Orchestration, which has been generally available since late 2025. A primary agent is the only thing the customer talks to; specialist agents work behind it and hand their answers back up. Salesforce’s own framing of the benefit is that the customer never switches bots, never loses context, never repeats themselves. One write-up from them puts it plainly: the handoff is invisible, and the person sees a single, continuous chat window regardless of how many agents were involved.
For example, let’s say you are chatting with your AI and ask it two questions — why is my corporate card bill so high, and how do I dispute a charge I didn’t make? The primary agent takes those questions, splits them, routes billing to one specialist and disputes to another, and stitches both answers into a single reply.
What you get then is a single voice, a clean response, and one place to look. What you don’t get is any sense that the two specialists disagreed. If they returned incompatible readings of the same charge, that conflict was resolved above them and below you.
Hierarchical teams work the majority of the time, since the orchestrator agent handles the division of labor and context sharing. There are still some drawbacks to this model, as it can sometimes take longer for the orchestrator to translate and resolve competing results.
Roundtable — Peer-based Teams
This is the model where everyone at the table is talking to everyone else. Microsoft’s AutoGen established this pattern: agents that work on a problem by conversing rather than by being dispatched.
Imagine you drop a piece of frustrating user feedback into your AI chat window, something like “customers are abandoning the checkout page.” Three agents enter a shared conversation. One reads it as a visual hierarchy issue and suggests moving the payment button. Another argues the legal microcopy is creating distrust. A third pushes back on both, pointing out a hidden friction point in the mandatory account creation step. They pass context around without anyone dictating turns and converge on a redesigned user flow.
From the front stage, this is a waiting period till the agents make a decision and report back. Something is clearly happening, and none of it is legible. If you surface the deliberation and you’ve turned the backstage into a spectacle nobody asked to watch. If you hide it and the person stares at a spinner while their tokens burn. Selectively exposing the agent’s workflow and thinking is one way to increase visibility and avoid the spinner effect.
This model also has some drawbacks. When there is no consensus between agents, that can cause boot loops and stalling. This is perhaps why this arrangement is still a minority in the industry.
Dynamic Duos
In this configuration, two agents form a team—a dynamic duo. This is the minimum unit of a team, but it is incredibly powerful. Simply pairing two agents together outperforms a single agent working alone.
The most common version of this is maker-critic duo. One agent generates the work, and the other reviews it against a set of constraints—pointing out flaws, demanding revisions, and sending it back. The loop runs internally until the work passes the test. Only the passing version crosses the line of visibility to the user.
From a design perspective, this changes the material we are working with. Pairs hide the messy, failed attempts. The person using the product only sees the polished final draft, not the multiple rejections that happened in the background. It’s exactly like a private studio crit session, except the feedback happens instantly and leaves no trace.
The real design challenge here is more than an interface layout; it’s about the pair's behavior. What is the second agent allowed to reject? How harsh is the critique? And most importantly, does the system capture that feedback to improve the overall workflow for the next run, or does the critique simply evaporate when the session ends?
What designers actually touch
You might be asking how this all relates to design and designers. It’s true that most of us won’t pick the agentic team type. It is usually chosen upstream, inherited, or already shipped by the time a designer is brought into the room. That is completely fine, because the structural part might not be where your true leverage lies. The real leverage is found in three critical layers of the backstage:
The agent’s instructions (The System Prompt Pattern): System prompts are the foundation of the AI experience, and they can be shaped today without asking anyone’s permission. This pattern dictates the hidden behaviors: whether the internal critic is harsh or permissive. Whether a worker agent escalates uncertainty instead of blindly guessing. Whether the orchestrator is instructed to openly report that two sub-agents disagreed, rather than quietly picking a winner behind closed doors and presenting it as absolute truth. It can also be about the agent's tone and voice.
The interface’s admission (The Stream of Thought Pattern): Given that a disagreement occurs backstage, does the person using the product actually see it? The Stream of Thought pattern surfaces this internal deliberation—show the rejected drafts, a trail of the revisions, or a transparent log of the agents’ data, rather than hiding it behind an opaque loading spinner. But this disclosure depends entirely on the first layer. You can only surface what the backstage preserved. If the system prompt didn’t tell the orchestrator to keep the disagreement in its memory, that tension is permanently gone by the time you sit down to design the screen.
The team’s staffing (The Agent Addition Pattern): This variable is available early in the process, when determining how many agents there are, what each is for, and whether to introduce a dedicated persona (like a “Devil’s Advocate” or “Tone Reviewer”) into the mix. Adding an agent is a design choice, closer to organizational staffing than to traditional interface work. When you decide to add an agent to the system, you are essentially addressing a new user need and use case. When you define the tasks and boundaries of that agent, you are also establishing a new team dynamic.
If you are working on an AI product, the version of this you can act on tomorrow morning could be to find your tech lead and your data lead and ask to see the system prompts. Sit down and work on them together. You don’t need to have chosen the agentic team type to do that. The prompts are already written, ready to shape what people experience. System prompts are the least-claimed design material available—and the people currently writing them mostly aren’t designers. It is time we start treating system prompts not as engineering configurations, but as the raw material shaping the human experience.
In the next issue of the AIX series, I will cover the concept of harness from a design perspective and explore the context design space.
And that’s a wrap for this issue. Until next time, take good care of yourself and your loved ones.
References
Frameworks and architecture
Anthropic. Building Effective AI Agents: Architecture Patterns and Implementation Frameworks. Claude Developer Platform. https://www.claude.com/platform/api
Microsoft. “Introducing Microsoft Agent Framework.” DevBlogs, October 1, 2025. https://devblogs.microsoft.com/agent-framework/ — the convergence of AutoGen and Semantic Kernel. Version 1.0 shipped April 3, 2026.
LangChain. Benchmark comparing supervisor and swarm architectures. https://blog.langchain.com/
“AI Design Is Service Design.” Design Meets AI. https://designmeetsai.substack.com/p/ai-design-is-service-design
Salesforce. Agentforce Multi-Agent Orchestration, generally available June 2026. https://www.salesforce.com/agentforce/
Augment Code. Cosmos, public preview June 2026. https://www.augmentcode.com/