Context Architecture - NN/G

Introducing NN/G Membership | Access all self-paced courses for $249 per year | Join by Jan. 26, 2027 |
Find the training option that fits your learning style.
June 12, 2026 2026-06-12
The way we shape AI products has evolved quickly.
It started with prompt engineering. Early on, success depended on crafting the right instruction. A well-written prompt could unlock surprisingly strong results, and teams began collecting and reusing prompts as assets.
Then came context engineering, a concept coined by Tobi Lutke. Teams realized that prompts alone were not enough; what matters is a concise collection of context-specific guidance, targeted to the task at hand: instructions, retrieved knowledge, narrow tools, selected memory, and state all working together. The task shifted from writing prompts to orchestrating context.
Now we are entering the era of agentic systems. Agents do not just respond, they perform tasks on behalf of the user. They retrieve information, call tools, maintain state, and act across multiple steps. They operate with increasing autonomy, often coordinating with other agents.
This shift unlocks a new design problem. We are no longer defining only what to say to a model, we are designing the environment in which it thinks and acts.
To address this challenge a familiar discipline, information architecture, becomes critical in a new form: context architecture.
For millennia, humans have organized information so people can understand it, navigate through it, and use it effectively. We developed structures, taxonomies, labeling systems, and navigation patterns to reduce ambiguity and improve findability. LLMs need the same foundations.
The challenge is not only the access to information. It is making that information meaningful, structured, and usable for both humans and machines.
This is the role of information architecture, now applied to context itself.
And in the age of AI, it becomes central.
Keep up with these industry-redefining changes and design for AI in Designing AI Experiences.
Traditional digital products are deterministic. We design flows step by step, define our product's behavior across those flows, and hard-code them. This way allows us to have a consistent output every single time. The system behaves as intended, and we have to worry only about how the user would react to it.
AI products change this dynamic. LLMs are probabilistic, so the same input can lead to different outputs. That variability is part of their power, but it also means we no longer have full control over what the system produces. The challenge shifts from defining exact outcomes to shaping the behavior of the system, while still accounting for how users will interpret and respond.
For many teams, training data is not something they can directly control. They rely on third party models and foundation models trained elsewhere. That makes context one of the primary ways to shape system behavior. Instructions, retrieved knowledge, tools, memory, and state all influence how the model interprets a task and generates a response. Teams can then measure whether changes to the context actually improve system behavior.
Context is not just a list of system prompts; it is an ecosystem of information that needs to be discovered and selected. It is everything inside the context window of an AI system. It can either live there or be retrieved from stored information, to shape the model's output.
In modern AI systems, context is assembled dynamically from multiple sources:
All these elements blend natural language, structured markup, and code. Some may be long and layered.
However, more context does not lead to better results, because every element competes for the model's "attention." Just like humans, models are affected by information overload.
Poorly structured context can slow systems down, increase costs, and lead to inconsistent or error-prone outputs. Clear context structure and prioritization matter as much as the content itself.
Context engineering is how engineering teams now shape AI behavior. It recognizes that these systems are not driven by a single input, but by a collection of interacting signals that need to be curated and maintained.
This is where UX professionals are needed.
We have seen this dynamic before in physical systems. Before moving to UX, I worked as an architect designing public schools in New York City. Engineers ensured the plumbing worked, the electricity flowed, and the structure held together. Architects focused on a different set of questions: What was the building for? How should people move through it? How should the spaces be organized so they make sense to the people using them?
What makes a house feel like a home is not just structural integrity. It is the natural light, the proportions of a room, and the spaces where people gather and create memories.
The same nuances apply here. Context engineering builds the infrastructure. Context architecture defines the structure of the information that lives on top of it. While context engineering focuses on pipelines and components, context architecture, led by information architects, focuses on structure, meaning, and behavior.
It asks things like:
Information architects define what metadata exists, how entities relate to each other, and how the structure reflects the user's mental model, ultimately making the model more efficient and accurate. For example, a well-designed taxonomy allows engineers to retrieve only the policies related to billing disputes instead of searching across all customer-support documentation, thus reducing retrieval noise and improving response accuracy. Similarly, labels aligned with the users' mental models help engineers invoke the right skill for each task. For example, labeling a skill reset password instead of credential-recovery workflow makes it easier for the system to match the skill to a user saying, "I can't log in."
As AI systems become embedded in everyday products, the collaboration