In the first part of this series, the point was simple: AI agents are now a second kind of visitor, and they tolerate ambiguity far less than people do. That idea holds up. But it understates what's actually changing.
When a human struggles with your interface, you lose a conversion. When an agent struggles with it, it fails a task on someone else's behalf, often without telling them why. The interface stops behaving like a surface people read and starts behaving like infrastructure something else depends on. Infrastructure has a different standard than décor. It needs to behave the same way every time, fail in predictable ways, and never require the thing using it to guess.
Most B2B websites were never built to that standard, because they never had to be.
For a CEO, the stakes here aren't UX nitpicks. A form an agent can't fill in correctly, a price it can't quote with confidence, is one more place where you get quietly dropped from a shortlist before anyone on the buying side ever opens your site themselves. What follows isn't a developer backlog. It's a short list of decisions that affect whether you get considered at all.
Forms are now an interaction protocol
A form used to be something a person filled in, got wrong, and fixed by looking at what turned red. An agent filling in the same form needs to know, before submitting, what each field expects, which fields are required, and what a valid value looks like. Not approximately. Exactly.
“Company” is ambiguous: legal name, trading name, or domain? “Phone” is ambiguous without a note on expected format. A field that silently truncates after 50 characters, or that accepts input and rejects it only on submit, gives a person a visible interactive cue and gives an agent a trip back through the process. The label and the constraint can't live only in a placeholder that disappears the moment someone starts typing.
This isn't a call to over-engineer every input. It's a call to put the constraint where it's still visible when something goes to use it.
Error and success states have to say what happened
A red border communicates “something is wrong” to a person who can then scan the form for a tooltip, a colour change, an asterisk. It communicates almost nothing to an agent, which needs the specific reason, ideally tied to the specific field, in text.
The same goes in reverse. A success state that's a toast notification fading out after two seconds, or a checkmark animation, is a confirmation only to a visitor who was watching the screen at that moment. “Your request has been received, reference #4471” is a confirmation whether or not anyone is watching the screen at all. This was always better design. It's also now the only way an agent can report back accurately on whether the task it was asked to do actually succeeded.
Pricing pages are where comparison happens
Part one touched on this: a price without its conditions is misleading, not just for people. The sharper point is that pricing is usually where an agent is directly comparing you to competitors, and inconsistency here has a cost that other pages don't carry in the same way.
If “Starter,” “Growth” and “Enterprise” don't map cleanly to what's actually included in each, if a feature's presence is marked only by an icon with no text alternative, if “custom pricing” hides a number that matters to the decision, the agent either reports something wrong or reports nothing useful at all. Either way, you've likely been filtered out of the comparison before a human ever saw your name.
Relationships between pieces of information need to be explicit
This is where accessibility and agent usability turn out to be close to the same problem. A screen reader user and an agent both need the association between a label and its input, a price and its condition, a claim and its source, stated in the markup or the text, not just implied by position on the page.
A table where a feature's availability is shown only by a green dot in a column. A condition placed in a tooltip that only appears on hover. A disclaimer in a footnote with no visible link back to the number it modifies. These all fail the same test: can the relationship survive being pulled out of its visual context? If not, both your accessibility audit and your agent-readiness happen to point at the same fix.
Descriptive, predictable interaction
A button's label should say what pressing it does. A link's label should say where it goes. This was already the rule in part one for navigation. It applies with more force to interactive elements that trigger something, submit a form, start a checkout, confirm a cancellation, because the cost of an agent getting this wrong isn't a wrong page. It's a wrong action, possibly one that can't be undone.
Predictability matters just as much. If clicking “Save” sometimes opens a modal and sometimes submits immediately depending on an earlier, unrelated choice, a person adapts after the first surprise. An agent has no way to detect that the behaviour changed until the outcome is already wrong.
Agents see your mobile site too
Many agents operate against the same responsive layout a phone gets, not a separate desktop view. A menu that only opens through a hover state, content that only exists behind a swipe gesture with no equivalent link, a form that works on desktop but collapses two fields into one unlabelled input on mobile: these are usability bugs today, and they are also places where an agent's access to your site depends on which layout it happens to render.
This isn't an argument for a special “agent mode.” It's a reminder that whatever gap already exists between your desktop and mobile experience is a gap agents inherit too.
Working, but operationally uncertain
There's a useful distinction between a page that's technically functional and one that's operationally reliable. A dropdown that requires a specific click sequence, works, technically. A multi-step process where step three only appears after an animation finishes, works, technically. A CAPTCHA that gates the one form you want an agent to help someone complete, works exactly as intended, for a person.
None of these are bugs in the traditional sense. They're places where the interface quietly assumes a human is the one operating it, in no hurry, watching the screen, able to tell when something has loaded. An agent completing the same flow on someone's behalf doesn't get the benefit of that assumption, and whether it fails depends on details you likely never tested for because no person ever noticed them.
Brand personality doesn't have to disappear
None of this is an argument for stripping out tone, humour, or visual identity. A pricing page can still sound like you. A confirmation message can still be warm instead of clinical. The distinction that matters is between personality in the delivery and ambiguity in the meaning.
“You're all set!” is fine as a success message, as long as it's paired with what was actually confirmed and what happens next. A playful error message is fine, as long as it still names the field and the fix. Agents don't need your copy to be boring. They need the information underneath the copy to still be there.
A practical starting point
You don't need to personally check a form field or read an error message in dev tools. What you need is five minutes to ask someone on your team, or an outside pair of eyes, to check five things this week:
- Pick your three most important forms. Check whether every field's expected format and requirement status is stated in visible text, not placeholder-only.
- Check what your error and success messages say when read as plain text, with no colour, icon or animation attached.
- Open your pricing page and copy every number and its conditions into a plain document. See if it still makes sense and still matches what you intended to say.
- Check one interactive element that triggers a real action (submit, confirm, cancel) and confirm its label states the outcome, not just the gesture.
- Open your site on a phone and repeat the first four checks there, separately.
What this turns up usually isn't new information. It's confirmation of things a redesign backlog already suspected, just without a reason urgent enough to prioritise them. An agent visiting your site for the first time is that reason.
The third part of this series looks at what changes when trust itself needs to be stated outright, not implied visually, and what that means for how B2B companies write about their own expertise.
Not sure whether your forms, errors and pricing pages would hold up to this test? Our CRO, customer journey and digital experience audits find exactly these gaps, and fix them.