The Agent Is a User. It Isn’t a Person.

We keep describing AI agents as if they were people.

We give them names, assign them roles, organize them into teams, and talk about what they know, remember, want, and decide. We build interfaces that resemble employee directories and dashboards that resemble organizational charts.

That language is understandable. But the metaphor can quietly become an architecture.

An agent is not a teammate or an employee. It does not wake up with its own agenda. It does not need coffee. Left to its own devices, it does nothing. An agent runs because a person, system, event, or previously established process initiates its execution.

That distinction is the starting point for Agent Experience, or AX.

AX is the design of interactions between AI agents and the systems in which they operate: the tools they discover, the information they interpret, the actions they invoke, the errors they encounter, the constraints they follow, and the outcomes they produce.

The thesis is simple:

An agent is a user of the system, but it is not a person.

That means we can apply the rigor of UX to agent interactions without importing assumptions about human intention, memory, motivation, or experience.

The Agent Is Still a User

In traditional user experience design, we study how people interact with systems. We consider their goals, capabilities, expectations, constraints, and environments.

But a user does not necessarily have to be a person.

An AI agent can discover capabilities, interpret information, invoke tools, encounter errors, recover from failures, and produce outcomes.

From the system’s perspective, that is a user interaction.

The term AX is useful because it connects a new problem to decades of UX practice. Discoverability, affordances, information architecture, feedback, constraints, and error recovery all have meaningful counterparts in agent interactions.

AX does not need to replace UX. It is better understood as a specialization within a broader experience architecture.

The agent is a user of the system. It just is not Stacy or Bob.

And that difference matters.

An Analogy Is Not an Architecture

Consider a conventional user persona.

We might describe someone’s motivations, frustrations, behaviors, needs, and goals. These are useful because human users bring their own intentions to the systems they use.

An agent does not.

An agent operates in response to a command, an event, or an established execution process. It can formulate plans, select actions, and adapt its behavior, but its operational objectives originate within an externally defined context.

There is a distinction between an objective and an intention.

We can describe an agent as pursuing an objective without assuming that it possesses independent desires. We can describe it as remembering information without assuming its memory resembles human memory, or as reasoning without assuming its internal processes resemble human thought.

These terms are useful abstractions. They become problematic when we mistake the abstraction for the mechanism.

Use analogy to explain unfamiliar systems, but use mechanism to define them.

For AX, that means describing the actor in terms of capabilities, operating context, authority, interaction contracts, and observable behavior.

Not personality.

A research agent and a reviewer agent may have different responsibilities, but that does not make them different kinds of beings. They may be instances of the same underlying model operating with different instructions, tools, knowledge, and constraints.

The distinction is architectural, not anthropological.

More Rail, Less Guard

This leads to a design question we have been exploring while developing Routekit, our open-source environment for governing AI-enabled work:

How much unreliable agent behavior can we eliminate by designing a better operating environment rather than adding more instructions and restrictions?

Much of the current approach to agent reliability involves guardrails. We give an agent a task, provide access to tools, and surround its execution with policies, validators, reviewers, retries, and escalation mechanisms.

Those controls matter. Some are indispensable.

But there is a difference between designing a system that continually catches undesirable behavior and designing one that makes desirable behavior easier to produce in the first place.

For both human and agentic users, that is a case of more Rail, less Guard.

A guard prevents an unacceptable action from completing.

A rail shapes the available path so that the appropriate action is easier to identify and execute.

Traditional UX has pursued this distinction for decades. We do not simply present users with every possible action and display an error whenever they choose incorrectly. We structure information, constrain inputs, establish sensible defaults, provide contextual feedback, and make valid operations discoverable.

Why should agent interfaces be any different?

An agent interacting with a poorly designed tool environment may need to infer capabilities from ambiguous descriptions, reconstruct state from prose, guess at required parameters, and recover from preventable errors. And it’ll gladly overspend your tokens along the way.

Poor AX is expensive.

A better environment exposes explicit contracts, structured context, valid state transitions, and actionable feedback. The objective is not to make the agent feel comfortable. It is to make correct execution more reliable and less costly.

Rail does not eliminate Guard. A well-designed interface can reduce the likelihood of an unauthorized operation, but it cannot replace independent enforcement of authorization.

The two mechanisms complement one another.

What Can We Borrow from UX?

The connection to traditional UX is useful, but the transfer is not automatic.

In an earlier UX287 article, Principles for User-Centered Problem Solving, I explored several established UX laws through the lens of practical product design.

Those principles provide a starting point for AX, but they do not necessarily transfer directly.

Consider Hick’s Law, which describes how human decision time changes with the number of choices presented.

An agent does not experience decision-making as a person does. But the number, clarity, and relevance of available tools may still affect its ability to select an appropriate action.

Or consider Jakob’s Law, which concerns people’s expectations that interfaces will behave like those they have encountered before.

An agent does not develop familiarity through lived experience. But consistency across tool contracts, schemas, and response structures may reduce ambiguity and improve execution reliability.

Other principles have weaker analogues. Fitts’s Law concerns physical movement toward a target. An agent invoking a function does not move a pointer across a screen, so applying the law literally would be unhelpful. Principles grounded in human working memory likewise cannot simply be mapped onto a model’s context window.

