Agent Experiences

One front door

Entry points, orchestration, and why routing is the system’s job rather than the user’s.

The position

A person should meet one agent, with one memory, however many places they reach it from. That agent takes any request and works out for itself whether to answer, call a specialist, or chain several together. The failure this avoids is not having several entry points — those help people find the thing. It is having several agents: a widget per page, an assistant per feature, each with its own history, which pushes a routing decision onto the person that they have no way to make correctly and fragments the context that would have made the next answer good.

This runs against how most teams build. Agent features tend to arrive per-team: the support group ships a support bot, the commerce group ships a shopping assistant, the docs group ships a docs search. Each is defensible. Together they produce a product where the user has to know your reporting structure to get help.

The user does not know which of your agents owns their problem. Frequently the problem spans two of them, which is exactly the case no single widget handles.

What goes wrong with many entry points

The user is made to route

Choosing the right agent requires knowing what each one can do, which is knowledge the product has and the person does not. Get it wrong and you are told to go somewhere else — the digital equivalent of being transferred between departments. Every wrong guess is a failure the system caused and the user pays for.

Context does not follow

Five surfaces means five conversation histories. The thing you explained in the billing widget is unavailable to the support widget, so you explain it again. Worse, each agent holds a partial picture and answers confidently from it.

Capability becomes unpredictable

When agents differ by surface, the user cannot form a stable model of what “the AI here” can do. It answered that question on the pricing page but not on the account page. The inconsistency reads as unreliability, and people stop trying.

There is nowhere to check what happened

Agents that act need a place where a person can see what was done on their behalf. Scatter the agents and you scatter that record, or lose it. For anything with consequences, this alone is disqualifying.

The market ran this experiment already

Through 2025 several companies shipped AI capability as its own destination. Most of it has since been folded back into a single surface people already used.

OpenAI launched the Atlas browser in October 2025 and shut it down in August 2026. The clearer signal came a few months earlier: in March 2026 it announced it would merge ChatGPT, Codex and the browser into one desktop application. Fidji Simo, its CEO of Applications, told staff the company had to stop chasing “side quests”, and that product fragmentation had been slowing them down and making it harder to hit the quality bar they wanted. What shipped is a single app where you converse, delegate to Codex and ChatGPT Work, and browse — one surface, specialists behind it.

Google closed Project Mariner in May 2026, folding the capability into Gemini Agent and Chrome without the standalone branding.

Two others moved differently, and it is worth not flattening them into the same story. Microsoft retired Edge’s separate Copilot Mode in May 2026 but pushed the features into ordinary Edge rather than into a hub — the opposite geometry, dissolving the AI surface into the ambient default. Anthropic made a third argument again: when its Chrome side panel became a full Claude Cowork session in August 2026, the point was that sessions live with your account rather than a device, so work started in a tab can be finished on desktop. Not one surface. One session across many.

Be careful how much weight this carries. Every one of these companies described the move as focus, normalisation, or continuity. None of them described it as a single-entry-point design principle — that reading is an argument, and it is ours. What the events establish is narrower and still useful: a separately-branded AI destination has repeatedly turned out to be a transitional artifact.

The orchestrator behind the door

One surface does not mean one agent. Behind it sits an orchestrator — the pattern also travels as supervisor, router, or handoff-based delegation — that reads intent and decides what to call. Specialists still exist. They stop being things the user has to find.

Every major framework now ships some version of this. Anthropic documents orchestrator-workers and routing; OpenAI’s Agents SDK distinguishes the manager pattern from handoffs; AWS Bedrock splits supervisor from supervisor-with-routing; Microsoft’s Agent Framework names five orchestration shapes. The protocol layer followed: Agent-to-Agent reached a stable 1.0 in April 2026 with signed Agent Cards describing what each agent can do.

Underneath the vocabulary, the frameworks divide on one question: does the orchestrator stay in the conversation and synthesize what specialists return, or does it hand the conversation over? OpenAI draws the line clearly — use agents as tools when a specialist should help with a bounded subtask but not take over the user-facing conversation; use handoffs when the specialist should own the rest of the turn. For a single front door, the first is usually what you want. The moment a specialist owns the conversation, you are one bad transfer away from the phone tree.

The architecture is not the interface

Orchestration is an implementation choice. The user should feel one agent that is good at many things, not a switchboard announcing transfers. If your interface says “handing you to the Billing Agent”, you have exposed your architecture as a user-facing concept and reinvented the phone tree.

