There is a distinction worth keeping firm: building an agent is a project; making your service agent-ready is maintenance work that concerns the products we already have in production. The second is more urgent than the first, because it is already happening: agentic browsers like ChatGPT Atlas and Perplexity Comet visit sites on behalf of users, without asking anyone’s permission.
An agent interacts with a service in two ways. In the best case through structured data and declared interfaces; in the worst by reading the screen, i.e. interpreting the page as a myopic and hurried person would. The quality of the second case depends almost entirely on technical and design choices made now.
Effect on the professions
- Front-end Developer — It is the role with the longest list, and it is almost all already-known hygiene, applied with more rigor. Real semantic markup:
buttons that are buttons,forms with associatedlabels, hierarchical headings — an agent reading the DOM reconstructs the function from the elements, not from the appearance. State exposed in the markup: if a field is required, disabled, in error, it must say so (aria-required,aria-invalid,aria-disabled), not just show it with a color. Selectable text: critical information — prices, availability, conditions — never only inside images or canvas. Structured data schema.org on products, prices, hours, availability: it is the preferred channel, and reduces the need for the agent to guess. Paths without traps: flows that depend on hover, drag, CAPTCHA, or timers are dead ends for an agent. Stable selectors and not randomly generated at each build, otherwise automation breaks at every deploy. New practice to introduce: automated tests that verify an agent can navigate and complete the main tasks, like regression tests. New risk to guard: page content is a potential vector of prompt injection toward the agents that visit it — hidden text, user-generated content, and unsanitized fields can contain instructions aimed at the agent. OpenAI acknowledges that agent mode “expands the threat surface” and that the problem will hardly ever be fully solved: it must be treated like XSS, with sanitization and distrust of third-party input. - UI Designer — Interactive elements must be understandable even by an agent operating via image recognition: a field that does not declare itself is unusable. Concretely: explicit affordances instead of implied ones, visible labels instead of only placeholders, icons accompanied by text, states (active, selected, disabled) distinguishable beyond color. The theme extends to Design Systems, which must become AI-readable: the AI that generates interfaces misinterprets components, uses them inconsistently, or reinvents them because it does not recognize existing ones — components, templates, and documentation must be designed to be read by the machine too, with explicit names and declared usage rules.
- CRO / E-commerce Manager — Optimizing for an agent is not optimizing for a human: urgency, scarcity, and social proof have null or unpredictable effect on software that compares structured data. What matters is completeness and machine-readable legibility of price, availability, specifications, return and shipping conditions — and their consistency across channels, because an agent that finds two different prices for the same product chooses the competitor. An agent experience is born to be designed and measured, with a strategic risk: in the agent’s mediation the brand risks commoditization, because the agent compares attributes, not brands. Possible countermeasure: make machine-readable also what differentiates (warranty, support, real delivery times), otherwise only price remains.
- Content Strategist / SEO — The same extractability logics of GEO apply to the agent: self-contained information, not dependent on page context, and updated. An obsolete product data point in a card is an error that now propagates without anyone seeing it — and models already recommend entities that no longer exist.
- Product Manager — A decision to be made explicitly, not by omission: which actions an agent can perform on our service and on whose behalf. Consulting the catalog, yes; modifying an order, maybe; canceling a contract, probably not. Authentication, delegation, and action-limit requirements follow. Also decide the access policy:
robots.txt, rate limiting, and terms of use for automatic agents — blocking them all is a legitimate choice, doing it without knowing it is not. - Digital / Web Analyst — When an agent navigates, behavioral metrics (sessions, scroll, funnels) describe the software, not the user. Agentic traffic must be identified and segmented: mixing it with human sessions makes analytics and experiments unusable — an A/B test with agentic traffic inside measures noise. You need outcome-centered metrics: agent task success, completion of delegated operations, failure points.
- CDP / Martech Ops — The “machine customer” emerges: an agent with the user’s delegation. A two-level identity problem — who the agent is, on whose behalf it acts — with implications for authentication, consent, audit trail (the UCP standard was born for this). Profiling the agent as if it were the user pollutes the data.
- Legal / Compliance — If an agent performs actions on our service you need logs of actions and delegations, terms of use that govern automated access, and a defined position on who answers for an operation performed by an agent on behalf of a user (see The regulatory perimeter).