In traditional software design, what the user perceives and what the system actually processes are basically the same thing — you select something, the system works on that thing.

There's a table on screen, the system works from that table. A user fills out a form, the system processes that form. The object of design is obvious.

When Agents enter the picture, that assumption breaks down for the first time.

01

A Problem That Looks Small but Isn't

When my team discusses Agent features, we usually start with presentation: what should it look like — a chat window, a panel embedded somewhere, a background process that stays out of the way.

These are real questions. But I've come to realize they're built on top of a more fundamental question that often gets skipped: are the user and the Agent working on the same thing?

When a user is looking at a complex interface and asks an Agent to "analyze this" — what does the Agent actually see?

It sounds like a technical question — how context gets passed, how token limits get handled. But it's also a design question. One that's seriously underestimated.

From the user's side, they're looking at a full screen — multiple panels, lots of data, various states. But after they click "Analyze with AI," the Agent might only be processing a small slice of what's on screen. Or it might be pulling from far beyond the screen, reaching into connected modules the user isn't even thinking about.

The user's mental model and the Agent's actual scope of awareness — there's a gap between them.

In traditional software, that gap doesn't exist. "What the system processes" and "what the user is working on" are the same thing. In Agent-based design, most interfaces don't address this gap at all.

02

What That Gap Sets Off

Once you see the gap, a lot of problems that seemed "already solved" turn out to be still open.

Take credibility of results. If an Agent produces an analysis and the user doesn't know what information that analysis was based on, their judgment of the result is essentially a blind guess — they either trust it completely or doubt it completely, with nothing in between. Both extremes are dangerous for long-term trust. Unconditional trust means users accept results when they shouldn't. Unconditional skepticism means they reject results even when they're right.

Then there's error correction. Say the Agent's analysis is off and the user wants to fix it — fix what exactly? The conclusion? Or what the Agent was looking at in the first place? These are two completely different levels of correction. Most interfaces only offer the first — a "regenerate" button — without touching the second. If the Agent was missing critical information to begin with, regenerating won't help.

And there's a less obvious problem when a system has more than one Agent. If one Agent handles a certain type of task and another handles something different, the user's problem is no longer just "what did it see" — it becomes "which one is responding to me right now, and how does its scope of awareness compare to the other one's?" If the user doesn't even know who they're talking to, asking what it saw becomes almost impossible.

03

Why This Gets Missed

There's a pretty simple reason: the gap is nearly invisible in demos.

In a well-prepared demo, the data is clean, the scenario is narrow, and the Agent's capabilities naturally line up with user expectations — because the whole thing was designed to look good. The seams don't show.

Real usage is nothing like that. Interfaces are messy, information is redundant, user intent is ambiguous, and multiple Agents with different responsibilities are running in parallel. The gap only surfaces through real, complex, sustained use.

That's why I don't think this can wait until "we'll clean it up later." It needs to be treated as a core design problem from the start — at least as important as deciding what form the Agent should take. Maybe more important. Because if the gap isn't part of the design from the beginning, it doesn't matter whether you use a chat interface or a canvas — users will stay stuck in "I'm not quite sure what it's doing" territory.

04

This Is Actually a Perception Problem

The core of perception is "how do you make the Agent's existence perceptible to the user." But a more precise framing is: aligning the Agent's cognitive scope with the user's sense of what's being worked on.

Users don't need to understand how an Agent works. But they do need to know where their world and the Agent's world overlap — and what to do when they don't.
Two directions for closing the gap
Direction 1 — User declares scope Right now, I want you to focus on this. Point at specific content and tell the Agent "this is what I want you to look at." It turns the boundary of context from something users passively receive into something they can actively shape — instead of waiting for the Agent to understand them, they tell it what they want it to understand.
Direction 2 — System surfaces scope The system records which information each task actually relied on, and surfaces that back to the user. Less intuitive, and it involves real technical questions — like how to make context visible and interactive. But that's a product design problem.

One direction is "user tells Agent." The other is "system tells user." But they're trying to solve the same thing: making sure "the Agent's world" and "the user's world" aren't two black boxes guessing at each other.