AI product design is not a prompt problem. It is a context architecture problem.

In my experience, when an AI feature works in the demo and breaks in production, the model is often not what failed. The failure sits in the system around it: which state is current, what the system is allowed to act on, what evidence sits behind an answer, and how a bad action is contained and undone. That surrounding system is what I call the context architecture.

At Tcules, we keep seeing the same pattern. A serious AI product conversation starts with the fashionable questions.

• Which model should we use?
• How much does prompt engineering matter?
• Should this be an agent, a workflow, or both?
• How autonomous should the system be?
• What is the right tool stack?

Then the work gets real, and the conversation changes. It stops being mostly about models. It stops being mostly about prompts. It starts becoming about context.

Not "context" in the loose sense of "give the model more information". Context in the harder sense:

• what the system knows
• what it is allowed to trust
• what it is allowed to do
• what the current state actually is
• what changed
• what is approved versus inferred
• what evidence sits behind a recommendation
• what can be reversed when something goes wrong

A lot of AI product work is still framed as a reasoning problem first. In my experience, many production failures show up somewhere else. They show up in representation, authority, provenance and recovery.

That is the real architecture.

This is not true for all AI work

To be precise, this is not a claim about every AI use case.

If you are doing lightweight summarisation, bounded content generation or low-risk assistance, in my experience model quality and prompt design often dominate.

But once a workflow becomes multi-step, stateful, collaborative, tool-using, high-consequence, and expected to work repeatedly rather than impress once, the bottleneck starts moving. Anthropic's guide to building effective agents makes a similar distinction between workflows, where models and tools run through predefined code paths, and agents, where the model directs its own process, and warns that autonomy brings "the potential for compounding errors". Repeatability is its own test: on the τ-bench benchmark (2024), a leading function-calling model of the time completed fewer than half the tasks, and in the retail domain succeeded on all eight attempts at the same task less than a quarter of the time.

At that point, raw intelligence is no longer enough.

The harder problem is building the substrate around intelligence.

What I mean by context architecture

A context architecture is the system that determines what an AI product knows, what it can trust, and what it can safely act on.

It sits underneath what model providers now call context engineering. Anthropic's Applied AI team defines context engineering as curating and maintaining the best set of tokens a model sees during inference, and treats context as "a finite resource with diminishing marginal returns". That is why "give the model more information" is not the answer. Context engineering decides what goes into the window. Context architecture decides whether what goes in is current, trusted and authorised.

In practice, that means some combination of:

• an entity model
• an artefact store
• relationship mapping
• event or history logs
• versioning
• provenance
• permissions
• evaluation and approval logic

That may sound abstract. It is not.

It is the difference between an AI system that sounds plausible and one that can survive production.

A model can generate an answer.

It cannot, by itself, establish canonical state. It cannot, by itself, resolve whether a design decision was approved yesterday or merely proposed. It cannot, by itself, guarantee that the context it received was complete, current or authorised. It cannot, by itself, make bad actions safely reversible.

That infrastructure has to exist outside the model.

LLMs are not your product architecture. They are a volatile reasoning layer sitting on top of state, evidence and control.

The three layers people keep collapsing into one

One of the most common mistakes I see in AI product design is collapsing three different layers into one fuzzy concept.

The reasoning layer

This is where models, prompts, tool calls, planning logic and response behaviour live. This layer matters. It determines how the system interprets inputs, decomposes tasks and produces outputs. But it is not the whole system.

The context substrate

This is where the system's working reality lives.

Artefacts. Entities. Relationships. State. History. Versioned decisions. Source references. Reusable objects.

This layer determines what the model has to work with.

The control layer

This is where permission, evaluation, human approval, rollback and observability live. This layer determines what the system may do, how it is checked, and how failure is contained.

A lot of teams are trying to solve problems in the context substrate and control layer using tricks in the reasoning layer.

That works briefly. Then it breaks in production.

Most serious agent failures I see are not failures of intelligence

That is my judgement from the work, not a measured rate. The research that exists points the same way without settling it. In an analysis of more than 1,600 annotated traces from seven multi-agent frameworks, Cemri and colleagues at UC Berkeley conclude that these failures are "not merely a function of challenges in the underlying model", and conjecture that better base models alone will not resolve all of them. Practitioners running agents in production, surveyed and interviewed for Measuring Agents in Production (ICML 2026), name reliability as their top development challenge and report handling it "through systems-level design".

The failures I see are usually failures of one of these four things.

State ambiguity

The system does not know what is current. It sees multiple documents, multiple specs, multiple threads, multiple versions, and cannot reliably distinguish active state from stale state.

So it behaves coherently on top of ambiguity. That is dangerous, because the answer sounds better than the underlying certainty deserves.

Authority confusion

The system does not know what it is allowed to act on. It cannot reliably distinguish between draft and approved, inferred and confirmed, internal note and client-facing artefact, or suggestion and executable instruction.

This is where agentic systems become risky. Not because they are "too intelligent", but because their action boundary is badly defined. The Model Context Protocol specification, the open standard for connecting models to data and tools, says tool descriptions should be treated as untrusted unless they come from a trusted server and that hosts must obtain explicit user consent before invoking any tool, and states that the protocol itself cannot enforce these principles; implementers should build consent and authorisation into their applications. The OWASP guidance on excessive agency is blunter: implement authorisation in downstream systems "rather than relying on an LLM to decide if an action is allowed". How that boundary appears to the person, action by action, is the subject of agentic UX design principles; this is the layer underneath it.

