System First Architecture for the AI Era

#architecture #ai #webdev #api

Introduction: A New Era in Search and Digital Architecture

On May 19, 2026, Google announced at I/O that search is entering an era of AI Mode, where users can create and manage search agents that continuously gather information and act on tasks in the background https://search.google . In this model, the familiar chain “person → Google → list of links” is giving way to AI-driven discovery: agents search, compare, analyze data, and even perform actions for the user . This shift suggests that digital products must expose their data, processes and actions in structured, machine readable ways to be visible to AI agents.

At OneEntry, we recognised early that page centric architectures would not meet these requirements. Our platform was built around a system first approach, focusing on well-defined entities, workflows, statuses, and integrations rather than pages and buttons. We believe that products and services built with these principles — whether on OneEntry or elsewhere — are better prepared for this new world: their backends expose clear processes that AI agents can interact with, helping ensure they remain discoverable and automatable in an AI driven search environment.

Below we provide a technical deep dive into how we structure systems for AI readability, using OneEntry as a concrete example.

How to Make a System Understandable to AI: Schemas, Events and Integrations in OneEntry

In the first article we found that the emergence of agentic AI changes not only search mechanics but also the approach to designing digital products. A page, a button, a form and even a single API method are no longer sufficient when an intelligent agent interacts with the system instead of a person. This article continues the first one. We move from general principles to the technical side: how to describe entities, statuses, actions and events so that AI agents can work with the system without guesswork or chaos.

Backend Is Not Just a Database

During the development of OneEntry we saw that the backend is no longer a passive storage of data. It becomes the operational layer of the system: it manages statuses, orchestrates workflows and connects integrations. The structure of a system is not only table fields but also processes, relationships and events. The task of the backend is to provide a single description of this structure in a form understandable to both people and machines. Such structured, machine readable documentation helps people and AI agents stay in sync and productive. That is why in the modern spec driven approach API contracts (OpenAPI, AsyncAPI) are considered “first class citizens”: they should be versioned and used as the single source of truth, with compatibility verified through contract testing.

How It Looks Technically

1. Entities and Attributes: The Structure Lives in the Backend

In OneEntry the frontend does not describe all fields manually. The model of an entity is stored in the backend: a list of attributes, their types and rules. For example, at first the model of a dish might look like this:

// Entity: Dish
type Dish = {
  title: string;
  description: string;
  price: number;
};

But in real life new characteristics appear: sizes, spiciness, allergens, availability, regional prices, kitchenStatus, deliverySettings. The structure of the entity in OneEntry is stored centrally, so if you need to add a new field, for example kitchenPreparationTime, you do not need to rewrite the entire frontend: you add the attribute to the entity description in the backend, and the form automatically picks up this parameter. This model makes work easier for developers and AI agents, which can dynamically discover the structure of entities via schemas.

2. Forms and Workflows: The Backend Knows Not Only Fields but Also Processes

Not only data are important but also the behaviour of the system. In OneEntry forms (for example, a reservation form) are stored not just as UI templates. The system knows:

what fields the form contains;
what validations apply to each field;
what happens after the form is submitted;
what events are triggered.

This means the backend stores the workflow of the form. When an application is submitted, checks, calls to external services and generation of events may occur. All this is described structurally. An AI agent can obtain this information from a schema and understand which steps need to be executed.

3. Events: The Event Model Helps AI Understand Processes

Every change of state in OneEntry is recorded as an event. For example, the order process can be described by events:

OrderCreated
↓
PaymentInitialized
↓
KitchenNotified
↓
CourierRequested
↓
CustomerNotified

An event is an immutable record with a name, timestamp and payload structure. Agents subscribe to these events and react to them. Event driven architecture (EDA) reduces latency by 70–90 % compared with polling because agents subscribe to events instead of constantly checking for changes . Confluent notes that replacing RPC calls with event driven architecture eliminates rigid dependencies and provides flexibility and scalability .

Events have schemas: the structure specifies the event name, timestamp, source, payload fields and version. Well defined schemas allow producers and consumers to evolve independently without coordination . The event bus receives events from producers and delivers them to all subscribed consumers. This decoupling gives EDA its scalability: producers do not need to know which agents will consume their events, and consumers do not need to know which systems produce the events they care about . New agents can be added to a topic without modifying existing components.

4. Integrations: Part of the System, Not External Black Boxes

OneEntry knows which integrations are connected (payment gateways, delivery, notifications), what actions they have and which events they process. This is described in the structure of the system, so an AI agent does not need to “guess” where payment logic is or where delivery logic is. It sees integrations as part of the workflows described in the schemas.

5. AI Schema, OpenAPI and MCP: How AI Learns the Structure

AI cannot simply “look at a site” and understand how the backend is arranged. Therefore the system must provide a machine readable description of its structure. In OneEntry this is done through several layers:

OpenAPI/Swagger for REST endpoints: AI can load /openapi.json and see the full API contract (methods, parameters, data models).
MCP (Model Context Protocol) or AI schema: these are extended schemas describing entities, their fields, relationships, statuses, allowed actions and related workflows. Confluent notes that MCP provides a universal standard for integrating AI systems with external tools, data sources and applications, ensuring secure and seamless access to up to date information .
Event schema registry: stores event schemas so that agents can validate and evolve message consumption.

Example: a restaurant application on OneEntry contains entities Order, Reservation, Payment, Delivery, Statuses, Events. Based on these data the system automatically generates an AI schema. When an agent requests /ai-schema, it receives a structured representation, for example:

{
  "entity": "Order",
  "actions": [
    "create",
    "cancel",
    "track"
  ],
  "statuses": [
    "created",
    "paid",
    "delivering",
    "completed"
  ]
}

The agent now understands that there is an Order entity, what statuses it has, what actions are available and what transitions are possible. It can correctly call API methods, subscribe to events OrderCreated, PaymentInitialized, DeliveryRequested and orchestrate subsequent steps.

Why This Matters for OneEntry and the AI First Era

The main advantage of OneEntry is that the system stores the structure of the project within itself. It knows its entities, attributes, forms, statuses, relationships, events and workflows. Business logic is not scattered across the frontend, middleware, scripts and separate APIs; it is centralised. Thanks to this, OneEntry is much easier to adapt to the AI first era than classic systems where logic lives in various layers.

In OneEntry the basis is not pages but entities and processes: users, orders, forms, statuses, events, integrations, workflows. The frontend remains important because people still need a convenient UX. But its role changes and it becomes a layer of interaction and visualisation. Business logic, orchestration and integrations remain in the backend, which provides understandable actions for people and AI agents.

The clearer a system describes its entities, statuses, workflows, events and relationships, the easier it is for AI to perform actions, automate processes and make decisions. Systems with clear models, predictable structures, workflows, event mechanisms and described integrations are much better prepared for an AI first internet, where agents will become the new “users,” backend systems will be more important than HTML pages and workflows will be more important than individual endpoints.

Conclusion

The rise of AI driven search and autonomous agents means our systems can no longer be “black boxes” filled with custom logic. To be discoverable and operable in this new landscape, backends need to be system first: centred on clear data models, explicit workflows, machine readable APIs and events. That isn’t about buzzwords - it’s about creating software that other systems (including AI agents) can understand and work with reliably.

We’ve shown how OneEntry approaches this: entities live in the backend rather than the UI, workflows and forms are defined alongside data structures, and events provide a decoupled way for agents to react to changes. These patterns aren’t proprietary; they’re emerging best practices for any team building modern APIs. Whether you use OneEntry or roll your own, focusing on structured schemas, strong event contracts and clear workflows is the practical foundation for AI ready applications.