Traditional software had an assumption so basic we never had to name it: what the user sees is what the system knows.
A table on screen — the system works from that table. A form the user fills in — the system processes that form. This assumption was so fundamental that we built entire interaction paradigms around it. We never had to "design" it, because it was free — baked into how software works.
Agents broke that assumption. And I'm not sure most design teams have noticed yet.
A Small Question — With a Large Consequence
When I'm working with a team on an agent feature, the first conversation is usually about form: Is this a chat interface? Embedded in a panel? Running silently in the background? These are real questions. But I've started noticing that they all sit on top of a more fundamental question that usually gets skipped entirely.
The question is: when a user is looking at a complex interface and invokes an agent to "analyze this" — what does the agent actually see?
It sounds technical. Context windows, token limits, what gets passed where. But I think it's a design question first, and a severely underestimated one.
The user is looking at a full screen — multiple panels, multiple data states, multiple in-progress threads. When they click "analyze," the agent might be working from a small slice of that screen, or from a much larger set of data that includes things not even visible. The user's mental model of what the agent knows, and the agent's actual context, don't match. There's a seam between them.
In traditional software, this seam doesn't exist. "What the system knows" and "what the user sees" are the same thing. In agent-based systems, the seam is the default — and most designs don't address it at all.
What the Seam Actually Costs
Once you see the seam, you start noticing how much depends on it.
Take credibility. If an agent delivers an analysis, and the user doesn't know what information that analysis was built from, the user is making a blind judgment — either full trust or full skepticism, nothing in between. Both extremes are bad for long-term adoption. Full trust means users will accept wrong answers. Full skepticism means users reject correct ones.
Take error correction. If the analysis is wrong, what does the user fix? The conclusion? Or the input the agent used? These are different layers of the problem. Most interfaces offer only one kind of fix — a "regenerate" button. But if the agent was missing critical context to begin with, regenerating from the same broken input won't help.
And then there's the multi-agent case. When a system has several agents with different scopes, the problem compounds. Users no longer just need to know "what does it see?" — they need to know "which agent is responding right now, and how does its context differ from the others?" If they can't answer "who's responding," they certainly can't answer "what does it know?"
Why This Is Easy to Miss
This problem is nearly invisible in demos.
A demo is a controlled environment: clean data, single scenario, agent capabilities calibrated exactly to match user expectations — because the whole scene was designed to look good. In that context, agent context and user intent align naturally. The seam doesn't show.
Real usage isn't like this. Real interfaces are messy. Data is redundant. User intent is ambiguous. Multiple agents are running with different responsibilities. The seam only becomes visible in extended, real-world use — which is often after a user's first impression has already been formed.
This is why I don't think this can be deferred to "optimize later." It needs to be treated as a core design problem from the beginning — as fundamental as "what form should this agent take?" Because if the seam isn't addressed in the initial design, users will land in a permanent state of "I'm not quite sure what it's doing" regardless of what interface you wrap around it.
It's a Translation Problem
Once I framed it this way, my understanding of what "agent presence design" actually means started to shift.
It's not just "how do we make the agent's existence visible to users?" The more accurate question is: how do we translate the agent's cognitive boundary into something users can understand?
These sound similar but start from very different places. The first asks "is it there?" The second asks "what does it know, what doesn't it know, and why?" The second is what users actually need — and almost never get.
Users don't need to know how the agent works. But they need to know where the agent's world and their world overlap — and, when they don't overlap, what to do about it.
Two Directions — Neither Complete
Thinking about this as a translation problem opened up two directions.
One direction is "user tells agent." The other is "system tells user." Both are trying to close the same gap.
I haven't validated either of these at scale — they're more "directions worth pursuing" than "confirmed solutions." But I've become increasingly certain of one thing: this seam won't close by itself just because agents get smarter. It's structural. As long as "what the user sees" and "what the agent processes" are different scopes, the seam exists.
What we can do is make it legible — so users know where it is, know what they can do about it, and know which side of it a discrepancy lives on. That's harder than picking an interface form. But it's the more important design problem.