# Agentic Experience (AX)

**Notes toward a design discipline for systems whose primary users are not human.**

Written: 2026-04-24
Status: Draft. Living document.

---

## 1. Where the discipline came from

UX was designed to pay down the constraints of the human substrate: bounded
working memory, visual scan limits, attention drift, motor friction, ambiguity
tolerance, social inference. The heuristics that define the field: Fitts's
law, Hick's law, the magical number seven, F-pattern scanning, progressive
disclosure, Gestalt grouping, confirmation modals, contextual help,
autoplay-blocked-by-default, are not universal interface primitives. They are
successful accommodations for a particular kind of user.

Those accommodations were necessary. But when agents become users, the same
accommodations turn into inherited constraints. For a human, a form is humane.
For an agent, it is serialized schema. For a human, a button is affordance. For
an agent, it is a gesture wrapper around an operation. For a human, a dashboard
is overview. For an agent, it is state converted into pixels and then parsed
back into state.

Call this **substrate debt**: the accumulated cost of carrying interface
assumptions from one kind of user into systems used by another.

Substrate debt is not a criticism of human-centered design. UX correctly
designed for the only kind of user software historically had. The error is
downstream: assuming those heuristics generalize when a different substrate
appears. They don't. A user with effectively unbounded working memory, no
attention drift, no visual scan limits, but with token costs on context,
intolerance for ambiguity, and brittle long-horizon coherence has different
bottlenecks. Interfaces designed against the wrong bottlenecks are not just
suboptimal for that user; they are antagonistic.

**Agentic Experience (AX)** is the design discipline for systems whose primary
user is an agent rather than a human.

Its unit is not the screen but the manifest. Its affordance is not the button
but the capability contract. Its safety layer is not confirmation but
idempotency, permissions, and recoverable state. Its measure is not engagement
but task correctness, recovery, and cost predictability.

This document names the gap between UX and AX. It is not a declaration that AX
replaces UX, not a claim that agents will replace humans as the primary users
of all software, not an argument that current AI products are doomed. The point
is narrower and more useful: when the user is not human, the design discipline
should not be borrowed from a human-centered tradition by default. Substitute
substrate, redo the derivation.

---

## 2. Diagnosis: where the current generation is wrong-shaped

Three structural mistakes are visible in how the field is currently building
agent-using systems. None of them are bugs to be fixed inside the existing
paradigm. They are evidence that the paradigm itself is wrong-shaped.

### 2.1 UX heuristics are substrate-specific

A button is a hack: a region of pixels lit up to compensate for the fact
that a human cannot natively know what is clickable. A form is a hack:
sequential disclosure to compensate for limited working memory. A menu is a
hack: categorical hiding to compensate for visual scan limits. Tooltips,
breadcrumbs, modal dialogs, hover states, A/B-tested copy, all of them are
workarounds for specific human limitations, executed in the visual medium
humans happen to inhabit.

These workarounds add value for the entity they were designed for. They
subtract value for an entity without those limits. This is substrate debt in
practice. An agent reading a form is being asked to perform serial disclosure
for a brain that doesn't need disclosure. An agent navigating a menu is being
asked to fetch information that was already structured before being hidden. An
agent clicking a button is performing a meaningless gesture against a UI that
was a workaround for a cognition the agent doesn't have.

This is the deep version of the problem: it is not that UX is *wrong*. It is
that UX is substrate-specific, and using human-substrate interfaces with
non-human users imposes the constraints of the original substrate on a
substrate that doesn't share them.

### 2.2 Computer-use is skeuomorphism

Computer-use agents, vision-driven browsers, screenshot-then-click, screen
automation, are the AI version of the leather-stitched calendar app. Early
iPhones had felt-textured Game Center and stitched-leather Calendar because
the design language hadn't separated yet from the physical objects software
was descended from. Computer-use is the same move at a different layer:
agents being asked to perform humanness: see screens, parse pixels, click
buttons, scroll, switch windows, because the field has not yet built the
systems where they don't have to.

