Context Engineering Is the New Information Architecture

The most important design question this decade is one we already know how to answer. We just called it something else.

There's a phrase I've started using in meetings that lands harder than it should.

A product manager will be describing some new AI feature — a copilot, an assistant, a generative something — and I'll ask, quietly, what does it remember, and what does it forget? The room usually goes still for a beat. Not because the question is hard, but because nobody has thought to ask it yet. We've been so focused on what the AI can do that we haven't designed what it knows.

I've come to believe this is the single most important design question we get to ask in the next few years. And the strange thing about it is that we already know how to answer it. We've been answering versions of it our whole careers. We just called it something else.

We called it information architecture.

The Quiet Reframing

Here is the part of my practice that has shifted most this year.

When someone says "agentic AI," I no longer think about the model. I think about the layer around the model — the thing that decides what context to load, what state to persist, what history to summarize, what to throw away. Because that layer, it turns out, is where almost all the interesting design work lives.

I've started calling it context engineering, because that's the term that's emerging in technical circles. But strip the word "engineering" off and what's left is something deeply familiar. It is the deliberate design of what information enters and leaves a mind across time. Whose mind? Sometimes a human's. Increasingly, both.

If you've ever designed a navigation system, you have designed context. If you've ever picked which fields to show on a default form and which to tuck inside a disclosure, you have designed context. If you've ever fought a product manager over what shows up in a notification, you have designed context. The discipline transfers almost completely. What's new is the second mind in the room.

Three Things I've Stopped Treating as Engineering Problems

These used to feel like things I waited for engineers to figure out. They aren't. They're design problems with technical implementations, and the design choices upstream determine almost everything downstream.

1. Principles travel further than rules

I've watched several teams try to define how an AI assistant should behave by writing detailed scripts. If the user does X, respond with Y. If they ask about Z, escalate. The scripts grow. The edge cases compound. Six weeks in, the document is forty pages long and the assistant still feels brittle. The first time a user does something the script didn't anticipate, the whole thing falls over.

The teams that ship something good do something different. They write four or five things:

• An identity, narrowly scoped. Who is this thing, in one sentence. ("A scheduling assistant for executives at a mid-sized firm.")
• A reasoning framework, not a flowchart. A repeatable way to approach problems. (Understand the request → check the calendar → propose options → confirm.)
• Heuristics, not rules. Compressed principles that guide judgment. ("When two times work, prefer the earlier one." "If anything is ambiguous, ask before assuming.")
• Trust in the model to choose its own tools toward the goal.

This is identical to the difference between a great design system and a brittle one. Great systems give designers principles and let them reason inside the spirit of the thing. Brittle systems try to anticipate every screen and end up with libraries of one-off components nobody can find. We have a lot of practice with this. The new ask is to apply it to a teammate that doesn't read body language.

Write the brief, not the script.

2. Memory is a resource, and you can spend it badly

Here is the technical reality nobody wants to put on a slide: AI systems have working memory, that memory is finite, and every token you put into it costs you three things. It costs money. It costs latency. And — most importantly — it dilutes the signal of what matters.

That third cost is the one that should get our attention. When you cram too much context into a system, performance doesn't fail loudly. It fails quietly. The model still answers. The answer is just worse, in ways that are hard to attribute. This is the "more is more" trap, and it's the same trap we've been pulling users out of for thirty years.

What works, both for humans and for AI, is the same four moves:

• Persist what matters across sessions.
• Select only what's needed for the current task.
• Compress when memory gets full.
• Isolate specialists into their own contexts.

Watch a person use a tool well and you see all four. They save things, they search, they summarize, they open different windows for different jobs. We have spent careers designing for the human's working memory. The frontier now is designing for two working memories at once, sharing the same surface, handing context back and forth.

That handoff — what the person passes to the AI, what the AI passes back, what the system remembers between turns — is the most important interaction surface I see in product work right now, and almost nobody is designing it intentionally.

3. The format of the conversation is the conversation

This one I learned by accident, watching the difference between asking an AI to respond in prose versus asking it to respond in structured form.

The format isn't just packaging. It changes the thinking.

Ask for a paragraph and you get sentences that read well and reason loosely. Ask for nested bullets and the reasoning gets more sequential. Ask for a structured outline — categories, dependencies, relationships — and the model starts producing something closer to architecture than narrative. The output style is shaping the cognition, not just the rendering.

This is craft we know. The medium of a communication shapes the substance. We've been picking media for cognitive effect since the beginning of the discipline. Memos invite different thinking than slides. Whiteboards invite different thinking than docs. Chat invites different thinking than email.

The new ask is to design those choices deliberately for AI as well as humans, and to design the translations between them. The agent thinks in structure. The user reads prose. The engineer wants JSON. The operator wants a dashboard. Who designs those handoffs?

We do, if we want to.

The Trap I'm Watching For

The thing I worry about most isn't AI doing our work badly. It's AI doing our work plausibly, and us mistaking plausibility for quality.

There's a pattern emerging in agentic workflows where you ask the AI to generate many variations of an artifact and pick the best. It's seductive. Run the loop ten times, get ten hero sections, pick the one that looks freshest.

Done well, this is useful. It produces real diversity when you have a strong evaluator and you know what you're optimizing for.

Done lazily, it produces the design equivalent of asking ChatGPT for five blog titles. You get five passable ones, ship the one with the best vibe, and miss the one that mattered — because the version that mattered would have required taste, and taste was the thing you outsourced.

The pattern is fine. The problem is when teams treat the loop as a substitute for the judgment about what to vary in the first place. That judgment is the work. It is the entire job. If we let it atrophy, we'll be very fast at making indistinguishable things.

If your team starts running these loops at scale, the question I'd ask is: who is writing the evaluator? If the answer is "the AI," you've quietly outsourced the part only you can do.

What I'm Practicing

The thing I do differently now — earlier in every project, before the screens and the flows — is this:

I write a short document that answers four questions about the system we're building.

What does this system remember across sessions, and what does it deliberately forget?

What context does each role in the system carry, and how does it get to them?

When context overflows, what gets compressed, and what gets thrown away?

Who has access to what, and how does the system show that to the people who need to know?

These are old questions in new clothes. Designers have been answering them in databases, settings panels, permission matrices, and onboarding flows for as long as there has been software. What's different is that they're now on the surface of the experience, in the back-and-forth between a person and an agent, where they used to be hidden inside the architecture.

That move — from hidden infrastructure to designed interaction — is the move that should put us, the designers, at the front of the room.

Context engineering is the new information architecture. We have a thirty-year head start. We should act like it.