AI Is Building Your Product. It Doesn't Know Your Customer.

Every design org I’ve seen operate at scale has solved the same hard problem: how to keep a large team aligned on shared design intent. You build a design system. You create a token library. You define spacing rules, type scales, color semantics, and component behaviors, and then you give that system a home. A repo, a Figma library, a Storybook instance. A place where the shared truth lives. And when it works, it’s one of the most powerful things a design organization can produce, a single source of truth that scales design decisions across dozens of teams without requiring a designer in every room.

It took the industry years to figure that out. And we’re proud of it. Rightly so.

Here’s what I’ve noticed in 2026, though: development teams aren’t waiting for us.

The engineers and product builders at most organizations are already moving to agentic development — by that, I mean they’re not just using AI to autocomplete code anymore. They have AI agents that can plan a sprint, scaffold an entire feature, write tests, and open a pull request. These agents are increasingly autonomous. They’re making product decisions at a pace that the traditional design review cycle wasn’t built for.

And those agents don’t know who your customers are.

Every new agentic session starts cold. It doesn’t know your users’ environment, their mental models, or the constraints that make your product worth building. It doesn’t know your tone-of-voice, your accessibility bar, or which design trade-offs your organization has already made and why. It knows what’s in its training data, and whatever context the developer remembered to paste into the prompt before getting started.

That’s the gap. And if design orgs don’t move to fill it deliberately, the agents building tomorrow’s product will make those decisions without us.

Think about what a design system actually does. At the surface level, it keeps components consistent. But below the surface — and this is the part that took most teams years to understand — it encodes intent. It answers the question: Why does this button look this way? It communicates: This color isn’t just blue. It’s the color we use when we need users to take an action that can’t be undone. It holds the reasoning, not just the rules.

That’s precisely what an AI agent needs to do its job well. Not just the rules, but the reasoning behind them.

The shift happening right now is that design systems, originally built for human designers and engineers, are being asked to serve a third audience: the AI agent.

And most of them aren’t ready.

Here’s what this looks like in practice. An engineering team spins up an agentic workflow to scaffold a new feature. The agent is making dozens of micro-decisions before a designer even opens the ticket. What level of contrast is “accessible enough?” Should this form field have inline validation? What’s the right label hierarchy for this dashboard? Is this a primary action or a destructive one?

If your customer context isn’t readable by an agent, it defaults to generic industry patterns. It defaults to “acceptable.” And “acceptable” isn’t what your users hired your organization to build.

I’ve seen this create a feedback loop that’s subtle but compounding. The output is technically coherent but strategically misaligned with your users. The design team catches it in review, manually corrects it, and everyone moves on. Then the same pattern repeats in the next sprint, and the one after that. Nobody patches the root cause, because the root cause isn’t visible; it’s the absence of customer and brand context in the agent’s session before it ever generates a line of code.

The reality is: design orgs are making retroactive corrections to problems we could have prevented with proactive context. We’ve just never had a format that development teams’ agents can actually consume.

Here’s the counter-intuitive truth: engineers already know how to leave a note for the machine. Developers are fluent in context files: they have their CLAUDE.md, their AGENTS.md, their .cursorrules. These files tell the agent how to build: which language conventions to follow, which patterns to avoid, and how to structure a pull request.

What those files almost never contain is the why behind the product. The customer. The brand. The intent.

That’s not an engineering gap. That’s a design gap. And it’s ours to fill.

What I’m seeing the leading design teams start to build is something I’d call a Context Repository. By that, I mean a structured set of Markdown files, maintained alongside your design system, that design orgs own and publish into the shared codebase. Not documentation for human designers. Documentation for the agents that development teams are using to build product right now.

Think of it this way: design tokens gave developers a structured way to consume visual intent at scale — the right color, the right spacing, the right type style, every time, without a designer in the room. A Context Repository does the same thing for customer intent, brand voice, and organizational values. It makes that knowledge portable. Machine-readable. Present at the start.

It’s not a new idea dressed up in AI language. It’s your design system’s natural next chapter, and arguably the most important chapter yet.

All of these files share the same job: they answer the customer and brand questions the agent will make assumptions about if you don’t. Think about what that repository could contain:

personas.md — Not the PDF buried in a Confluence page nobody opens. A lean, structured file that describes your actual users: their environment, their mental models, their relationship to the product. The veteran field technician who’s used your tool for 15 years. The new logistics coordinator still learning the workflow. The executive who checks in twice a month and needs to understand the headline number immediately. This is the file that stops an agent from building a beautiful mobile-first experience for someone who exclusively works on a 27-inch monitor in a windowless office.

business-rules.md — Every product carries a set of constraints that didn’t come from a design decision; they came from legal, compliance, operations, or a contract signed five years ago. An agent that doesn’t know these rules will confidently generate features your company isn’t allowed to ship. This file encodes the guardrails the agent needs before it starts proposing solutions.

research-findings.md — Your UX research team has spent years learning things about your customers that no training dataset contains. The workarounds users have built due to the current flow being too slow. The features that get ignored because the label doesn’t match the mental model. The moments where trust breaks. This file distills those findings into structured, actionable signals the agent can reason from — so it’s building on real evidence, not industry averages.

content-guide.md — Every label, error message, and confirmation dialog is a brand moment. An agent without a content guide will default to functional but generic language: “Submit,” “Error,” “Are you sure?” A content guide tells the agent that your brand talks to users like a trusted colleague: direct, human, never condescending. This is the difference between a product that feels familiar and one that feels like a form.

competitive-analysis.md — Context isn’t just about your users. It’s about the landscape they’re coming from. If your users have been trained by a competitor’s interaction patterns for the last three years, an agent needs to know that — because it shapes what feels intuitive versus confusing. This file gives the agent the market awareness to make smarter positioning decisions at the design level, not just the marketing level.

Engineering teams with agentic workflows are already treating their context files the way good architects treat documentation: as living infrastructure with an owner, a versioning strategy, and a review cycle.

The opportunity for design leaders is straightforward: they’ve built the process. We have the design context.

Development teams want this! The engineers I’ve seen doing this work aren’t trying to skip design. They’re trying to move faster than the traditional handoff process allows. If design orgs can encode customer context, brand constraints, and accessibility requirements in a format agents can consume, we don’t slow the build down. We embed design intelligence into it.

If you build this well, you’ve done something far more valuable than improving AI output quality. You’ve forced your organization to write down the things it only knew in its head.

Most enterprise design teams have a version of “shared understanding” that lives entirely in people, in the veteran researcher who knows your users cold, in the design director who has opinions about tone that are brilliant but undocumented, in the engineering manager who knows which patterns create technical debt. That knowledge is real and valuable. It’s also fragile. It walks out the door when people leave.

A Context Repository doesn’t just serve the AI agent. It externalizes institutional knowledge — just as your design system externalized visual intent. And that has organizational value long after the current wave of agentic tools evolves into whatever comes next.

Development teams are moving to agentic workflows whether design orgs are ready or not. That’s not a criticism; it’s the reality of where the tooling is headed. The question isn’t whether AI agents will be involved in building your product. It’s whether those agents will have your customer context when they do.

Design system teams already understand governance, versioning, and the difference between a rule and its reasoning. They know how to write documentation that scales. The capability to build a Context Repository isn’t somewhere else in the org.

It’s already in your design system team. They just need a new mandate.

The agents are already in the room. The question is: did we brief them?

Is your design org actively contributing context files to your engineering team’s agentic workflows? Or are you still catching misaligned output in review? I’d love to hear what you’re seeing in the comments!

Found this useful? Subscribe for more systems-thinking perspectives on enterprise AI and UX leadership.