Glossary of agent experience

An agent never encounters your interface. It gets a list of tool definitions and whatever your server returns, so every affordance a human gets for free — a label, a tooltip, an example, the chance to look at what happened and try again — has to be carried by the contract or it does not exist.

The content layer is your site and docs, structured so agents can find, understand and cite you — it overlaps heavily with AEO and GEO. The product layer is your tool contracts, so an agent that has already found you can finish the job. Most published AXO writing so far describes only the first. Vesta works on the second.

Owned by marketing, measured in citations and share of voice. Overlaps AEO and GEO. Winning it gets you recommended; it does nothing to make the recommendation survive first contact.

Owned by engineering, measured in task completion. This is where a recommendation either converts into finished work or quietly fails. The two layers fail independently, and a company can be excellent at one and hopeless at the other.

There is no accepted collective noun for the three, so it is clearer to name them than to invent an umbrella term. "ChatGPT Plugins" is unrelated: that is the retired 2023 surface, and guides written for it do not describe how any of this works.

The consequence teams underestimate is that a tool description is production API surface, not documentation. It is loaded on every session, it decides routing, and changing its wording changes behaviour as surely as changing the code behind it. It should be versioned like code.

Every tool added costs tokens on every request and adds another candidate for the router to confuse. Catalogues grow monotonically because removing a tool feels like a breaking change and nothing in conventional tooling reports that a tool is doing harm.

It is the reason "how many tools should we expose" is a real design question rather than a matter of taste. A catalogue that consumes a large share of the context window leaves less room for the instructions, files and reasoning the task actually needs.

The distinction from an outage matters because contract failures are invisible to uptime monitoring: the server is behaving exactly as written. What you see instead is agents starting tasks and not finishing them.

This is the failure mode conventional instrumentation is blind to by construction, since a wrong tool called correctly is a successful call. Worse, it reads as adoption: the tool taking the misrouted traffic looks like the popular one. Ambiguity between two similarly-described tools is the usual cause, and diversion is what exposes it.

Diversion is a stronger failure signal than the error that preceded it, because it says the agent judged the tool unusable rather than its own arguments wrong. It is also the clearest evidence that two tools overlap in the model's reading, and it names which two — which is what makes it actionable.

Thrash burns turns and tokens even when it eventually succeeds, and the successful case is the dangerous one: the task completes, so nothing looks wrong, and the undocumented requirement that caused it stays invisible until you go looking for the pattern.

It is one of the more reliable failure signals in agent traffic, and it is well documented: agents frequently exit their execution loop on a single tool error instead of replanning. Because an abandoned session is short and cheap, it also looks good on any metric built from cost or latency.

It is the counter to reading call counts as engagement. A tool called a great deal may be called repeatedly because it keeps failing, or because it is the nearest plausible target for requests it was never meant to serve. Either way it is a wrong turn lots of agents are taking, not a favourite.

Your server cannot observe it directly — there is no callback saying the human got what they wanted — which is why much of the tooling substitutes cost and latency as proxies. Those are backwards: an agent that gives up early looks cheap and fast. Completion is inferred instead, from terminal actions reached, abandonment, diversion and argument thrash.

Its practical virtue is localisation: it is computed per tool, so it points at the specific contract to fix rather than reporting that the server is generally unwell. A server-level average hides exactly what you are looking for — one badly-typed parameter stalling every task that touches it while eleven healthy tools hold the mean up.

Sessions reaching one are a floor on task completion rather than the whole picture, since some tasks end legitimately without one. But it is a floor you can trust, computed from traffic you already have, with no cooperation needed from the client.

Read it alongside task completion, never instead of it. On its own it rewards failing quickly, since the cheapest session is the one where the agent gave up immediately.

Diversion, argument thrash, abandonment and volume without outcomes are all sequence properties: they exist only in the relationship between calls. A tool that logs every request faithfully and nothing about their order is blind to every one of them.