The useful question is not whether every UX law has an agent equivalent.

It is whether the underlying design problem exists for this class of user, and whether the principle offers a useful way to investigate it.

That is a separate exploration.

For now, the larger point is this:

AX should inherit the rigor of UX, not blindly inherit its assumptions.

Designing for a Different Kind of User

There are measurable consequences to the design of an agent’s operating environment.

Give the same model the same task through two different interfaces.

One provides broad capabilities, loosely described tools, unstructured context, and generic error messages.

The other provides task-relevant capabilities, explicit contracts, structured state, bounded operations, and recoverable failures.

We should expect differences in performance, although the magnitude needs to be measured rather than assumed.

Those differences can be evaluated through task completion, tool-selection accuracy, retries, intervention frequency, latency, and computational cost.

Agent reliability is not exclusively a model problem or a prompting problem.

It is also an experience design problem.

That creates an opportunity for designers. We can identify the actor, understand its capabilities and constraints, model the interaction, define successful outcomes, and test whether the design produces them.

The research methods will differ. We do not interview an agent to discover its frustrations or observe its body language to identify confusion. We examine behavior, execution traces, tool interactions, errors, and outcomes.

A human interface and an agent interface may expose the same underlying system through very different representations.

That is not an inconsistency.

It is designing for the user.

Observe the Work, Not the Fictional Workforce

These distinctions also influence how we design interfaces for people supervising agentic systems.

Many agent interfaces emphasize the agents themselves. We see named assistants, specialized workers, team structures, and activity feeds that resemble workplace conversations.

That can make complex execution more approachable. But it can also obscure what matters.

When an agent completes a task, I want to understand what changed.

What objective initiated the work? What authority was delegated? Which tools were invoked? What knowledge was consulted? What state transitions occurred? What was validated? Where did the system intervene? What outcome was produced?

The identity of the executing model matters, but primarily as attribution and operational context.

The fundamental objects of observation are the work, its state, its dependencies, its lineage, and its outcomes.

Instead of organizing everything around a fictional workforce, organize it around observable activity. Human operators can then inspect execution, knowledge, and governance through different views of the same underlying evidence.

This does not mean eliminating agent identities or role-based views. Those can be useful. It means avoiding the assumption that the agent is the primary object simply because we have given it a name.

There is also an important UX/AX intersection:

The agent needs an interface that supports reliable execution.

The human needs an interface that supports understanding, supervision, and intervention.

Both interact with the same system, but their needs are different. Designing one experience without considering the other leaves part of the system undesigned.

Intent Has Lineage, Too

An agent’s activity should be traceable to the objective that authorized it.

Consider a human initiating a workflow that produces hundreds of tool calls across multiple agents over several hours.

Those operations are not necessarily hundreds of independent intentions. They may all descend from one authorized objective.

That gives us a useful relationship:

Originating intent → Delegated objective → Execution → Observed outcome

Each stage can introduce decisions, constraints, and state changes. Each should retain a traceable relationship to what came before.

This matters for accountability, debugging, and recovery. When something goes wrong, it is not enough to know which agent made the final tool call. We need to understand why that operation was available, what authorized it, and how the system arrived at that state.

The lineage of authority becomes as important as the lineage of execution.

This is also where knowledge lineage enters the picture.

Consider an agent investigating a product requirement. It retrieves the current requirement, discovers a conflicting implementation constraint, and produces a recommendation.

That interaction is not just an execution event. It may also introduce a new assertion into the project’s knowledge.

A subsequent agent may encounter that assertion, evaluate it alongside the original requirement, and contribute another finding.

The system is no longer simply providing context to agents. Agent interactions are participating in the evolution of that context.

Knowledge informs execution. Execution produces knowledge. That knowledge informs future execution.

And as that cycle repeats, preserving the history of how knowledge evolved becomes essential.

One principle we’re exploring in Routekit captures this:

No future state should require the destruction or reinterpretation of its ancestors to establish its own validity.

A new assertion can extend, challenge, or supersede an earlier one without erasing the context in which that earlier assertion was valid.

The deeper implications for provenance, reconciliation, and shared knowledge coordination deserve their own discussion.

For AX, the immediate implication is simpler: an agent’s ability to act correctly depends partly on whether the knowledge available to it preserves authority, provenance, and applicability.

A well-designed knowledge interface should not force an agent to reconstruct those relationships from an undifferentiated collection of retrieved text.

That is another example of Rail.

Design the System, Not the Metaphor

We can call an agent a user. We can borrow the methods of UX to understand its interactions. We can use roles and organizational metaphors to make unfamiliar systems easier to discuss.

But none of those abstractions should obscure the mechanisms underneath.

Agents receive objectives through command and delegation. They operate within defined capabilities and constraints. Their behavior can be observed, measured, validated, and governed.

Designing these systems requires us to consider both the experience of human operators and the interaction requirements of nonhuman actors.

These are connected design problems.

They are not solved by pretending agents are people.

The more interesting opportunity is to apply the rigor of user-centered design to systems where humans are no longer the only actors interacting with software.

Not by making machines more human.

By making the systems they operate within more understandable, reliable, and accountable.

The model is not the system. And the agent is not the person.