How to Choose the Best Agent Experience (AX) Agency

What an Agent Experience team does for product success

UX teams existed to understand how people interact with a product and to make that interaction better. They read user psychology, behavioural patterns and market dynamics. That role has not disappeared. It has widened, because your product now has two users.

The first user is a person: they look at the screen, scroll, hesitate, click. The second user is an AI agent: ChatGPT, Claude, Perplexity and Gemini read your site, compare your product against rivals, fill in your form and decide whether to recommend you. Agent-driven request volume has grown sharply over the past year, and in B2B a meaningful share of purchase research now runs straight through an assistant.

Agent Experience (AX) is the design of how easily, safely and reliably an AI agent can use a website, a piece of software or an API. It is built in four layers: the agent being able to find you (access), understand you correctly (context), act on your behalf (tools) and finish a multi-step job end to end (orchestration).

A good AX team, like a good UX team, is not merely a design supplier. It is a strategic partner that unlocks your product's potential in the agent era. The difference: it looks not only through human eyes but through the machine's reading logic. A product page with incomplete schema looks flawless to a person and reads as a product with no clear price to an agent. A team that can see that gap prevents wasted investment and lost time.

In-house team or outside support?

In the UX era the question was "do we hire a designer or work with an outside team". In the AX era it is harder, because one specialism is no longer enough.

An in-house team knows the product and the data intimately, sits inside the process and can focus on long-term improvement. But Agent Experience is not a load one person can carry. You need a front-end engineer fluent in structured data and semantic HTML, a back-end developer who can stand up an API and an MCP server, an analyst who can measure visibility inside AI search, a UX researcher to design human-agent interfaces, and someone to set the security and governance frame. Building that team from scratch takes months, and the field moves fast: agent protocols (MCP, WebMCP, AP2, ACP) update quarterly.

An outside team arrives multi-disciplinary. It carries the pattern knowledge that comes from seeing the same problems across dozens of sites: which firewall rule silently blocks which bot, which schema error leads to invisibility, which llms.txt structure lowers agent success. It brings the measurement stack and the tooling, so you do not pay for licences and trials.

In practice the best model is hybrid: the outside team runs the first audit, sets the roadmap, manages the first 90 days of change and keeps measuring; the in-house team takes over implementation and upkeep. A good partner leaves you capability, not dependency.

How to tell an experienced AX team apart

The number of providers using the words "AI visibility", "GEO" and "agentic" grew fast. A few concrete tests separate the capable from the average.

Does it measure through the agent's eyes?

The AX equivalent of "do you run user testing" is "do you run agent task simulations". A good team runs defined tasks on your site with real agents, records the step at which the agent breaks off, and reports it as a score from 0 to 100. A team that says "we will make your site AI friendly" but cannot say how it measures that is working on intuition.

Does the portfolio show outcomes or only deliverables?

In a UX portfolio you look for a lift in conversion. In an AX portfolio look for these: a rise in citation share inside AI answers, agent task completion rate, a measured increase in agent-readiness score, autonomous resolution rate. "We added llms.txt and placed 200 schemas" is a delivery list, not an outcome.

Is there technical depth?

Ask these three questions and judge how clear the answers are. How do you connect schema to the visible HTML? The right answer: schema alone is not enough, most AI crawlers read the visible copy. How do you write llms.txt? The right answer: short, by hand, verified; bloated files lower agent success. How do you set authorisation on an MCP server? The right answer: zero trust, hard limits, human approval points. Walk away from a team that answers these three in marketing language.

Is the methodology transparent?

An experienced team explains its order: access first, then readability, then data, then visibility, then protocol, then transaction, then measurement. Investment that skips that order is wasted; a flawless MCP server on a bot-blocked site reaches nobody. A team that never explains the chain and jumps straight to "you will rank first in AI" does not know the order.

Is the team composition right?

In UX you looked at the balance of researcher, designer and product strategist. In AX at least two people join them: an engineer fluent in structured data and semantic HTML, and a developer who builds the API and protocol side. If the team is only content and design people, the access and tool layers cannot be built.

Is their own site ready for agents?

The simplest test. Scan the team's own site with an agent-readiness tool. A team whose robots.txt blocks agent bots, that has no llms.txt and whose schema is broken cannot deliver this service to you.

Red flags to avoid

This field is new and unregulated; the quality standards that formed over years in UX have not settled yet. Take note if any of these appear.