What the front door owes the user

Progress, without an org chart

Delegated work takes longer than a reply. Show that something is happening and roughly what — “checking your invoices” beats both a silent spinner and a narrated tour of which sub-agent is running. Name the work, not the worker.

One conversation, one memory

Anything the user said earlier is available later, whatever specialist handled it. This is the main thing they get in exchange for the single surface, and the first thing a poorly-built orchestrator loses at the handoff boundary.

The door owns the failure

When a specialist fails, the user does not have a relationship with that specialist. They have one with your product. The front door reports the failure in its own voice, says what it could not do, and offers the next move. “The billing agent returned an error” is not an answer; it is a stack trace with manners.

Consistent permission, consistently asked

A consequential action needs the same confirmation regardless of which specialist performs it. Per-agent permission models produce a product where the same risk is sometimes confirmed and sometimes not, and users quickly learn to click through whatever appears.

One record of what was done

A single place listing actions taken on the user’s behalf, in their language, reversible where reversal is possible. See interaction models for how much of this needs to be seen before the fact rather than after.

One door does not mean many agents

It is worth separating two claims that get run together, because the evidence treats them very differently.

The interface claim — one consistent surface, routing handled by the system — is a design position, and the product outcomes above support it. The architecture claim — that you should therefore build a fleet of specialist agents behind it — does not follow, and the people who build these systems are markedly less enthusiastic about it than the marketing suggests.

Anthropic’s guidance has said since 2024 to find the simplest solution possible and only increase complexity when needed. OpenAI’s agent guide recommends maximizing a single agent’s capabilities first, noting that a single agent with tools is often sufficient. LangChain says plainly that not every complex task needs the approach. These are not hedges from skeptics; they are the vendors whose products would benefit from the opposite advice.

What delegation costs

Anthropic measured agents using roughly four times the tokens of a chat interaction, and multi-agent systems around fifteen times. Each handoff also adds latency, and each specialist starts without the context the orchestrator accumulated unless you deliberately pass it.

That buys something real when the work parallelizes or exceeds one context window — a subagent can explore tens of thousands of tokens and return a one-to-two-thousand-token summary. The mechanism is context compression, not extra intelligence. If your task does not need compressing, you are paying fifteen times for nothing.

The rule that survived contact with production

Cognition argued in 2025 against multi-agent systems outright, on the grounds that dispersed decision-making produces conflicting work — their example was two subagents building a game and producing a bird and a background in different visual styles, neither able to see the other. In April 2026 they revised the position into something more useful: multiple agents can contribute intelligence to a task, but writes stay single-threaded. Many readers, one writer.

That rule was independently reproduced. When Anthropic ran a large parallel-agent experiment in early 2026, the coordination that worked was mechanical — git-based file locking, no LLM orchestrator at all — and the failure mode when agents converged on the same problem was exactly that they overwrote each other’s changes.

A 2026 controlled comparison found that of six multi-agent systems tested, at most one beat a matched single-agent baseline on average accuracy, while a runtime-determined delegation workflow beat every fixed topology by more than twenty points. The pattern in that result is not that delegation fails. It is that pre-specified agent topologies fail, and delegation decided at runtime, on the actual request, works. Which is another way of saying the orchestrator should be reading intent, not executing an org chart you drew in advance.

The practical position

Build the single surface. That part is settled enough to act on. Behind it, start with one capable agent and a good tool set, and split into specialists only when you hit a reason to — overlapping tools the model confuses, genuinely parallel work, or context that will not fit.

Anthropic said in late 2025 that it remains unclear whether a single general-purpose agent or a multi-agent architecture performs better across contexts. Nobody has settled this. Anyone telling you otherwise is selling something, and the honest answer is that the interface question and the architecture question have very different amounts of evidence behind them.

Where the argument breaks down

Taken too far, a single entry point becomes an argument against contextual help, and that would be wrong. An agent that acts on the thing you are looking at has real advantages: it inherits the selection, the record, the current state. Making someone open a panel and describe what is already on screen is worse, not better.

There is a genuine cost to routing everything through a generalist, too. An extra hop adds latency, and intent can be lost in translation between the orchestrator and the specialist that actually knows the domain.