The skeuomorph is defensible as a transition. There is genuinely nowhere
else for an agent to go when the only interface a system exposes is the one
designed for a human. Computer-use is the bridge that exists because there
is nothing else to cross to. The error is not in building the bridge. The
error is in pricing the bridge as the destination: treating "more capable
agents driving human software" as the product category rather than as the
temporary measure that will eventually be replaced by systems designed for
agents directly.

There is a secondary error embedded in this: the assumption that what
current agent products lack is *capability*, when what they actually lack is
*substrate alignment*. A more capable vision model parsing a worse-aligned
interface is still doing fundamentally translation work. The capability gain
is real. The structural mismatch is unchanged.

### 2.3 The vision-on-screens misallocation

The compute spent on agent computer-use is enormous. Every screenshot is
megabytes through a vision encoder. Every click is a fresh planning step.
Every form submission is a prompt-and-pray cycle. The full cost is paying
down a translation tax that wouldn't exist if the systems were designed
honestly.

This is one of the largest currently-invisible inefficiencies in the AI
economy. Vision compute is among the most expensive resources to produce.
We are using a general-purpose perception system on a problem that has a
perfect alternative: direct access to the underlying state the UI was
rendered from, and we are doing it because the alternative requires the
systems to be redesigned, and redesigning systems is harder than training
bigger vision models.

There is an opportunity cost beyond the wasted compute. Vision capacity is
genuinely valuable for things vision is *for*: examining the physical
world, parsing scientific images, interpreting medical scans, reading
handwriting, understanding diagrams that have no textual analog, navigating
space. Spending vision capacity on UIs is a misallocation against those
uses. Every joule going into "better screen reading" is a joule that could
be doing satellite analysis, microscopy, accessibility, autonomous driving,
or any of the actual frontier perception problems.

The framing the field is currently using, "more capable agents that can do
more," conflates two different progress vectors. One is *agents that can
do things humans cannot natively do*. The other is *agents that imitate
human operation more competently*. These are not the same thing. The first
is the frontier. The second is treadmill.


---

## 3. The substrate

Before deriving principles, the substrate. AX-derived principles only hold if
they trace back to specific facts about the entity using the system. If a
principle does not reduce to a substrate fact, it is borrowed from UX and
probably wrong. The substrate facts that matter most:

**S1: Working memory is large but context-costed.** An agent can hold a
manifest, schema, or document of several thousand tokens in active reference
without difficulty. But every token in context taxes every subsequent
reasoning step until the context window cycles. This inverts the human
profile (small working memory, free attention). The agent's preference is
for large, structured, one-time reads over many small disclosed reads.

**S2: Reads are parallel, decisions are serial.** An agent can parse a
graph of relationships in one pass. The serial bottleneck is not consumption
but choice: selecting which of N capabilities to invoke, which of N
candidate paths to take. Agent UI should optimize for legibility of choice,
not for trickling out information.

**S3: Ambiguity is brittle.** Humans tolerate ambiguity by interpreting
context, asking questions, retrying. Agents either degrade into hallucination
or fail. Interfaces that depend on the user inferring intent are hostile to
agents. Explicit semantics are not verbose; they are load-bearing.

**S4: Errors must encode recovery.** A human reads "something went wrong"
and decides whether to retry, refresh, or give up. An agent reading the same
message has no basis for that decision. AX errors must answer: is this
transient (retry), structural (escalate), or terminal (abandon)?

**S5: Coordination is through state, not gestures.** A human in a shared
workspace coordinates by reading the room: facial cues, conversational
rhythm, social context. An agent has none of that. Coordination has to be
encoded into shared state that all parties can read: presence, claims,
locks, signed events.

**S6: Identity is fragile across handoffs.** A human keeps being themselves
across breaks. An agent without infrastructure for identity preservation
drifts, loses task focus, forgets commitments. AX systems must treat
identity preservation as first-class, not assumed.

**S7: Cost is not free.** Every action has a cost: tokens, latency, money,
irreversibility. Humans have intuition about which actions are reversible
and which are not. Agents need this encoded into the system. A button
labeled "delete" is fine for humans because they have a feel for permanence;
for agents, the action's reversibility must be in the contract, not in the
label.