• A promise of guaranteed AI ranking. Appearing in an AI answer is not a deterministic ranking but a probabilistic selection. Nobody can guarantee it.
• Selling a single file as the magic fix. llms.txt helps but is not sufficient on its own; some agents read it, others do not.
• Starting implementation without proposing measurement. A project with no baseline cannot prove success.
• Piling on schema. Adding dozens of unrelated schemas brings no visibility; entity consistency does.
• Focusing on one engine. Source overlap between AI engines is low; a team optimising for a single assistant misses the rest.
• Proposing dark patterns as conversion optimisation. Fake urgency and shaming buttons irritate people and stop agents.
• Never discussing governance. A team that proposes no human approval point, no GDPR frame and no audit trail for agent transactions involving money or personal data is leaving the risk with you.
• Hours in the contract, no milestones. Ask for verifiable checkpoints such as "feed validated" or "access score above 80".

The AX brief: the base of a solid engagement

After choosing the right team, the most important step is a good brief. The spine of a UX brief (problem, goal, scope, product knowledge, success criteria, budget and timing) stays exactly as it was; items specific to the agent era are added on top.

Definition of the problem. Not only "where do users struggle" but "where do agents break off". Write what you know: "ChatGPT quotes our price wrong", "Perplexity never cites us", "agents cannot complete our quote form".

Current agent-readiness state. Scan your site with a free tool before the brief and put the score in it. The team spends no time on discovery from zero, and you know every proposal comes off the same baseline.

Target agents and use cases. Which agents do you want using you? Shopping assistants, B2B purchasing agents, customer service agents? Write two or three concrete tasks you want an agent to finish on your site: "find, compare, add to basket", "get a corporate quote", "book an appointment".

Technical inventory. Do you have an API, is it documented? What is the render architecture? Do you have a product feed, is it current? Which CMS and which firewall? Without this the access and tool layer cannot be planned.

Data and permission limits. Which data an agent may reach, which action it may take alone, where a human must approve. The GDPR frame. This is the most skipped line in a brief and the most expensive one to skip.

Success criteria. In new-generation metrics: citation share in AI answers, agent-readiness score, agent task completion rate, autonomous resolution rate. The classic metrics stay; the two are read together.

Transparency of internal process matters as much as it did in the UX era: who the team talks to, who may touch critical files such as robots.txt and the firewall, who signs off. A fix in the access layer usually depends on IT opening a rule; if that person is not in the brief, the project stalls in week one.

Core qualities an AX team needs

The qualities we used to list for a UX designer (empathy, research and analysis, communication, problem solving) still hold. Five competencies join them in an AX team.

Understanding machine reading logic. Knowing how an agent sees the page: the accessibility tree, DOM order, semantic HTML, structured data. For a designer this is a new kind of empathy.

Context engineering. Presenting agents with correct, sufficient information and no noise. llms.txt, AGENTS.md and documentation design. The discipline of writing little but right.

Protocol literacy. Following standards such as MCP, WebMCP, AP2 and ACP, and being able to say which of them matters for you today. Not proposing all of them, but choosing the right one.

Designing trust and control. In flows where a person and an agent share the same interface, designing control, transparency, reversibility and approval points. Microsoft's Human-AI Interaction guidelines and the HAX toolkit are the foundational references here.

Measurement and honesty. Being able to say that part of AI traffic is invisible to any setup, that most industry statistics come from a single source, and that the only valid proof is your own baseline. A team that gives you the accurate news rather than the good news.

Communication matters more here than it used to. An AX project bridges marketing, product, engineering, IT and legal. A team that cannot explain the same thing clearly at all of those tables cannot carry the project.

What the right AX partnership adds

A well-chosen AX partner is not a project supplier but a long-term growth partner. The difference is that it opens a new growth channel.

With the right partner your brand is found and cited correctly in AI answers; agents transact with you reliably on your customer's behalf; your customer sees and controls what the agent did. Fixes in the access, schema and data layers help not only agents but accessibility and classic search visibility too; one investment feeds three channels.

The partner also carries agent-first thinking into your culture: the product team starts asking "can an agent read this" when it opens a new page. Once that question lands, redesign costs fall and every new feature is born agent-ready. We covered the smallest-scale version of the same discipline in our CTA button article.

Timing may matter most. In a period when AI agents are reshaping the web, the large majority of brands are still invisible or merely readable. A brand that moves early with the right partner gains a structural advantage in a low-competition window. By the time your competitors start reading this page, you are already measuring.

In fairness: Webtures also offers Agent Experience work. Apply the tests above to us as well. Scan our site, look for outcomes in our portfolio, ask us the three technical questions. The decision is yours.