The resolution is that contextual affordances are not the same thing as parallel conversations. A “summarise this” control on a document is fine, and should be there. What it should not do is open a second, separate chat with its own history. It should hand into the same surface, carrying its context with it, so there is still one thread and one record. Many entry points, one conversation.

Anti-patterns

  • An agent picker. If the user has to choose the agent, the routing problem was handed to the wrong party.
  • Chat widgets that each keep their own history on different pages of the same product.
  • Narrating internal handoffs to the user as though the sub-agents were people they should know about.
  • A specialist that answers in a different voice, with a different permission model, from the surface that invoked it.
  • Contextual buttons that open new conversations instead of adding to the existing one.
  • An orchestrator that silently drops what the user said three turns ago because the specialist did not receive it.

Questions to ask about your own product

  • How many distinct agent surfaces can a user reach today, and do they share history?
  • If someone asks a question in the wrong place, what happens? Are they redirected, or answered?
  • Does a request spanning two internal domains work, or does it fall between them?
  • Is there one place a person can go to see everything done on their behalf?
  • Do your contextual entry points add to the main thread, or start their own?
  • Does a consequential action get confirmed the same way no matter which specialist runs it?

What the research actually supports

One study tests the handoff advice above fairly directly. A CHI 2026 paper on how people read multi-agent interfaces held the answer constant and varied only how much of the process was shown, from a bare final answer through to full agent debate. Two findings matter here.

The first is a Goldilocks effect: participants wanted enough process visibility to see the system deliberating, and more than that actively eroded trust on simple tasks. Most wanted a simple answer first with the option to expand. The second is more pointed — whether agents ran sequentially or in parallel, and how information flowed between them, stayed perceptually latent and did not affect trust judgements at all. The authors also advise surfacing distinct lines of reasoning rather than raw agent counts, because people use the number of agents as a trust heuristic and it is a bad one.

That is about as direct a result as this field offers, and it says: do not visualise your orchestration topology. Users cannot perceive it and do not reward it. Report the work, offer the detail on request, and keep your architecture to yourself. A related 2026 study on agent-trace oversight found designs that made reviewers feel more confident produced little actual accuracy gain — worth holding onto before you build an elaborate trace viewer.

The best argument against this page

Atlassian’s design system takes the opposite position explicitly, and it is the only major design system with a published stance on any of this. Its first principle is integrated, not segregated: the agent lives where work already happens, embedded alongside everything else rather than set apart, with controls in the working surface to avoid context switching. If you are looking for the strongest published counter-argument, that is it.

Nielsen Norman Group has published both sides within two months. April 2026 guidance says to consolidate AI chat and avoid competing bots, on the grounds that users should not need to understand your architecture to find help. May 2026 guidance, from watching people fail to discover an agent at all, recommends the opposite: multiple entry points, because most users defaulted to the familiar interface and never tried the agent. They never reconcile the two.

The reconciliation we would offer — and this is our argument, not their finding — is that these are answers to different questions. Discoverability wants many doors. Coherence wants one agent. Those are only in conflict if you assume a door implies a separate agent, and it does not. Consolidate the identity and the session, not the number of entry points. Put an affordance wherever the work is, and have every one of them open into the same continuing conversation with the same memory. That is close to what Anthropic shipped by making the browser panel a session rather than a surface, and close to how the enterprise “front door” pattern is usually described — a routing layer above specialists that keep their own surfaces for anyone who wants to go direct.

What nobody has measured

There is no controlled comparison of embedded contextual assistance against a central agent surface. None. Anyone telling you research shows inline beats chat is overstating it, and so is anyone claiming the reverse. The measured work in this area tests trace design, not placement. Beyond the two studies above, the major UX authorities — Nielsen Norman Group, Google’s People + AI Guidebook, Microsoft’s HAX toolkit — have published nothing on disclosing that a request was delegated to a sub-agent. The architecture literature is rich; the interface literature barely exists. Most of the “what the front door owes the user” section above is therefore reasoned rather than researched, and we would rather say so.

References

Related

Last reviewed . The consolidation argument is a design position supported by product outcomes rather than a controlled finding, and both the architecture question and the placement question are genuinely unsettled. Treat the single-session recommendation as the durable part, the single-surface recommendation as a strong prior, and the delegation advice as a starting point to measure against your own workload.

Stay Updated

Analysis of AI search, crawler policy and agent standards — sent when there is something worth reading, roughly twice a month. Unsubscribe anytime.

We store your email address only to send you this newsletter. See our privacy policy.