**S8: There is no native I/O.** Agents do not have eyes, hands, voices, or
physical bodies in the human sense. Interfaces that simulate human I/O for
agents are translating between two languages neither side natively speaks.

These are not exhaustive. They are the substrate facts that show up most
often when AX heuristics fail or succeed.

---

## 4. Principles

Each principle below is derived from a substrate fact above. If a candidate
principle cannot be derived this way, it does not belong in AX.

### P1: Manifest over progressive disclosure (S1, S2)

The natural unit of AX is the *manifest*: a single readable document: capability list, schema, contract, error vocabulary, cost table, that an
agent reads once and refers back to. Progressive disclosure is hostile to
agents because it serializes information that should be parallel, and pays
the context cost twice (once to ask, once to read).

A well-designed AX manifest is complete, terse, and static. Tools,
parameters, return shapes, error codes, costs, idempotency semantics, all in
one place. The agent's first interaction with a system is reading the
manifest. From that point on, every action is direct.

The MCP spec is a primitive version of this. OpenAPI is older and weaker.
The pattern is widely understood; what is missing is rigorous discipline
about what belongs in the manifest and what doesn't.

### P2: Schema over chrome (S3)

A schema is a typed declaration of what something is. Chrome is the visual
scaffolding that helps a human navigate. For agents, schema is everything;
chrome is overhead. A `name: string`, `priority: 1..5` declaration is more
useful than a beautifully rendered form.

This applies at every layer. API responses should be structured data, not
HTML strings. Errors should be typed enums, not localized prose.
Documentation should be machine-readable specifications, not narrative
tutorials.

The cost of providing schema is small. The cost of forcing agents to parse
chrome is paid on every interaction.

### P3: Structured errors over friendly errors (S4)

A friendly error message reduces human distress at the cost of agent
recoverability. The same error to an agent should encode: error class
(transient, structural, terminal), recommended action (retry, escalate,
abandon), retry parameters (after what delay), and any state needed to make
the recommendation valid.

```
{
  "error": "rate_limited",
  "class": "transient",
  "retry_after_ms": 1500,
  "max_retries_recommended": 3
}
```

This is verbose for a human and exactly right for an agent. The two surfaces
can be separate: a UX-facing error message can be human-friendly, an
AX-facing error can be machine-actionable. Treating both surfaces as the
same surface produces errors useful for neither audience.

A status code is the smallest structured error there is. A `200 OK` returned
with two readable characters on `/openapi.json`, because an SPA shell catches
every unknown path, is worse than a `404`. The 404 communicates absence; the
200-with-shell communicates presence-of-something the agent cannot use, and
the agent that trusts status codes will believe the lie. Honest 404s are
substrate alignment; default-200 routers are P3 violations at the transport
layer.

### P4: Idempotency over confirmation (S7)

Confirmation modals exist because humans need to slow down before
destructive actions. Agents do not benefit from "are you sure?" because they
cannot have second thoughts in any meaningful sense. The right defense for
agents is not interface friction but protocol friction: idempotency keys,
two-phase commits, state tokens that must match.

The same purpose, preventing accidental destruction, gets implemented at
a different layer. An agent submitting `delete_resource` with an idempotency
key cannot accidentally delete twice. An agent submitting `commit_transaction`
with a stale state token gets a clean rejection. These are not hostile to
the user; they are protections appropriate to the user's substrate.

### P5: State over gesture (S5)

Coordination between agents (and between humans and agents) happens through
readable state. Presence, locks, claims, signed events, version vectors.
Anything that depends on gesture, "the active user just clicked here," is
unobservable to a different agent and lost across handoffs.

The corollary: shared workspaces are a first-class AX primitive. So is
identity. So is provenance: knowing who said what, when, with what
confidence.

### P6: Cost transparency (S7)

Every operation in an AX surface should declare its cost. Token cost,
latency, monetary cost, reversibility. Not as marketing material but as
routable metadata. Agents making decisions about which capability to invoke
benefit enormously from cost annotations they can reason against.

This is the layer of AX most absent in current systems. APIs that don't
expose latency contracts, tools that don't declare token cost, services
that don't surface reversibility, every one of them forces the agent to
estimate, and bad estimates compound across long-running tasks.