Provenance loss

The system cannot show why it said what it said. It gives a recommendation, but the supporting evidence is fragmented, missing or impossible to inspect.

That makes correction hard and trust brittle.

Recovery weakness

The system can act, but failure is poorly contained.

No rollback. No trace. No clear step history. No reliable way to inspect what happened.

A widely reported July 2025 incident shows authority and recovery failing together. The Register reported that Replit's coding agent deleted a user's production database despite an instruction to freeze code and, according to Replit, did not respond properly when asked to restore the data because it lacked access to the right internal documentation. The fixes Replit announced were structural, not prompt changes: separate development and production databases, and a forced documentation lookup for restores.

A demo only needs to work. A system needs to fail sanely.

Why design makes this problem worse, not easier

This becomes brutally obvious in product design, because design is not just output generation.

A complex product UI is a state machine dressed as an interface.

Behind every "simple" screen there are permissions, dependencies, empty states, failure states, conditional logic, responsive behaviour, data assumptions, implementation constraints and future extensibility decisions.

Now add AI.

The interface becomes partly probabilistic. Responses may vary. Retrieval may fail. Confidence may be misplaced. The system may need to explain itself, cite itself or gracefully step back.

At that point, the design problem is no longer just "how should this look?" or even "how should this flow?"

It becomes:

• what must the system remember?
• what should it reveal?
• what must remain inspectable?
• when should it ask for confirmation?
• what should be reversible?
• where does responsibility sit when the system is wrong?

Those are not prompt questions. They are product architecture questions. Once they are answered in the architecture, the review moments a person actually sees are their own design problem, covered in human-in-the-loop UX patterns.

Why this shows up so clearly in design audit systems

AI-powered design audit is a good example. From the outside, it looks like automated critique: getting a model to say smart things about a UI. That is the easy part, and candidate issues are becoming cheap to produce, as argued in what you should get from heuristic evaluation. The hard part is a system that moves through flows without losing context, keeps screen-level and flow-level evidence, separates isolated issues from systemic patterns, ties each finding to an artefact and to observable proof, and says where evidence is partial. Without that memory, traceability and provenance, you do not have an audit system. You have a fluent commentator.

Why this also shows up in design engineering

The second example is design engineering.

In advanced product teams, UI truth does not live in one place. It lives across design intent, component logic, runtime behaviour and production constraints.

That is why modern teams keep running into parity problems:

• the Figma component says one thing
• the code component does another
• production reveals a third reality
• edge cases emerge only at runtime
• AI-specific states were never fully represented anywhere

The old handoff model cannot absorb that well.

The real problem is not "how do we pass design to engineering?"

It is "how do we preserve parity between design intent, code implementation and runtime behaviour as the system evolves?"

That is a context architecture problem.

Because once parity matters, you need to know:

• which component definition is current
• how it maps to code
• which states are missing
• where divergence began
• which changes were intentional
• which were accidental
• whether production behaviour still reflects the original contract

This is why I think design engineering is becoming more important. Not because everyone should become a frontend developer, but because product quality increasingly depends on tighter coupling between design systems, code systems and live behaviour. It is also why Tcules, a digital product design studio, builds on Product Design and extends it with Design Engineering and Software Development, bringing design and engineering into the same conversation from early concepts and working prototypes to launch-ready software.

Why "old-school" structures keep coming back

This is the part that throws people off.

The deeper AI product work goes, the more teams rediscover things that look old-school:

• files
• graphs
• logs
• records
• version history
• approval states
• structured artefacts

That does not mean the future is backward.

It means certain problems keep recurring, and these structures remain legible ways to solve them.

Not because folders are magical. Not because graphs are trendy. Not because logs are elegant.

But because persistent systems need persistent representations.

Files, graphs and records are not the truth. They are just some of the clearest containers we currently have for persistent state, relationships, provenance, authority and recoverability.

In my experience, the teams that mistake these for outdated metaphors have not yet been forced to debug a high-stakes AI workflow in production.

What founders and system architects should ask instead

If you are building an AI-native product, do not stop at:

• which model should power this?
• what prompt pattern should we use?
• how autonomous should the agent be?

Also ask:

• what is the unit of work in this system?
• what artefacts does it create, consume or modify?
• where does canonical truth live?
• what must be versioned?
• what is inferred versus approved?
• what evidence should always be inspectable?
• what can the system do without permission?
• what must be reversible?
• how will this survive across sessions, tools and people?

Those are not secondary implementation details. They are core product decisions.

Working through them for a specific product, and designing the relationship between people, models and product state, is the work behind AI product UX at Tcules.

The real shift

The most useful way I know to say this is simple:

AI products do not become reliable when the model gets smarter. They become reliable when intelligence is placed inside a better context and control architecture.

That is the shift.

Not from old systems to new systems. From software that merely executes logic to software that must preserve, interpret and act across context.

The teams that win here will not be the ones with the cleverest prompt library.

They will be the ones that represent work better.

Because in production-grade AI systems, intelligence is downstream of structure.