AI Applications: Six Architectural Steps to Avoid Chaos

The adoption of AI has outpaced the organization of the products that host it, multiplying heterogeneous vocabularies, outputs, and error behaviors. Six movements in information architecture and design propose a method to regain control without starting from scratch.

Refactor on cadence to avoid invisible accumulation

After the 1906 earthquake, the damaged floors of the San José house were sealed, and construction continued elsewhere. This reflex is mirrored in teams that replace a feature while leaving the old one active behind a flag, never returning to it. The first three proposed movements are merely a snapshot that degrades over time if nothing is planned to reconcile it. New objects appear without being named in the initial contract, deadlines push teams to circumvent the template library, and components are forked to the point of existing in two variants with different behaviors. These drifts result from a normal accumulation when no time is reserved for a reset.

Why so many AI surfaces end up disjointed

Nearly 90% of organizations use AI, but most have not reorganized their workflows accordingly. Features have arrived faster than any structure to contain them, with divergent vocabularies, output formats, and error behaviors. This issue falls under information architecture, a skill already present in teams. Prototyping makes additions inexpensive, leading to a proliferation of copilots, summaries, drafting buttons, and improvised data models, each operating in isolation. The metaphor of a house mapped for a virtual tour illustrates the difficulty of navigating a set without a plan.

Anchor an object model and a semantic contract

Before any new capability, a shared object model must be defined, with the real domain names and the allowed verbs for each. Constraints such as an archivable project, a shareable document, or an invoice that is approved and payable but not archivable if the business prohibits it only exist if they are written down. This model serves as the scaffolding upon which everything else depends. A request like "create a follow-up" must be based on a defined object with a persistent home; otherwise, it invents an entity without grounding. Specifically, this involves listing names before features, checking each action against a real object, and publishing a common semantic contract approved by engineering and design.

Standardize behaviors through a template library

It is necessary for a limited library of interaction templates to frame behaviors over time: suggestion, drafting, synthesis, classification, planning, and confirmation, each traversing states from input to retrieval or cancellation. Many teams have 40 features without any template, resulting in 40 different ways to handle failure, even though failure is not an exceptional situation. It should be designed once at the model level so that it is inherited everywhere, regulating as strictly what is displayed as what occurs. Teams already know how to build controlled languages. Operationally: name five or six behaviors and document their states, compose the new from the library, deliberately add missing templates, and sustainably unify states of error, emptiness, low confidence, and delay.

Close the set of outputs and prioritize payloads

Defining a closed set of output components such as cards, differences, tables, timelines, or pre-filled forms allows for framing surfaces. Any custom proposal must justify why nothing in the set is suitable. The responses from features should return as structured payloads that the frontend renders via existing components, with schemas derived from their properties, rather than as free text.

Maintain the product map as a living document

In many teams, the information architecture has remained static since launch, while dozens of capabilities have been added. Without an updated map, it is impossible to see the current shape of the product or address drift; the map must be alive. This involves redrawing it with each delivery, integrating it into the definition of done, generating it from the routes and navigation of the code, then reconciling it with the drawn version, and appointing a responsible person at each level. The story of a house built continuously, without a plan, highlights the risk of stacking. Conversely, requests that were once absurd, such as a house with between two and forty-five rooms or a roof in 48 hours, are now technically feasible thanks to prototyping, making it even more necessary to apply these six movements to channel speed.