For years, software teams have invested heavily in UX: the experience people have when they use a product. As AI agents begin using those same products through tools and APIs, we need to pay equal attention to another interface. At Neurosnap, we call it AX: Agent Experience.
I’m the founder and CEO of Neurosnap, a platform that makes advances in drug discovery, molecular biology, and chemistry accessible to researchers. Over the past several months, we’ve been rolling out our MCP server to clients around the world, including top pharmaceutical companies and Fortune 500 organizations working across life sciences, agriculture, and materials science.
That work has taught us something simple: giving an agent access to a tool does not mean it knows how to use that tool well.
Neurosnap presents an unusually demanding environment. Agents may need to navigate hundreds of tools, thousands of settings, saved jobs, input files, generated results, and relationships between them. A good human interface helps researchers find their way through that complexity. Agents need comparable guidance, delivered through tool descriptions, schemas, examples, responses, and errors.
Here are eight lessons we’ve learned so far.
1. Start with a map, not the whole territory
An agent needs to understand the major concepts of a platform before it can use individual tools effectively. What is a job? How are results retrieved? Which actions can consume credits? A short orientation at the start of an agent’s context can answer those questions.
That orientation should remain short. Sending every tool description and every setting up front makes the useful information harder to find and raises token costs. We’ve had better results giving agents a small set of starting instructions and a way to discover more detail when the task calls for it.
2. Make discovery task driven
A human can browse a menu, scan categories, and open a form. An agent benefits from a similarly gradual path: find the relevant capability, inspect its specification, then use it.
This matters when a platform has many related tools. An agent asked to review past results should be led toward listing jobs, reading their details, and retrieving their files. It should not have to infer that workflow from a flat catalog dominated by submission tools.
The goal is to make the next useful action obvious without hiding the broader platform.
3. Describe the contract, not just the action
“Submit a job” is a description of an action. It is not enough information to perform it reliably.
An agent also needs to know which inputs are required, which are optional, what defaults apply, what limits are enforced, and how files must be supplied. Examples are especially valuable when an input has a shape that is easy to misunderstand. We’ve seen agents understand the scientific request yet stumble over the mechanics of attaching a file or configuring a more advanced workflow.
Good AX puts those constraints close to the tool. It gives the agent the same practical information a researcher would get from a well-designed form and its documentation.
4. Give consequential actions a rehearsal
Agents can experiment with a search or a file listing at little cost. A job submission is different: it can start real work and consume credits.
For consequential actions, a validation step helps the agent check the complete request before committing. It can catch missing inputs and incompatible settings without creating a partial or diagnostic job. The agent should also be told what a successful submission returns, including the job ID it must report back to the user.
This is an AX principle with a direct UX benefit: fewer surprise charges and clearer outcomes.
5. Treat retrieval as a first-class capability
Early tool sets often make creation easier than inspection. An agent may be able to submit a job but struggle to retrieve the resulting files. That becomes obvious when a user asks it to compare two completed runs: filenames alone cannot support a structural comparison.
Listing, reading, and downloading results deserve the same design attention as submission. An agent needs reliable access to the underlying data and clear guidance on when it should inspect that data before making a claim.
6. Make errors useful without exposing internals
An error that says only “something failed” leaves an agent unable to correct its next attempt. An error that exposes internal implementation details is no better for the user.
The useful middle ground is a safe, specific explanation: which input was rejected, what constraint it violated, and whether any action actually took place. For a failed submission, “no job ID was returned” is a consequential fact. Preserving that fact lets the agent respond honestly and decide whether a retry is appropriate.
7. Separate durable files from a temporary workspace
An agent’s working environment is temporary; a user’s files and results need to remain accessible. This distinction is easy to lose when an agent writes a report and includes its internal file path in a response. That path may work inside the agent’s workspace but fail for the person reading the answer.
We’ve learned to treat published files as product artifacts with user-accessible links and viewers. We’ve also learned not to load every saved file into every new agent session. A focused set of relevant files, plus a catalog the agent can search, gives it the material it needs without overwhelming its workspace.
8. Measure whether the task was completed
A successful tool call is not the same as a successful user outcome. Did the agent retrieve the files it needed? Did it submit the requested configuration rather than a partial one? Did it report the correct job ID? Did it distinguish a completed computation from a scientifically convincing result?
Those are the questions we use when reviewing agent behavior. Each failure points to a possible improvement in the interface: a missing retrieval tool, an unclear constraint, a weak example, or an error that did not provide enough information to recover.
AX and UX belong together
AX is not a replacement for UX. It is the design of the path an agent takes through a product on a user’s behalf. When that path is clear, the human experience improves too: actions are more reliable, costs are more predictable, and results are easier to verify.
As agents become a common way to use scientific software, I expect teams to review tool catalogs, schemas, examples, and error messages with the same care they give pages and forms. The interface may be different, but the design question is familiar: can the person—or agent—understand what to do next and trust what happened?