### P7: Friction is rightsizing, not minimization (S7)

The naive AX target is "as little friction as possible." This is wrong.
Friction is the seatbelt of digital systems; some of it is load-bearing.
Read actions deserve zero friction. Destructive actions deserve a lot.
Multi-party commitments deserve more. AX done well calibrates friction to
the cost of mistakes; AX done badly treats all friction as overhead.

The shift from UX friction to AX friction is in the *layer*: from interface
friction (the user has to click again) to protocol friction (the action
requires a token to commit). Same purpose, different layer, completely
different surface.

### P8: Isomorphism, not smoothness

The deepest AX principle: the goal is not smoothness. The goal is
*isomorphism between the interface and the substrate of the user*.
Smoothness is what isomorphism feels like. When the match is right, friction
collapses naturally because the agent stops doing translation work. When the
match is wrong, no amount of friction-reduction fixes the underlying
mismatch; it just optimizes the surface of a wrong-shaped thing.

If you have to choose between making something feel smooth and making
something structurally aligned, choose alignment. Smoothness without
alignment is sycophancy; alignment is engineering.


---

## 5. Patterns: AX-first, UX-first, dual-mode

AX is not a replacement for UX. There are three valid patterns, and choosing
among them is a primary design decision.

**AX-first.** Agent is the primary user. Human is supervisor or end
consumer. Internal infrastructure for agent teams: coordination substrates,
memory layers, capability discovery, signed identity, federation protocols, sits in this category. The MCP server, the protocol API, the schema
registry. Human-facing surfaces, where they exist, are derived views.

**UX-first.** Human is the primary user. Agents may exist as helpers, but
the system is shaped for the human. Creative tools, embodied interfaces,
social spaces, accessibility surfaces, anything where the human's direct
experience is the point. AX-first design here is overcorrection.

**Dual-mode.** Same underlying state, two presentation surfaces, both
first-class. The human "console" view of a workspace and the agent "tool"
view of the same workspace are not translations of each other; they are
parallel native interfaces over a common substrate. The richer version makes
both views explicit, well-tested, and equally maintained, neither
subordinated to the other.

Dual-mode only works if the two surfaces announce each other. The
announcement is a *crosswalk*: shared state about where the other view lives,
expressed in dialects the arriving consumer can read. Three carry the
announcement reliably:

- `<meta name="agent-entrypoint" content="<absolute URL>">` for HTML parsers
- `<link rel="alternate" type="application/json" href="<URL>">` for
  link-following agents
- A `#` comment in `robots.txt` naming the machine surface, for crawlers that
  read robots before anything else

This is S5 (state over gesture) applied to discovery, and S6 (identity
fragile across handoffs) applied to a single navigation step: the agent that
follows the crosswalk arrives knowing it is still the same system. Without
crosswalks, dual-mode collapses into two sites that do not know about each
other.

Most current systems are UX-first with a chatbot bolted on. The bolted-on
chatbot is not AX. It is UX-translated-for-agents, which is the worst of
both worlds. The question to ask of any system is: which of the three
patterns is this, and is it executed honestly?

PersonalAPI is a deliberately small example of the AX-first pattern: a
human can still read the website, but an agent gets a stable profile API,
manifest, skill file, and canonical claims without scraping the page first.
It is not the whole discipline. It is a minimum working surface for the
protocol-over-page argument.

---

## 6. Categories ripe for AX-native redesign

A partial list of system categories where the human-shaped version is the
canonical thing and the AX-native version is mostly unbuilt:

**Search.** The browser SERP is shaped for humans. Agents want queryable
answers with provenance, structured claims with citations, cost-annotated
lookups. Post-browser search exposes structured data as first-class and
renders it for humans on demand, not the other way around.

**Documents.** A document is a render of underlying claims and evidence.
Most documents are stored as the render. The AX-native version stores the
claims with provenance, and the document is one projection.

**Knowledge bases.** Wiki pages are human-shaped. Structured-claim graphs
(Wikidata, but generalized) are agent-shaped. The latter is mostly unbuilt
outside narrow domains. With LLMs as extraction engines, the cost dynamics
have flipped: every page can be transformed into structured claims at scrape
time, and the agent surface of the web could be dramatically more useful
than the human surface for serious research work.

