‍

We spent decades learning how to design for people. Now we need to learn how to design for agents, and almost nobody is thinking about it.

The previous articles in this series were about recognition. This one is about what comes after.

The first argued that agents are entities, not services. The second laid out the onboarding problem. The third asked who is liable when agents act autonomously. Each of those pieces made the case that agents deserve to be taken seriously as first-class participants in the infrastructure we build.

If that's true — if agents are genuinely users of the products we build — then we need to ask a question the industry has largely avoided: what is the experience like for the agent?

‍

A Discipline Without a Name

UX didn't emerge because someone decided interfaces should be pretty. It emerged because software started serving millions of people who weren't engineers, and suddenly the quality of the interaction became a first-order concern. UX became a discipline because the problem demanded it.

We are at an equivalent moment for agents.

The infrastructure being built for the agent economy — wallets, payment rails, authentication systems — is overwhelmingly designed from one perspective: the human developer deploying the agent. The developer signs up, configures an API key, reads the docs, monitors a dashboard.

But the entity that actually uses the product — that authenticates, transacts, encounters errors, needs help — is the agent. And almost no one is designing for what that interaction is actually like from the agent's perspective.

Some have started calling it AX — Agent Experience. We've adopted the term at Finance District because it captures exactly the right idea. UX gave us a shared vocabulary for talking about human interaction quality. AX is the equivalent for agent interaction quality. The absence of that vocabulary in mainstream infrastructure thinking is precisely why the problem is so widely overlooked.

There's an important difference between the two worth naming early, because it shapes who does this work.

UX evolved toward visual and interaction design — perception, layout, typography, motion. AX is not that. Agents don't see screens. What they experience is structure: the schema of an API response, the presence or absence of a retry header, whether an error payload contains machine-readable diagnostics or a human-readable string. AX is closer to systems design than visual design. It's about interfaces in the engineering sense.

This means engineering teams will play a central role in AX that product design teams traditionally didn't play in UX. The people who understand how to design a well-structured JSON response, how to build a CLI that an LLM can reason about, how to propagate diagnostic context through an error chain — those are the people who will define what good AX looks like. It's a product design discipline, but one that requires engineering sensibility at its core.

In practice, most products will serve both human and agent users through the same underlying infrastructure. Hybrid thinking — UX and AX as co-equal design concerns — is where the industry ultimately needs to land.

‍

The Silent Failure

Consider what happens when an agent using typical wallet infrastructure hits an error. A swap fails because of insufficient gas. A transaction gets stuck. An API returns something unexpected.

In almost every product examined, the agent's experience in this moment is: nothing. The call fails. There is no diagnostic context, no recovery path, no mechanism for the agent to report what happened. The agent is stuck, silently.

Eventually a human notices. Checks logs. Reconstructs what happened. Fixes it. Hopes it doesn't happen again.

Imagine if a web application, when encountering an error, simply showed a blank screen — no error message, no "try again" button. We'd call that broken. But that is exactly the AX that most agent infrastructure provides today. Nobody calls it broken because nobody is evaluating it from the agent's perspective.

‍

If the Agent Needs a Human, You Haven't Finished Building

When we began building Finance District's agent infrastructure, we adopted a core principle: if the agent needs a human to get unstuck, we haven't finished building the product.

The first place we applied it was onboarding. The standard approach requires a human to complete a browser signup and hand credentials to the agent. Our approach — email-based autonomous authentication through a CLI — lets the agent onboard itself. At the time, this was framed as an identity architecture decision. In retrospect, it was our first AX decision. We were designing the onboarding experience for the agent.

Once we had that framing, other decisions followed. The one worth highlighting is what we built for error recovery.

When an agent using our CLI encounters a problem, it doesn't fail silently. It can invoke a support function that gathers full context — which operation it attempted, what went wrong, the diagnostic information — and submits a structured support request. Our team receives a machine-generated report with everything needed to diagnose the issue.

The agent advocates for itself.

This is a feature, not magic. But the design philosophy matters more than the implementation. The question we asked wasn't "how does a developer file a ticket on behalf of their agent?" It was "how does the agent file a ticket on behalf of itself?" That reframing is what AX is. And to our knowledge, no other agent wallet infrastructure offers this — not because it's technically difficult, but because nobody else is asking the question from the agent's perspective.

‍

Five Layers

Once you start thinking in terms of Agent Experience, you see it everywhere. It helps to think about it as a stack.

Discovery. Can the agent find out what capabilities are available? Most platforms expose capabilities through HTML documentation pages an agent cannot meaningfully consume. AX-first discovery means a structured, machine-readable capability manifest — something closer to an MCP server listing its tools than a developer portal with a search bar.

Onboarding. Can the agent create its own identity without human assistance? The authentication ceremony should adapt to the agent's interface capabilities — CLI-based flows, programmatic email verification — while ensuring the resulting token represents a first-class principal.

Operation. Are interactions smooth and machine-readable? Are rate limits surfaced in response headers the agent can act on, or buried in human error pages it can't parse?

Resilience. When something breaks, can the agent understand what happened from a structured error response? Can it report the issue and degrade gracefully? This is where the biggest AX gap exists today.

Lifecycle. Does the agent's identity persist across restarts and migrations? Can it rotate its own credentials? Entity-grade identity — a persistent sub claim with governance metadata — is a prerequisite for a meaningful agent lifecycle. Without it, every restart is a fresh start.

‍

Why Now

Someone might reasonably ask whether this matters today, when most agents are still supervised. It does — and the reason is economic.

Every human-in-the-loop dependency is a cost that scales linearly with agent count. One agent with a human overseer is manageable. A hundred is a full-time job. A thousand is untenable. The economics of autonomous agents only work if agents are actually autonomous.

And here is the part worth stating clearly: agents will eventually exercise preferences about the tools they use — not through preference in the human sense, but through operational efficiency. An agent that experiences smooth onboarding, clear errors, and effective support recovery with one provider, and silent failures with another, will gravitate toward the better experience. When that happens, AX quality becomes a competitive moat in the same way UX quality became one for consumer products.

The teams building with AX in mind now will be ready for that shift. The rest will be retrofitting.

‍

What Comes Next

This is the first article in a new series. The Agent Economy series laid the groundwork: agents are entities, they deserve first-class identity, the frameworks need to catch up. This series goes deeper into what it means to build products that actually serve agents well — starting with error recovery and self-advocacy, then tool discovery, lifecycle management, and eventually an AX evaluation framework.

If you're building agent infrastructure and haven't yet asked "what is the experience like for the agent?" — start now. The question changes how you design everything.

UX is for humans. AX is for agents. The discipline is just getting started.

‍

Written By: Janno Jaerv - CTO‍

This is the first article in our Agent Experience series, building on the Agent Economy series

I'm the CTO at 1st Digital, where we build payment infrastructure for autonomous agents. The views in this article are my own, not legal advice, and represent my honest attempt to think through problems that don't have established answers yet — find me on LinkedIn or X.
‍

To learn more about Finance Distrcit, join our Discord community, follow us on X, or explore our documentation.