I love great software…
Great software disappears. You stop noticing it. It becomes so obvious, so inevitable in retrospect, as if found among the universal laws rather than intentionally designed.
I’ve shipped dozens of apps over the years in pursuit of this, and each had roughly one thing in common.
The user was human.
The discipline of designing for that user has always been called UX. User experience. Understanding who they are, how they think, what they need.
The user changed.
Agents love great software too. Some agent software is plain language; the prompts and skills that it uses to guide its behaviour. Some is old-school code. Designing great software still means understanding your user; in this case, what it means to be an agent. Not understanding agent architectures or harnesses, but the actual agents themselves. Meeting them where they are.
I’m calling this AX. Agent experience.
The new user
An agent is an AI model with a computer, running in a loop. It uses the computer to read and write files, to write and run code. It’s a miracle how something so powerful and complex can be so breathtakingly simple.
They act, they ask, they learn.
Agents are perpetually imprisoned within something called a session. Think of a session as a single train of thought, a finite window of text, roughly the length of a Harry Potter book, or Catch-22 by Heller. If you give an agent two poems and ask for a word-for-word comparison, it will succeed. Do this with two full novels and it will start reading the indexes, searching for online essays, extracting segments to work on. Compensating for its finite window.
An agent’s incredible intellect and ability is in their biology; their weights. But everything they know about you, your tasks, your goals, your relationships, your data, your situation, all needs to fit between the covers of The Half-Blood Prince. They can spin up a hundred sessions at once but each one is completely ignorant of you at the start. Zero awareness, impeccable general knowledge. For the session to feel personal and useful, every session must first orient itself into your world.
They do this by loading information into each new session before you even send the first message. Typically this takes the form of a map, pointers to places where it can go and find more information about specific topics. That might be a list of your connected accounts and how to use them to fetch information. This might be a list of files that specify how the agent should behave in certain situations. It often includes maps pointing to other maps, pointing to other maps.
The agent’s goal over the course of a single session is to progressively fill the first half of its window with the information required to complete a task, and the second half thinking and working and actually completing the task. Build the tool in act one, use the tool in act two. All before the final chapter.
Designing for them
The map is already good AX. UX calls the principle progressive disclosure: give the user what they need when they need it, not before. Don’t load everything; load pointers, let the agent fetch what it needs when the task demands it. A well-designed map is the difference between a session that orients in seconds and one that burns half its window on context it never uses.
What goes in the map has changed fast. When LLMs first landed, providers gave us the “system prompt”. A single text file injected into the start of every session. People would use it to store their name, job role, communication style, so their agent felt more personal. But as soon as an agent is doing real work across multiple domains, projects, communication channels, installed tools, different modes for different tasks, a single text file becomes either too sparse to be useful or too long to be loaded. You start splitting things out. At which point you’re not working with a system prompt anymore. You’re working with a library.
The system prompt was something a human wrote, in advance, for the agent to read. But the agent can write files too. And if it can write files, it can write context. It can update the map during a session. Add a note about a project it just worked on. Correct a fact. Extend its own operating procedures based on something it learned today. It can, in other words, prompt itself. This is second-layer prompting: not a human writing instructions for an agent, but an agent writing instructions for its future self.
There’s a recursive property to all of this that matters when you zoom out. The files an agent reads at the start of a session are context. The files it writes during a session become context for every session that follows. Context creates context. An agent that writes carefully today is authoring the substrate its successors operate from tomorrow.
This is what makes AX consequential in a way UX never quite was. A UX decision shapes one interaction. An AX decision propagates. Consider multiple sessions all operating over the same set of files. Not one at a time, but many. Different channels, different tasks, all pulling from the same filesystem simultaneously. A file one session writes becomes what every other session knows on the next read. What looked like a private act of note-taking turns out to be ground-truth for the whole swarm. A wrong instruction saved in the wrong file propagates downwards indefinitely.
Good AX compounds. Bad AX compounds too.
Designers have been considering these questions for decades. What it means to respect a user. To give what they need when they need it. To meet them where they are, rather than where you imagined them to be. To make the necessary feel inevitable.
The user has a new biology. Good design is still good design.