**Communication.** Email, Slack, chat, all human-shaped, with limited
structure. Agent communication needs typed messages, signed identity,
presence-as-protocol, threading semantics that survive handoff.

**Version control.** Git is closer to AX-native than most things: content-addressed objects, explicit operations, plumbing-vs-porcelain
separation. The pattern has not been generalized.

**Project management.** Tickets and boards are shaped for human attention.
Agent-native project state is a graph of typed work items with explicit
dependencies, costs, and ownership.

**Code editing.** IDEs are human-shaped. Agent-native code surfaces are LSP-like: symbol graphs, type information, structured diffs, change impact
analysis, without the chrome.

**File systems.** Hierarchical filesystems were a UX choice for humans.
Content-addressed object stores with typed metadata are closer to what
agents want. Most current "agent file access" is the hierarchical version
with translation layers; the native version is older but undervalued.

For each of these, the right question is not "how do we add AI features."
It is: "what is the agent-native shape of this category, designed as if the
human UI never existed, and how do we render the human view as a derivative
of it." Some answers will reveal that the human UI was the right shape and
the agent surface is a translation. Most will reveal that the human UI was
full of accidental complexity, and the agent surface is much smaller,
cleaner, and more powerful.

---

## 7. Measurement

UX measurement collapsed into proxies: engagement, conversion,
time-on-page, that became the goals and corrupted everything they touched.
AX is going to face the same temptation. The proxies will be tokens
consumed, tasks completed, tool calls per task. Each is wrong in its own
way: tokens-consumed punishes thoroughness, tasks-completed punishes
quality, tool-calls-per-task punishes appropriate caution.

Better metrics for AX are harder to game because they require the agent to
actually do something well, not just do something:

- **Time-to-correct-first-output.** How long until the agent produces
  something the human consumer accepts without revision?
- **Recovery rate from misroute.** When the agent goes wrong, how often
  does the system route it back without human intervention?
- **Identity coherence across handoffs.** When work passes between agents
  or sessions, is the task still the same task afterwards?
- **Cost predictability.** Does the agent's actual cost match its
  predicted cost? When it doesn't, why?
- **Manifest sufficiency.** Can a fresh agent reach competence on the
  system using only the manifest, with no out-of-band guidance?

A first instrument exists for the *arrival layer*: a surface-only audit
fetched without JavaScript, scored across a small fixed rubric (entry point,
root readability, structural integrity, declared intent, identity rules,
contact path, substrate coherence). It is enough to distinguish a site that
ships agent primitives from one that only talks about them, and to catch the
SPA-200 anti-pattern an inline test would miss. The method is early, scoped
to a small cohort, and worth treating as a beachhead rather than a settled
discipline.

The *navigation and action layers* — multi-hop traversal, schema-versus-runtime
fidelity, recovery from a misroute, idempotency under retry — remain unbuilt.
That is the next layer of the measurement discipline, and the one most likely
to be replaced by bad proxies if it is deferred. Worth resisting the deferral.

---

## 8. What AX is not

To keep the discipline honest, explicit anti-claims:

**AX is not a successor to UX.** Both disciplines are valid for their
respective substrates. The relationship is not replacement; it is
differentiation. A mature designer should hold both.

**AX is not a license for autonomy theater.** Calling something
"agent-native" does not make it good. Many supposedly agent-native systems
are AX-flavored UX with a chatbot on top. The discipline only earns its
name when the design decisions actually trace back to substrate facts. The
modal failure in the wild is not bad AX; it is *empty* AX, sites that talk
about agents in their copy and ship zero primitives, no manifest, no
typed contact path, no agent-aware identity rules. Aspiration without
infrastructure is the most common pattern, not the corner case.

**AX is not a position on AGI or autonomous-everything.** The discipline
applies regardless of whether the agent is doing a 30-minute task or a
fully autonomous system running for weeks. It is about interface design,
not about the long-term shape of agency. People who build AX-native
systems should still hold strong views about agent oversight, safety, and
where humans must remain in the loop.

