For a long time, designing a website meant organising information within an interface: navigation, pages, user journeys and interactions. That interface still matters for human visitors. But it is no longer the only way to access a company's content and services. An AI assistant can read several websites, compare offerings and deliver a summary without the user opening those pages.
This goes beyond visibility in ChatGPT. It affects how we structure information, develop functionality and select the systems used to manage content. Four distinctions are particularly useful when designing digital projects in this context.
1. Readable by an agent does not mean usable by an agent
The foundations of the web still matter when automated systems need to understand a business: accessible HTML, explicit copy, consistent links and structured data where appropriate. Key information about services and projects should not exist only inside an animation or visual interaction.
Now imagine an agent asked not only to compare three suppliers but to prepare a quote request. Identifying a service on a page and correctly submitting a project brief are very different tasks. The second requires an understanding of expected fields, validation rules, permissions and how to confirm an outcome.
A documented API can provide a reliable path for some actions, but it is not the only approach. Agents can also interact with existing forms and web interfaces. The important distinction is between reading public information and performing an action, especially one that changes data or commits a user to something.
Making content readable is the starting point. Enabling reliable action requires additional design.
2. When an agent writes code, quality criteria still matter
Development agents can now produce complete features. The result may look convincing, work in a demo and even pass the expected tests. None of that necessarily guarantees sound architecture or a correct understanding of business constraints.
Consider an integration connecting payments to user accounts. Matching them by email address may appear sufficient in early tests. But when an email address changes or records no longer match, the association becomes fragile. A stable identifier and explicit matching rules are usually a better choice. This is not a syntax error; it is a design decision.
Agentic engineering means setting the conditions before delegating: define business invariants, security requirements, acceptance criteria and edge cases. Then review the outcome with automated tests, code review and human approval appropriate to the risk. Agents can assist throughout; they should not be the sole authority on what is acceptable.
As implementation becomes faster, the ability to specify sound constraints and recognise poor decisions becomes more valuable, not less.
3. Before building an AI application, test what an existing model can already do
Andrej Karpathy described building MenuGen, an application that illustrated dishes from a photographed restaurant menu, before discovering that a general-purpose model could produce a similar result from the image and a simple instruction. The story does not mean applications are disappearing. It challenges us to identify what an application genuinely adds.
If a product mainly wraps a prompt in an interface, it may become redundant quickly. A dedicated application can still make sense when it provides business integrations, granular access control, a specific experience, repeatable results, audit trails or approval processes.
Before development, we find it useful to prototype with existing tools and document what remains missing. Which data needs connecting? Which actions must be reliable? Who approves what? What ongoing maintenance is the organisation prepared to support?
The question is not simply 'can we build it?', but 'what can this product guarantee that existing tools cannot?'
4. A CMS with an API is not automatically ready for agents
Content workflows provide a practical example. A marketing team may need to update a hundred product records in three languages. An agent could retrieve the content, prepare changes, suggest translations and flag inconsistencies. Giving it unrestricted publishing access, however, would rarely be a sensible first step.
A safer workflow separates read and write permissions, drafts and publication. It includes change history, human approval and, where necessary, a way to roll back modifications. The exact capabilities depend on the CMS, its API and the surrounding integrations.
This introduces an additional criterion when evaluating platforms. Editorial usability remains important, but so do content structure, granular permissions and the ability to build controlled workflows. A headless CMS can make some integrations easier; it does not solve governance on its own.
What this means for our design process
At ultraperfekt, these developments encourage us to ask a few questions earlier in a project: who needs to read this content, a person or an agent? Which actions should be automated? How will results be verified? And do we actually need to build a new tool?
The fundamentals remain unchanged: understand the need, structure the information, choose a suitable architecture and test what gets delivered. AI does not make these steps obsolete. It increases the number of situations in which we need to think beyond the graphical interface.