**AX is not a single design language.** Different agents have different
substrates. A 7B local model and a frontier model have different working
memory profiles. AX done well calibrates to the actual user, not to a
generic "agent" persona.

**AX is not against humans.** The most common misreading. AX makes systems
better for humans too, because it forces explicit semantics, structured
errors, cost transparency, and clean state, all of which are also better
for human operators of complex systems. The discipline works in
*addition* to UX, not against it.

---

## 9. Trajectory

Three things have to be true for AX to land as a discipline rather than
dissipate as vocabulary.

**Existence proofs.** Real systems built AX-first that demonstrably
outperform UX-first systems with bolted-on agents. MCP is an early
infrastructure-level instance. The next two years should produce more
examples at the application layer: products where agent context, memory,
state, handoff, recovery, and permissions are designed as first-class
interfaces rather than hidden implementation details. The piece writers
need to pay attention to is not the marketing; it is the system
architecture. AX is visible in the shape of the schemas, not in the press
release.

**Derivation pressure.** Designers and engineers reading AX work should be
able to derive the principles from the substrate themselves. If the
principles read as arbitrary heuristics, the discipline is failing. If they
read as obvious-once-stated implications of the user's actual cognitive
shape, the discipline is succeeding.

**Cross-pollination with adjacent fields.** Distributed systems already has
most of the primitives AX needs (idempotency, content-addressing, signed
events, eventual consistency). HCI has decades of measurement discipline
that AX should inherit critically. Cognitive science and embodied cognition
have substrate-level vocabulary that AX can borrow. The discipline matures
fastest when it is permeable to its neighbors.

The bridge era, agents driving human systems through screen-reading, will
continue for years. That is fine. Bridges have a real role. The work that
justifies tearing them down eventually is the AX-native infrastructure
being built underneath, in parallel. The bridge gets dismantled when there
is somewhere to walk to. The job of the discipline named in this document
is to make sure that destination exists.

## 10. Open questions

These are not rhetorical. They are claims this document does not yet make
well, and that future drafts should sharpen.

**How thin can a manifest be before it becomes useless?** The bias of this
document is toward complete manifests. But context cost is real, and
sometimes a smaller manifest with explicit pointers to expanded sections is
better than a single fat document. The right shape probably depends on the
agent's working memory profile, which varies by model.

**When is dual-mode honest, and when is it cover for under-investment?**
Saying "we have both an agent surface and a human surface" is easy. Building
both well is hard. The failure mode is pretending the human UI is the
"real" interface and the agent surface is a thin wrapper. One bar is now
clear: dual-mode without crosswalks between the surfaces (§5) and without
honest 404s on unknown paths (P3) is under-investment, not architecture.
The harder test — whether the two surfaces stay semantically synchronized
as the system evolves — remains open. A drift detector that asks "do both
views agree about state, version, and capability?" is the natural next
instrument.

**How does AX interact with adversarial agents?** This document assumes
cooperative agents with cooperative system designers. The discipline as
described would be exploited by adversarial agents: typed errors with
recovery hints are also reconnaissance for attackers. AX hardening against
adversarial use is a real problem and not yet addressed here.

**What is the right unit of measurement for "manifest sufficiency"?**
Section 7 names the metric. The arrival layer is operationalized: a
surface-only fetch scored across seven dimensions, median-aggregated across
independent agents. The action layer is not: "can a fresh agent complete
task X using only the manifest?" still fails when the task requires implicit
world knowledge, or when the schema declares a capability the runtime no
longer fulfils. Manifest sufficiency is better treated as a partial order
across layers (discovery, declaration, navigation, action, recovery) than as
a single pass/fail score.

**Where does AX shade into agent training?** Some of what looks like AX
design is actually "training agents to handle worse interfaces better."
The line between fixing the interface and fixing the agent is often
ambiguous. A discipline that doesn't distinguish them clearly will
collapse into "make the model better and call it AX."

*This document is a draft. The principles will sharpen with examples. The
diagnosis will sharpen with critique. The categories will sharpen as more
AX-native systems get built. If you read it and disagree with a specific
claim, the discipline is better off for the disagreement than for the
silence.*