There is a fairly predictable moment in product design now. Someone says the product needs AI, and the next discussion is usually about where the assistant should live. A floating button appears. Then a sparkle icon. Then a panel opens from the right. Eventually there is a prompt box at the bottom, and the product officially has an AI strategy.

Meanwhile, the user was already doing something.

They were reading a dashboard, comparing two numbers, editing a document, trying to understand why a project slipped, reviewing an order, or looking for the reason a metric suddenly changed. To get help, we often ask them to stop that flow, open another surface, explain what they were looking at, read the answer, then return to the original interface and mentally reconnect everything.

The intelligence may be impressive. The choreography around it often is not.

That made me wonder whether the problem is not the assistant itself, but the container we keep putting it in.

What if AI did not always need a permanent home beside the interface? What if it understood the interface well enough to temporarily become part of it?

That is the idea I have been exploring as a Spatial AI layer.

https://youtu.be/1PokPoypnGM

AI understands more context now. Our interaction model has barely changed.

AI products are increasingly able to understand the environment around the user rather than only the text inside a prompt. Design tools can reason about canvas objects and components. Screen-aware assistants can understand what is visible. Productivity agents can operate across documents, tasks, and application state.

That is a meaningful shift because the AI increasingly knows where the user already is.

But we still make people travel to AI.

Imagine working beside a colleague who can see the same analytics dashboard you are looking at, knows what every metric represents, knows which data changed since yesterday, and understands the relationship between the numbers on the screen. Every time you ask a question, that colleague hands you a blank notebook and asks you to describe the screen first.

Useful colleague.

Strange workflow.

Chat is still valuable, but it should not have to be the universal shape of intelligence.

If AI understands the structure of the interface, its response can sometimes be something other than a paragraph.

It can point.

It can connect.

It can highlight a boundary.

It can become the prompt.

And occasionally, it can simply get out of the way.

That is where Spatial AI starts.

The idea is a small AI presence that sits quietly in the product until there is a reason for it to become useful. It does not behave like a mascot following the pointer around, and it does not constantly remind the user that the product contains AI.

Most of the time, it is almost nothing.

But its form can change according to the task.

If something deserves attention, it can stretch into a pointer. If the user is trying to understand why one thing changed, it can become the relationship between cause and effect. If they want to ask a question, it can expand into an input. If they speak, the same material can enter a listening state. If an important event happens, its material can change and attach itself to the relevant part of the interface.

Then it returns to its neutral form.

The important part is not the blob.

The important part is that one intelligence can temporarily become the interaction the user needs.

Consider the most ordinary question possible: “Why did this change?”

Imagine a SaaS analytics dashboard.

Weekly active users have dropped 18%.

There are ten other metrics on the screen, several charts, a funnel, and a list of recent product changes. The user does not yet know whether the drop is meaningful or where it came from.

A normal AI assistant can answer this perfectly well:

Weekly active users declined because onboarding completion dropped after the latest signup-flow change.

Useful answer.

But the user still has to find the onboarding metric, locate the signup change, compare the dates, and rebuild the relationship that the AI already understands.

Spatial AI can respond differently.

The assistant stays quiet while the user begins reading. Once the metric becomes relevant, it moves into nearby whitespace and points toward the 18% drop.

Most of this change comes from onboarding.

If the user wants to understand why, the AI returns to its neutral form and stretches from the weekly-active-user metric toward the onboarding-completion chart. The relevant part of the funnel gets a restrained boundary.

For several seconds, the AI is no longer merely describing the relationship.

It becomes the relationship.

Then it retracts.

This removes a surprisingly common piece of work from AI interaction: translating the assistant’s language back into the interface.

https://youtu.be/3THEQY2g094

A prompt should not need permanent real estate either.

Prompt boxes are useful because language gives users enormous flexibility. I am not arguing that we should remove them.

I am questioning whether they need to live inside a permanent AI destination.

Imagine someone is looking at a project-management board and sees that a launch has moved by six days. They invoke the Spatial AI presence near the timeline.

The blob moves into safe whitespace and gradually stretches horizontally. Its surface settles into an input field.

Ask about this project…

The user types:

What is actually blocking the launch?

They submit.

The input compresses toward its centre and returns to the blob. The blob travels to the dependency chain and connects the launch date to a delayed content approval, which in turn blocks the final QA task.

The answer does not arrive in another panel.

It arrives at the problem.

That distinction is important. If AI becomes deeply contextual, the user should not have to repeatedly move between “product mode” and “AI mode.”

AI should increasingly feel like a capability of the product itself.

https://youtu.be/o39DZAroSt0

The same principle works for voice.

A lot of AI interfaces change visual language completely when voice begins. Suddenly there is a microphone, a waveform, bars bouncing inside an orb, and several glowing layers trying very hard to prove that sound exists.

I think that is unnecessary.

When the user starts speaking, the same Spatial AI presence can remain recognisably itself. Its organic motion becomes slightly more attentive and a subtle halo indicates that it is listening. When it responds, the material can continue slowly deforming without pretending to have a mouth or face.

The important thing is continuity.

The entity that listened is the same entity that moves toward the answer afterwards.

Text, voice, explanation, navigation and state feedback do not need five separate AI components. They can be expressions of one interaction layer.

That is when AI begins to feel native to the product rather than attached to it.

This only works if the AI learns when to do nothing.

This is probably the most important part of the idea.

An AI object moving through an interface looks fantastic in a thirty-second concept video. The same object moving every few minutes during an eight-hour workday would become unbearable.

So the most important Spatial AI state is not pointing, morphing, listening, or warning.

It is silence.

If someone is successfully reading the page, stay quiet. If the existing interface already explains what happened, stay quiet. If background analysis completes and nothing important changed, stay quiet. If a user clearly knows what they are doing, do not introduce movement simply because AI is technically available.

I think proactive AI needs a concept of an intervention budget.

Instead of asking, “What can AI do here?”, the system should ask:

What is the smallest intervention that improves the user’s current task?

I currently think about that as a ladder.

Do nothing → Presence → Signal → Point → Relationship → Conversation → Escalation

Conversation is deliberately not first.

If a subtle pointer solves the problem, there is no reason to open a conversation. If connecting two pieces of information communicates the answer better than a paragraph, use the connection. If the user is already succeeding, level zero wins.

The most sophisticated behaviour may be knowing when not to participate.

Behaviour can help decide when intervention is useful, but it cannot read minds.

Suppose someone working in a project tool repeatedly opens the timeline, then dependencies, then returns to the timeline, then opens dependencies again.

The system may eventually infer that they are trying to understand what is blocking the launch.

But one backtrack does not mean confusion. Neither does a hover, a pause, or a repeated click in isolation.

Behavior is evidence, not certainty.

A Spatial AI system should combine multiple signals: the current workflow, repeated navigation, failed actions, what the user has already inspected, and how confident the AI is about its interpretation. Even then, the first intervention should remain small.

Perhaps the blob moves slightly toward the dependency view.

This may be the faster route.

The user can ignore it.

That relationship matters. AI should propose an interpretation of behaviour, not announce that it has successfully diagnosed the person using the product.

Restraint is part of intelligence.

The hard part is not animation. It is teaching AI what the interface means.

A prototype can fake Spatial AI very easily.

Move the blob to x: 842.

Draw a line to y: 430.

Highlight this card.

Looks great in a demo.

Falls apart as soon as the layout changes.

For this to work as a real product layer, the AI needs a semantic understanding of the interface. It cannot only know where something is. It needs to know what that thing means.

Take an e-commerce operations platform.

A card displaying “12 units remaining” should not just be a rectangle with text inside it. To the AI, it might represent:

Object: Inventory Level
Product: Everyday Backpack
State: Low stock
Importance: High
Related to:
  - Recent sales velocity
  - Supplier lead time
  - Incoming shipment

AI may:
  - explain
  - highlight
  - connect related information
  - suggest actions

AI may not:
  - change inventory
  - place purchase orders without approval

Now a user can ask:

Why are we going out of stock?

And Spatial AI does not search for nearby numbers.

It understands the relationship between inventory, sales velocity and the next shipment.

This connects closely to something I have written about before: design systems increasingly need to describe more than visual appearance. As AI becomes another consumer of the system, components need structured intent, state, relationships and constraints — not just pixels and tokens.

Spatial AI depends on that foundation.

Without semantics, the blob is animation.

With semantics, it can navigate meaning.

This also changes what designers need to specify.

We already design user flows, states, journeys, permissions, components and increasingly agent behaviour.

Spatial AI introduces another design question:

When should intelligence physically enter the experience?

That probably needs its own artifact.

I have been thinking about it as an Intervention Map.

For each important moment, we define the user’s current goal, the signals the system can observe, how confident AI is about its interpretation, the smallest useful intervention, where that intervention may appear, how the user can ignore it, and what causes the AI to return to neutral.

One additional question should be mandatory:

What must AI never do here?

That question may become as important as everything the AI is allowed to do.

For example:

User momentSignalAI responseReading analyticsNormal progressionDo nothingReturning after a weekOne major metric changedPoint to changeAsking “why?”Explicit intentConnect cause and outcomeRepeated project backtrackingMedium-confidence frictionSuggest a routeStock approaching zeroHigh relevanceAttach warning to inventoryWorkflow completeConfirmed successBrief completion gesture

This is how the idea moves from “interesting AI animation” into interaction architecture.

And this cannot become another AI mascot.

There is a version of this concept that I would immediately kill.

The blob follows the cursor. It waves when the product opens. It bounces when a filter finishes loading. It becomes sad when something fails. Someone eventually gives it eyes and a name, and now we are scheduling workshops to define its personality.

That is not Spatial AI.

Movement needs semantic meaning.

If it moves, the motion should communicate direction, relationship, scope, progress, urgency or completion. If the motion communicates nothing, remove it.

A brief success morph after finishing a meaningful task can work because it communicates closure. The blob might rise slightly, briefly approximate a thumbs-up, then melt back into its neutral form.

Half a second.

Done.

No confetti.

The user probably has other things to do.

The intelligence should come from knowing when to appear, not from constantly trying to look alive.

This is bigger than a blob.

The underlying capabilities are already emerging. AI can increasingly understand screens, application state, canvases, documents, components and the environment around a task. The interaction model simply has not caught up yet.

We still tend to treat AI as another destination inside the product.

Open assistant.

Ask.

Read.

Close.

Continue.

Spatial AI asks what happens when intelligence becomes part of the interaction language instead.

Sometimes the right answer is a prompt.

Sometimes it is a connection between two things.

Sometimes it is a boundary around the relevant section.

Sometimes it is a small piece of guidance.

Sometimes it is an urgent state attached directly to the thing that changed.

And very often, it should be nothing at all.

That is the part I find most interesting.

The future AI interface may not be the one with the best chatbot attached to it.

It may be the product that understands when intelligence should enter the interface, what form it should take, and when it should disappear again.

https://youtu.be/_9B6FRPNNPc

Closing

For most of software history, the relationship was simple: the interface exposed controls, the user navigated them, and the system responded.

AI is changing that relationship.

It can increasingly understand what the user is looking at, what the objects on the screen mean, what changed, how those objects relate to one another, and what the user may be trying to accomplish.

So perhaps “Where should we put the AI assistant?” is becoming the wrong design question.

The more interesting one is:

What should intelligence become when it already understands where the user is?

That is what I am trying to explore with Spatial AI.

Not another chatbot. Not another right-side copilot. And definitely not a futuristic blob floating around because blobs apparently became the official shape of artificial intelligence.

A layer of intelligence that can enter the interaction when it adds value, temporarily become the interface the user needs, and quietly leave when it does not.

Because the best AI interface may eventually be the one that stops looking like an AI interface at all.

The scariest AI product moment will not be when the interface looks broken.

It will be when the system does the wrong thing beautifully.

A clean card. A polished summary. A confident recommendation. A smooth animation. A beautiful button saying, “Approve.”

And behind all that polish, the AI has misunderstood the user, skipped context, recommended the wrong next step, or taken action before the customer was ready.

That is the next UX problem.

Not bad UI. Bad agency.

In my previous article, I explored design systems as infrastructure — the idea that design systems are no longer just UI kits, but the foundation that helps teams build consistent, scalable products.

But this is the next chapter.

Because once AI agents enter the product experience, they will not just help us design screens. They will begin acting inside the customer journey.

They will answer questions. Summarise problems. Recommend next steps. Draft responses. Trigger workflows. Route requests. Personalise experiences. Escalate cases. Sometimes, they may even act before the user explicitly asks.

And at that point, the designer’s job changes.

We are no longer only designing what users click.

We are designing what systems are allowed to do.

The next UX question is not “what should the user do next?”

For years, UX design has focused on helping users move forward.

Make the task easier. Reduce friction. Improve completion. Shorten the flow. Make the next action obvious.

That still matters.

But agentic AI adds a new layer:

What should the system be allowed to do on behalf of the user?

That question is much heavier than “where should the button go?”

Should AI only suggest? Should it draft? Should it prepare an action? Should it execute after approval? Should it act automatically? Should it stop and ask a human?

This is not only an interaction-design problem. It is a trust problem. A governance problem. A CX problem.

A button waits for the user.

An agent may move without them.

That is the shift.

AI is moving from answer box to action layer

For a while, AI in products looked like an answer box.

Ask a question. Get a response. Maybe copy it somewhere. Maybe regenerate it.

But the market is moving beyond that.

Microsoft describes autonomous agents in Copilot Studio as agents that can perceive events, make decisions, and execute tasks using triggers, instructions, and guardrails defined by the organization. (Microsoft Learn)

Atlassian describes Rovo agents as configurable AI teammates that can be used across Chat, Confluence, Jira, automation rules, and Studio, depending on knowledge sources and permissions. (Atlassian Support)

GitHub Copilot’s cloud agent can work on coding tasks in its own environment, explore code, make changes, run tests, and create pull requests. (GitHub Docs)

Notice the pattern.

The interesting part is not the chat window.

The interesting part is action.

AI is no longer only replying. It is starting to move work forward.

And when software starts moving work forward, UX has to design the brakes, mirrors, seatbelt, and emergency exit — not just the dashboard.

CX innovation is not “add a sparkle icon”

A lot of product teams still treat AI innovation like a visual layer.

Add an AI assistant. Add a magic button. Add an auto-summary. Add a recommended section. Add a “generate” option.

That is the shallow version.

The deeper version is this:

AI should reduce customer effort without reducing customer control.

That is the balance.

Your CX research direction also points to this: customer experience innovation is no longer just about polishing interfaces, but about designing coherent, trustworthy, adaptive journeys across touchpoints, channels, and time. It also highlights that trust has become the gating factor for AI-enabled CX innovation.

That is where agentic UX becomes important.

A product can be fast and still feel unsafe. It can be automated and still feel annoying. It can be personalised and still feel creepy. It can be intelligent and still feel irresponsible.

So the designer’s job is not to make AI look smart.

The job is to make AI behave responsibly.

The permission ladder: a simple way to design agentic UX

Not every AI action deserves the same level of freedom.

A good agentic experience needs a permission ladder.

At the lowest level, AI can inform. It can summarise, classify, explain, translate, simplify, or make complex information easier to understand.

One level higher, AI can recommend. It can suggest the next best action, prioritise options, surface risks, or guide the user toward a better decision.

Then AI can prepare. It can draft an email, pre-fill a form, create a report, assemble a checklist, or generate a response for review.

After that, AI can execute with approval. It can take action, but only after the user clearly reviews and confirms.

Only in low-risk, reversible, well-bounded situations should AI act automatically.

This ladder matters because many weak AI experiences happen when teams jump too quickly from “AI can suggest” to “AI can do.”

That jump is where trust breaks.

A mature product does not ask, “Can we automate this?”

It asks, “What level of agency is appropriate here?”

Real example: online shopping returns

Let’s take a simple public example: an ecommerce return journey.

A customer wants to return a pair of shoes.

At the inform level, AI can explain the return policy in plain language.

“You can return this item within 30 days. It must be unused and in original packaging.”

At the recommend level, AI can suggest the best return option.

“Drop-off is faster than pickup for your location.”

At the prepare level, AI can pre-fill the return reason, generate the label, and prepare the refund request.

At the execute with approval level, AI can submit the return only after the customer confirms the item, refund method, pickup address, and terms.

At the automatic level, maybe AI can send a reminder if the return label is about to expire.

That feels helpful.

But imagine AI automatically choosing store credit instead of refunding to the original payment method because it is better for business.

That may improve internal metrics.

But it damages trust.

This is the difference between automation and agency design.

Real example: travel booking changes

Now imagine a travel app.

A flight is delayed, and AI wants to help.

At the inform level, it explains the delay and shows the updated departure time.

At the recommend level, it suggests alternative flights, nearby hotels, or meal voucher options.

At the prepare level, it drafts a rebooking plan.

At the execute with approval level, it changes the flight after the user confirms the new timing, layover, seat preference, baggage impact, and price difference.

But should AI automatically rebook the user without asking?

Maybe in a very specific, pre-approved, low-risk corporate travel policy. But for most customers, no.

Because travel is personal.

A “better” flight on paper may be worse for the person.

Maybe they needed that layover. Maybe they are travelling with family. Maybe they have visa constraints. Maybe they planned airport pickup. Maybe the cheapest option is not the least stressful option.

AI may optimise the transaction.

But UX must protect the human context.

Real example: customer support escalation

Support is becoming one of the biggest testing grounds for agentic UX.

Intercom describes Fin as an AI agent for customer experience that can resolve complex queries across channels and is evolving into specialized roles across service, sales, and more. (Intercom) Zendesk positions its AI agents as service tools that can automate customer interactions and improve support outcomes. (Zendesk)

But customers do not care how advanced the bot is.

They care whether their problem gets solved without repeating themselves five times.

That is where the real UX lives.

The bot is not the experience.

The handoff is the experience. The recovery is the experience. The context transfer is the experience. The moment where AI says, “I need a human here,” is the experience.

A poor handoff says:

“I cannot help with this.”

A better handoff says:

“I’m connecting you to the right person. I’ve shared your issue summary, order details, and the steps already tried, so you do not need to repeat yourself.”

That one moment can change how the customer feels about the entire brand.

Human fallback is not a failure.

Bad fallback is.

The interface must show why the agent wants to act

When AI recommends or prepares an action, the UI should not only show the output.

It should show the reason.

Users need to understand why something is being recommended, what evidence supports it, how confident the system is, what will change if they approve, whether they can undo it, who will be notified, and where the action will be recorded.

This is where many AI products still feel thin.

They show the conclusion but hide the responsibility.

A good agentic interface should feel less like a magician and more like a senior teammate.

Not:

“Trust me, I handled it.”

More like:

“Here is what I found. Here is what I suggest. Here is why. Here is the risk. Here is what needs your approval.”

That difference is everything.

IBM’s Carbon AI guidance is a useful public example of this direction. Its AI label is intended to make AI-generated or AI-assisted content recognizable and to reinforce transparency, accountability, and explainability across interfaces. (Carbon Design System)

That is the kind of thinking product teams need more of.

AI should not silently blend into the interface when it is influencing decisions.

Users deserve to know when intelligence is involved.

Designers need a new artifact: the agency map

In a normal user flow, we map what the user does.

In an agentic flow, we also need to map what the agent does.

For every important journey moment, we should ask:

What does the user want? What does the agent know? What can the agent infer? What is the agent allowed to do? What requires confirmation? What should be reversible? What should be logged? What should trigger escalation? What should the agent never do?

This becomes a new design artifact.

Not just a user journey map.

An agency map.

The agency map shows where AI informs, recommends, prepares, acts, pauses, asks, escalates, or stays silent.

And honestly, “stays silent” may become one of the most underrated AI design patterns.

Not every moment needs intelligence.

Some moments need space.

How we can implement this using AI

The practical part is not “add AI everywhere.”

The practical part is using AI to design safer AI experiences.

Designers can use AI to audit journeys and ask:

Where is the user repeating work? Where is decision fatigue happening? Where is context getting lost? Where can the system prepare something useful? Where would automation create risk? Where should human approval remain mandatory? Where does the product need evidence, undo, or escalation?

AI can help generate an agency matrix for a journey.

For every task, classify whether the agent should:

AI can also help write handoff scripts, create failure scenarios, generate edge cases, draft evidence-card content, cluster user feedback, and build test cases for risky agent behavior.

For example, in an ecommerce return journey, AI can help test:

What happens if the customer wants a refund but the system recommends store credit? What happens if the item is non-returnable? What happens if the pickup address is wrong? What happens if AI fills the wrong reason? What happens if the customer rejects the recommendation? What happens if the refund fails?

This is where AI becomes useful before it becomes visible to users.

We can use AI to stress-test the experience.

Not just decorate it.

The new UX metrics are not only completion and speed

Agentic experiences need a different measurement mindset.

Yes, we should still measure task completion, time saved, resolution rate, adoption, support volume, and conversion.

But that is not enough.

We also need to measure how often users override the agent, how often they undo an AI action, how often they reject a recommendation, how often they ask for human help, whether they understood why AI suggested something, whether trust increased or decreased after automation, and whether AI reduced effort without increasing anxiety.

If the only metric is automation rate, teams will over-automate.

If the only metric is speed, teams will remove necessary friction.

If the only metric is containment, teams will trap users.

Agentic UX needs guardrail metrics because not all efficiency is healthy.

Sometimes friction is not the enemy.

Sometimes friction is the seatbelt.

This is the real sequel

Design systems gave teams consistency.

Agentic systems need responsibility.

The previous question was:

Can AI understand the system?

The next question is:

Can AI act without damaging the journey?

That is the real sequel.

Because the future of UX is not only AI-generated screens. It is AI-mediated experiences where software starts making decisions, preparing work, and taking action around the customer.

And when products start acting, designers must design the boundaries.

Permission. Evidence. Confidence. Undo. Escalation. Memory. Silence. Human control.

These are the new materials of UX.

They do not replace layout, hierarchy, content, accessibility, or interaction design.

They sit on top of them as a new layer of responsibility.

Closing thought

The future is not AI that looks intelligent.

The future is AI that knows its limits.

That is what customers will trust.

Not the agent that answers everything. Not the product that automates everything. Not the interface that hides complexity under a sparkle icon.

The product that wins will be the one that knows when to suggest, when to prepare, when to ask, when to act, and when to step back.

Because in the agentic era, the best experience may not be the one where AI does the most.

It may be the one where AI does the right amount — with evidence, permission, and humility.

That is where design becomes interesting again.

Not because we are designing more screens.

But because we are designing the behavior of products that are no longer waiting quietly for clicks.

They are starting to act.

Designing for the Moment AI Starts Acting was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Your next design system user may not be a designer opening Figma or an engineer browsing Storybook. It may be an AI agent asked to generate a screen, choose components, write code, and produce something close enough to production that humans only review the final shape.

That changes the role of a design system completely.

For years, design systems were built mainly for humans. Designers used them to maintain visual consistency. Engineers used them to avoid rebuilding the same components. Product teams used them to move faster with shared patterns. That model still matters, but it is no longer enough.

AI does not understand your product the way a designer does. It does not know why one button should be primary, why a modal is wrong for a certain flow, or why a table needs an empty state before it ships. AI follows the context it is given. If the design system cannot explain its intent clearly, the AI will guess.

And that is where the next wave of design drift begins.

The old design system was a shelf

Most design systems today behave like well-organized shelves. Components are stored in one place. Tokens are documented. Patterns are explained. Examples are added. There are usage notes, do’s and don’ts, accessibility guidelines, and maybe a few contribution rules.

This is useful, but passive.

A passive design system waits for someone to read it, understand it, and apply it correctly. That already creates problems with human teams under deadline pressure. People miss details. Engineers copy old code. Designers create one-off patterns. Someone hardcodes a color because it is “just for now,” and six months later it becomes part of the product’s visual language by accident.

AI makes this faster. It can generate UI quickly, but speed without system intelligence creates a new problem: inconsistent output at scale. The more teams rely on AI-assisted development, the more important it becomes for the design system to be machine-readable, not just human-readable.

The question is no longer only, “Do we have a component for this?” The better question is, “Can the system explain when, why, and how this component should be used clearly enough for both humans and AI agents?”

That is the shift from a component library to product infrastructure.

The design system needs a new job

A traditional design system tells humans what to do. An agentic design system tells humans and machines what to do, then checks whether they did it correctly.

This does not mean replacing designers. It means preserving design judgment in a form that systems can use. The design system should know what components exist, when they should be used, when they should not be used, which variants are appropriate, what tokens are allowed, what accessibility rules apply, and what patterns should be blocked before they reach production.

In simple words, the design system has to become an operating layer between product intent and shipped interface.

That operating layer needs five parts: components and tokens, structured intent, a knowledge graph, an agent layer, and governance. Each layer has a specific job. Together, they create a design system that is not just documented, but executable.

Layer 1: Components, tokens, and archetypes

This is the foundation. It includes buttons, inputs, tables, cards, modals, navigation, empty states, icons, spacing, color, typography, motion, and screen templates. Without this layer, nothing else works.

But this is also where many design systems stop. They create reusable parts and assume adoption will solve the rest. It rarely does. A component alone does not tell an AI agent when it should be used. A token alone does not explain why a certain background is correct in one context and wrong in another.

Components and tokens are necessary, but they are no longer the strategic advantage. The advantage is not just having reusable parts. The advantage is having reusable parts that carry meaning.

Layer 2: Structured intent

Structured intent is the most important layer. This is where every component explains itself in a format that humans can read and machines can query.

A button should not only say, “Primary buttons are used for important actions.” That is too vague. Important to whom? Important in what context? Can a screen have two primary buttons? What happens when one action is destructive and another is the main path forward?

A better rule would say: “Use the primary variant for the main action the user should take in the current decision area. Do not use more than one primary button in the same section. Use secondary for supporting actions. Use danger for destructive or irreversible actions.”

That is design judgment converted into usable logic.

Structured intent should include usage rules, anti-patterns, variant meanings, composition rules, accessibility requirements, content guidance, and AI selection hints. The goal is not to create more documentation. The goal is to make design intent clear enough that it can guide generation and validation.

Here is a simplified example:

{
"component": "Button",
"purpose": "Triggers an action or moves the user forward in a workflow.",
"useWhen": [
"The user needs to take a clear action",
"The action is part of a form, confirmation, or task flow",
"The action should be visually distinct from surrounding content"
],
"doNotUseWhen": [
{
"scenario": "Multiple primary buttons in the same section",
"reason": "Creates unclear visual hierarchy",
"alternative": "Use one primary button and secondary or ghost buttons for supporting actions"
}
],
"variants": {
"primary": "Main action the user should take",
"secondary": "Alternative or supporting action",
"ghost": "Low-emphasis action",
"danger": "Destructive or irreversible action"
},
"composition": {
"allowedChildren": ["text", "icon"],
"disallowedChildren": ["card", "form", "table"]
},
"accessibility": {
"requiresKeyboardFocus": true,
"requiresAccessibleName": true,
"minimumContrast": "WCAG AA"
},
"aiHints": {
"selectionKeywords": ["submit", "save", "continue", "confirm", "cancel"],
"selectionRule": "Choose the variant based on action hierarchy, not visual preference."
}
}

This is not documentation written only for robots. It is design guidance written clearly enough that both humans and robots can use it. That clarity is the real value.

Layer 3: The knowledge graph

Once components carry intent, the system needs a map of relationships. That is the role of the knowledge graph.

The knowledge graph answers questions like: Which screens use this component? Which tokens does it depend on? Which patterns are approved for this use case? Which component replaced an older one? Which product areas are using deprecated patterns? What might break if this token changes?

This turns the design system from a collection into a network.

For AI, this context is extremely important. Without a map, an agent can only pick from available parts. With a map, it can understand relationships. It can know that an incident triage screen usually needs a list-detail layout, a filter pattern, severity indicators, an empty state, loading states, and approved action hierarchy.

That is the difference between generating UI from vibes and generating UI from institutional memory.

Layer 4: The agent layer

The agent layer is where the system becomes active. There are three useful agent roles.

The first is a selection agent. It helps choose the right component based on intent. For example, if the prompt says “add a confirmation action,” the agent checks the metadata and selects the correct button variant instead of inventing custom markup.

The second is a validation agent. It checks whether generated UI follows the system rules. It can flag hardcoded colors, incorrect variants, missing accessibility attributes, unsupported component nesting, or missing states such as loading, empty, error, and success.

The third is a generation agent. This is the more advanced layer where an agent can assemble a screen from product intent. It reads the system, selects an archetype, chooses approved components, applies tokens, and creates a draft that humans review.

The important point is this: the agent should not create from scratch. It should create from system knowledge.

AI should not be treated as a magic designer. It should be treated as a fast builder that needs strong context, clear constraints, and automatic validation.

Layer 5: Governance

Governance is the layer that keeps the system honest. Without it, the architecture becomes a nice diagram and nothing more.

Governance includes CI checks, linting rules, token audits, accessibility validation, visual regression, contribution workflows, deprecation paths, and audit logs. These are not glamorous, but they are what make consistency survive real product pressure.

A rule that only lives in documentation is a suggestion. A rule that runs in CI is governance.

This is especially important in AI-assisted workflows. If an AI generates a screen with hardcoded spacing, wrong component usage, or missing accessibility states, the system should catch it before merge. Designers should not spend their time manually hunting every obvious violation. Their attention should go toward experience quality, hierarchy, flow, trust, and user understanding.

Good governance does not slow teams down. Bad governance does. Good governance removes repeated arguments and catches predictable mistakes early.

What changes in real product work

Imagine a team needs to build a new incident triage screen.

In the current model, a PM writes a ticket, a designer interprets it, an engineer looks for an old screen, AI helps generate some code, a few components are almost right, some tokens are hardcoded, design QA catches a few issues, and some drift still slips into production.

Nobody planned the mess. The mess simply found the gaps.

In an agentic design system, the same work starts with intent. The system maps the request to a known screen archetype. The agent selects approved components. It uses design tokens. It checks composition, accessibility, and required states. A designer and engineer still review the output, but they are not reviewing basic system compliance. They are reviewing whether the experience actually works.

That is the real productivity gain. Not “AI makes screens faster.” The better claim is: AI can help teams move faster without creating uncontrolled design debt, if the system gives it enough intent and governance.

The real moat is not the UI kit

Many teams think their design system advantage is the component library. It is not. Components can be copied. Tokens can be copied. Layouts can be copied.

The real moat is the accumulated judgment around the system.

Why does this component exist? When should it be avoided? Which variant works in which context? Which misuse keeps appearing? Which patterns are accepted by product teams? Which rules need enforcement? Which components should be deprecated? Which AI outputs keep getting rejected?

That corpus becomes the asset.

A traditional component library scales with adoption. An agentic design system compounds with usage. Every product team adds patterns. Every rejected AI output sharpens the rules. Every validation failure exposes a gap. Every accepted pattern strengthens the system.

Over time, the design system becomes more than a reusable library. It becomes product memory.

How to start without boiling the ocean

You do not need to build the full architecture immediately. Start with one component that causes repeated confusion. Good candidates are Button, Modal, Table, Dropdown, Empty State, Filter, Navigation, or Card.

For that component, document five things.

First, define usage. When should this component be used, and what user intent does it support?

Second, define anti-patterns. Where is this component commonly misused, why does that create confusion, and what should be used instead?

Third, define variants. Do not describe variants only by appearance. Describe them by intent. Primary is not “the blue button.” Primary is the main action the user should take.

Fourth, define composition. What can go inside this component? What can sit beside it? What should never be nested inside it?

Fifth, define AI hints. What keywords, user goals, task signals, or conditions should help an AI agent select this component correctly?

If a component cannot answer these five questions, it is not ready for AI-assisted product work.

The Agentic Component Intent Template

Use this as a starting point:

Component name:
What it does:
Primary user intent:
When to use it:
When not to use it:
Variants and what each one means:
Allowed children:
Disallowed children:
Common mistakes:
Accessibility requirements:
Content rules:
AI selection keywords:
Validation rules:
Examples of correct usage:
Examples of incorrect usage:
Open questions:

Fill this out for one component and your design system becomes slightly more readable to machines. Fill it out for ten and patterns start to emerge. Fill it out for the whole system and you no longer have only a component library. You have product infrastructure.

A practical prompt to create structured intent

Here is a prompt you can use with existing component documentation:

You are a senior design systems architect.

I will provide documentation for a UI component.

Convert it into structured intent for both human designers and AI agents.

Use this schema:
- componentName
- purpose
- primaryUserIntent
- useWhen
- doNotUseWhen
- variants
- compositionRules
- accessibilityRules
- contentGuidelines
- aiSelectionHints
- validationRules
- examples
- openQuestions

Rules:
- Do not invent unsupported behavior.
- If something is unclear, mark it under openQuestions.
- Write in plain language.
- Make each rule specific enough that an AI agent could use it to choose the component correctly.
- Output valid JSON.

Here is the component documentation:
[Paste documentation here]

This does not solve everything, but it gives teams a practical starting point. The goal is not perfection. The goal is to begin converting design judgment into a structure that can be reused, queried, and improved.

Designers move upstream

This is not about replacing designers. That is the shallow version of the AI conversation.

The better question is: what parts of design judgment are important enough to preserve in the system?

Designers will not create long-term value by manually correcting every AI-generated button, table, or modal. They will create value by teaching the system what good looks like before the screen is generated.

That means designers move upstream. Less time policing surface-level inconsistencies. More time defining patterns, clarifying intent, shaping interaction quality, improving accessibility, and deciding what should become reusable product logic.

This is still design craft. It is just operating at a higher level.

Closing thought

Your design system has a new user now. That user is not only a designer or engineer. It is an AI agent that needs context, constraints, and feedback.

The future of design systems is not bigger libraries. It is clearer intent. It is not more documentation. It is documentation that machines can query and humans can trust.

A design system that stores components helps teams move. A design system that understands intent helps teams move correctly.

And a design system that can explain itself may be the first step toward a design system that thinks.

Your Next Design System User Is an AI Agent was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most agent failures are not model failures. They’re product failures wearing a premium UI.

There’s a very modern kind of design meeting happening right now.

The design file is open.
Someone wants the AI assistant to feel “more proactive.”
Someone else wants it docked on the right because that somehow feels more intelligent.
A third person thinks the magic icon still doesn’t look magical enough.

Beautiful.

Then, if the meeting is lucky, one mildly annoying adult asks the only question that actually matters:

“What exactly is this agent allowed to do?”

And suddenly the room gets quiet.

I’ve been in enough design critiques to know we can debate a button for twenty minutes, a border radius for ten more, and still avoid the one question that decides whether the feature is useful or just expensive theater.

That silence matters.

Because the strongest guidance coming from Google’s PAIR Guidebook, Anthropic, OpenAI, Microsoft, NIST, and Nielsen Norman Group is not really telling teams to add more AI glitter. It keeps coming back to the same grown-up themes: start with a real user need, decide whether AI should automate or augment, pass the right context instead of dumping everything into the model, define the system’s actions and boundaries clearly, design for correction and graceful failure, and measure whether the thing actually improved work. NN/g now goes so far as to say AI agents interact with digital interfaces alongside humans and should be treated as users in that functional sense. (Pair with Google)

So this article is not about how to make your agent sound smarter.

It’s about something less sexy and much more useful:

Before you give the agent keys, run a real review.

Not a workshop.
Not a slogan.
Not a side panel with confidence badges and emotional support copy.

A review.

Let’s make it concrete.

Imagine a product design team working on a new onboarding flow for a SaaS product. The team wants an agent to help review the flow before release. Not to replace the designer. Not to become the next design messiah. Just to do some of the heavy lifting first.

Maybe it scans the latest screens, compares them against the design system, checks whether accessibility basics are being violated, reads recent usability findings, and drafts a prioritized set of changes for the team to review.

Reasonable idea.

But that idea becomes useful only when six uncomfortable questions get answered.

First: give it a real job

“Help improve the onboarding experience” is not a job.
That’s not a requirement. That’s a scented candle.

A real job sounds like this:

Review the onboarding flow, compare it against approved components and recent research findings, then draft a prioritized list of usability and consistency issues for the designer to approve.

Now the work becomes real.

The best guidance starts here for a reason. Google’s PAIR Guidebook explicitly tells teams to identify real user needs and decide whether the task should be automated or augmented. It also warns that sometimes ordinary software or rules are the better choice. Anthropic’s guidance on effective agents makes a similar point from the other side: agents add the most value when the task has clear success criteria, feedback loops, and meaningful human oversight. (Pair with Google)

If the job is vague, the agent won’t become intelligent.

It will improvise.

And nothing creates premium chaos faster than a system improvising inside a workflow nobody properly defined.

Second: brief it before it speaks

This is where teams get sentimental.

They say,
“We’ll just give it more context.”

No.

That is how digital hoarding becomes product strategy.

Context is not more information.
Context is the right information at the right moment.

In our onboarding example, the agent probably does not need the entire history of the company, twelve quarters of roadmaps, and every abandoned concept from the workshop-that-should-never-be-mentioned-again.

It needs what matters now:

Which flow is under review.
Which platform it’s for.
Which version of the design system is current.
What the primary user goal is.
What recent usability tests found.
What constraints already exist.
What accessibility requirements are non-negotiable.

That’s context.

Anthropic’s context-engineering guidance is useful precisely because it says this part out loud: the real challenge is curating what enters the model’s working state over time, not just writing a clever prompt. Microsoft’s Copilot Studio guidance shows the same principle in very practical form by letting teams pass structured page-level context, language, and other variables into an agent so the user doesn’t have to repeat what the system already knows. (Anthropic)

If your agent keeps asking for information already visible in the product, already stored in the system, or already decided in the workflow, that is not intelligence.

That is amnesia with a nice onboarding animation.

Third: define the move, not just the button

This is where many AI features still feel like interns in blazers.

A team says, “The agent can take action.”

Lovely.

What action?
With what authority?
Using what input?
With what side effects?
And who cleans up if it gets bold?

In the onboarding example, maybe the agent is allowed to annotate frames, flag component mismatches, identify likely accessibility issues, draft usability recommendations, and create suggested tickets for the team.

Fine.

But maybe it is not allowed to rewrite approved brand copy on its own, swap shared components across the file, change the design system library, or push anything into development without a human sign-off.

That distinction is the design.

OpenAI’s function-calling guidance is useful here because it turns this dreamy “the AI will just do stuff” narrative into something stricter: models connect to data and actions through defined tools. OpenAI’s structured-outputs guidance pushes that further by emphasizing schema-constrained outputs when reliable structure matters. In plain English: if the action is real, it needs a real contract. (OpenAI Developers)

A pretty button is not an action contract.

A prompt is not an action contract.

A side panel with strong opinions and a confidence score is definitely not an action contract.

If you cannot clearly define the move, you are not ready to automate it.

You are just emotionally attached to the demo.

Fourth: draw the line before it crosses one

This is where maturity enters the room.

Not everything should be automated.
Not everything should be agent-led.
Not everything deserves autonomy just because the prototype looked smooth in the review.

The real question is simple:

When may the agent proceed, and when must it ask?

Back to the onboarding example.

If the issue is a straightforward component mismatch, maybe the agent can suggest the correct component on its own.

If the issue touches legal copy, accessibility claims, pricing language, or a high-stakes conversion step, maybe it must stop and ask.

If the research evidence conflicts, maybe it must ask.
If the confidence is weak, it must ask.
If the proposed change alters the experience in a way that affects business rules, it absolutely must ask.

Microsoft’s Human-AI Interaction guidelines have aged well because they keep returning to this exact discipline: make the system’s capabilities and limits clear, support correction, explain why the system acted as it did, and scope the service when uncertainty is high. NIST’s AI Risk Management Framework takes the same problem seriously from a governance angle, framing AI risk management as something continuous rather than something you remember right before launch. (Microsoft)

This is not friction.

This is respect.

A good agent does not just know how to act.
It knows where its authority ends.

Fifth: design the bad day, not just the happy path

Here is one of my favorite little AI fantasies:

Teams spend weeks designing how the assistant should behave when everything goes right.

Then the first real project is messy. The research is incomplete. The design system is partially outdated. The team changed a pattern last week but forgot to document it. The model confidently flags the wrong thing.

And the agent says:

“Sorry, I didn’t understand that.”

Amazing.
What a contribution.

The real design test is not the smooth moment.
It is the awkward one.

If the agent is wrong, vague, outdated, or overconfident, what happens next?

In the onboarding example, maybe the agent should show which rule or source it used. Maybe it should surface uncertainty instead of hiding it behind polished language. Maybe it should let the designer reject the suggestion, preserve that decision, and learn which feedback matters next time. Maybe if it hands work off, it should carry the file context, rationale, and relevant evidence with it so the next human is not forced to start from scratch like some kind of SaaS groundhog day.

Microsoft’s guidance on fallbacks and handoffs is useful here because it emphasizes exactly that continuity: when the system cannot proceed confidently, it should preserve trust and context instead of dumping the user into a dead end. (Microsoft)

A handoff that loses context is not a handoff.

It is just a transfer of frustration.

Sixth: prove it did anything useful

This is the part that protects teams from their own excitement.

Because AI products can look smart long before they become useful.

The summary sounds sharp.
The panel feels premium.
The recommendations look polished.
Everyone leaves the meeting with that dangerous little feeling that innovation has occurred.

Meanwhile, nobody has checked whether the work actually got better.

So measure what matters.

Did design reviews get faster?
Did repetitive comments go down?
Did consistency issues get caught earlier?
Did accessibility defects drop?
Did designers actually trust the recommendations?
Did the agent reduce boring coordination work — or just add another layer of polished noise?

NIST’s AI RMF treats this kind of measurement as part of ongoing risk management, not an optional afterthought. NN/g is making a similar move in AI-era service design by arguing that teams need to care about automation effectiveness, data quality, and trust — not just whether the interaction felt clever. (NIST)

Because “it looked intelligent in the demo” is not a metric.

It’s a warning sign.

The real shift

I don’t think the future belongs to the teams that add the most agents.

I think it belongs to the teams that can answer six adult questions before the agent touches anything.

Not “Should the panel be on the right?”
Not “Can it sound more proactive?”
Not “Does the magic icon feel magical enough?”

The real questions are less glamorous and much more useful:

What exact job is the agent doing?
What context does it get before it speaks?
What actions is it actually allowed to take?
Where does its authority stop?
What happens when it gets things wrong?
How will you prove it helped?

That’s it.

If a team cannot answer those six clearly, the product is not agent-ready.

It is just a chatbot standing in front of unfinished product decisions and hoping the UI distracts you.

And that, honestly, is the shift.

Not from no-AI to AI.
From vibe-based product decisions to rule-based product design.

Because once agents enter the workflow, every weak decision gets exposed faster.

If the job is vague, the agent will improvise.
If the context is weak, it will guess.
If the actions are fuzzy, it will overreach.
If the boundary is unclear, it will cross one.
If recovery is missing, the human inherits the mess.
If there is no proof, the demo wins and the workflow loses.

That is the part I want readers to carry into their next design review, product discussion, or AI brainstorm.

Not a framework with a cute acronym.
Not another innovation ritual with sticky notes and synthetic confidence.

Just this review:

Job. Context. Actions. Boundaries. Recovery. Proof.

Run it before you ship anything “agentic.”
Run it before you let a model recommend, rewrite, approve, route, escalate, or act.
Run it before everyone falls in love with the prototype and forgets to ask whether the product actually knows its own rules.

Because this is still UX.

Just less innocent.

For years, we were rewarded for making complexity look calm on the surface.

Now we have to do something harder.

We have to make the system itself behave with clarity.

Not just cleaner screens.
Clearer rules.

Not just better prompts.
Better product decisions.

Not just more helpful agents.
More honest products.

So if you want one thing from this article, take this:

Before you give the agent keys, make sure you can answer the six adult questions.

What is the job?
What does it know?
What can it do?
Where must it stop?
How does it fail?
How will you know it helped?

If the house has no rules, the smartest guest in the world can still break it.

And a bad agent is rarely just a model problem.

More often, it is a confused product with a confident voice.

Before You Give the Agent Keys, Make Sure the House Has Rules was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s a moment I’ve seen in far too many enterprise products.

An operator is sitting in front of six tabs.
One system for alerts.
One for notes.
One for context.
One for communication.
One for reporting.
And one mystery tab that has somehow become “part of the process” even though nobody officially owns it.

Everybody in the room calls this work.

Sometimes, it is.

But sometimes, it’s just a human being doing what the system never learned to do for itself.

Reading one thing.
Translating it into another.
Checking whether the tags match.
Copying context from one surface to the next.
Holding the logic together with memory, caution, and just enough fear of making the wrong call.

I’ve watched teams spend hours polishing the visible part of that workflow.

Should this button be more prominent?
Should this panel collapse by default?
Should this chip be blue, purple, or “something more actionable”?

Meanwhile, the deeper problem sat quietly underneath the UI like a bored villain:

The system itself didn’t understand its own work.

It didn’t clearly model the object.
It didn’t clearly express the state.
It didn’t clearly define what an action meant, when it should be available, or what should happen after it ran.

So a human stepped in and became the missing logic.

The human became the middleware.

That line sounds dramatic until you watch real people work.

And that is why I think we’re entering a more important shift than “AI in UX” or “chat is the new interface” or whatever shiny phrase is winning this quarter.

The real shift is this:

We need to start building products that are not only easy for humans to use, but also clear enough for agents to understand, navigate, and act inside safely.

Not because humans are disappearing.
Not because interfaces are dying.
But because too much of modern software still depends on people doing background orchestration that software should have been designed to handle in the first place.

That’s what makes this moment real.

Today’s leading systems can already inspect screens, use tools, follow multistep instructions, and complete tasks inside interfaces. They are still imperfect, still slow in many environments, still prone to mistakes. But the direction is obvious: software is moving from answering questions to helping execute work.

And if software is starting to act, then design has to care about something deeper than usability alone.

It has to care about interpretability.

For years, our craft centered on a familiar question:

Can the user understand this?

That question still matters.
It always will.

But now there’s a second one sitting beside it:

Can an agent understand this well enough to act without creating chaos?

That changes the brief.

Because agents do not experience your product the way users do.

They do not admire hierarchy.
They do not feel reassured by tasteful spacing.
They do not pause to appreciate that you finally fixed the awkward empty state illustration from Q3.

They care about something else.

They care whether the system is structurally legible.

What is this thing?
What state is it in?
What actions are possible?
What are the rules?
What requires permission?
What creates risk?
What can be undone?
What needs review?

Humans can often survive messy meaning.

Agents expose it.

That’s why I don’t think the next design frontier is “more AI features.”
I think it is agent-readable product architecture.

And yes, that sounds less sexy.
Which is exactly why it matters.

The next great product advantage may not be a prettier dashboard or a smarter assistant voice.

It may be a system whose underlying logic is so well-structured that an agent can move through it cleanly, safely, and usefully on behalf of a human.

That means clearer states.
Better object models.
Explicit action design.
Permission boundaries.
Fallback paths.
Confidence signals.
Auditability.
Memory that carries context without carrying confusion.

In other words, we are no longer just designing screens.

We are designing systems of meaning.

What “context for agents” actually looks like

This is where the conversation usually becomes fuzzy.

People say, “We should give the agent more context,” as if context is some magical dust you sprinkle on top of a prompt and suddenly the system becomes wise.

That’s not context.

That’s wishful thinking.

Real context is structured.
Specific.
Timely.
Useful to the task.

Let’s make it concrete.

Imagine a customer support workspace. A user is already logged in. They’re on the billing page, they have an enterprise plan, the account shows two failed payments, and they opened chat after reading the invoice history section.

A weak assistant still begins with the digital equivalent of forgetting your name at dinner:

“Can you share your account ID?”
“What seems to be the issue?”
“Are you asking about billing or subscription?”

That is not intelligence.

That is amnesia with a friendly tone.

An agent designed with context would begin differently.

The system would pass structured signals like:

• account type: enterprise
• current page: billing
• recent event: failed payment
• open invoices: 2
• intent signal: clicked “payment issue” help entry

Now the agent can start where the user actually is:

“I can see you’re on the billing page and there were two failed payment attempts on the account. Do you want help retrying the payment method, downloading the invoices, or checking whether service access is at risk?”

That one shift changes everything.

The agent is no longer guessing.
It is entering the conversation already briefed.

That is what context means in practice.

Not dumping more text into the model.
Not forcing the user to repeat what the system already knows.
But giving the agent the right state, the right signals, and the right business facts at the right moment.

The smartest agent is often not the one with the biggest model.

It’s the one that walks into the task already understanding the room.

And this is the part I think many teams will underestimate.

They’ll add an assistant.
Maybe a side panel.
Maybe a prompt box.
Maybe a magical summary card with sparkles and confidence percentages.

But if the underlying product is ambiguous, the agent won’t become intelligent.

It will become expensive confusion with a pleasant tone.

And this is where the conversation needs maturity.

“Build for agents” does not mean “stop designing for humans.”
That would be lazy thinking.

Humans are still where judgment lives.
Humans are still where accountability lives.
Humans are still where trust is won or lost.

The future is not agent instead of user.

It is agent on behalf of user.

That difference matters.

It means the visible interface becomes less of a place for manual stitching and more of a place for oversight.

Less operational clicking.
More reviewing, steering, approving, and stepping in when the stakes are real.

That is a much better future than the usual AI fantasy.

Not because it removes people.
Because it removes the nonsense we’ve been asking people to do.

Less tab juggling.
Less context copying.
Less human glue holding fragmented workflows together.
More time spent on judgment, prioritization, exception handling, and actual decision-making.

And maybe that is the real design challenge ahead.

Not how to make AI look helpful.
How to make systems become understandable enough that help is actually possible.

For years, we designed for what users could see.
The next era will belong to teams who also design for what systems can understand.

Because increasingly, user-centered outcomes will depend on agent-centered foundations.

The interface is not disappearing.

It is simply no longer the only audience.

Users Were the Interface. Agents Will Be the Workflow. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

“Design isn’t just about what you create.
It’s about teaching others — even machines — how to create with you.”

The Day I Realized I Was Designing with AI, Not for AI

A few months ago, I found myself arguing with an AI model about spacing.

Yes, spacing.

I asked Figma Make to generate a dashboard layout, and what it produced was almost perfect — except the cards didn’t align on the baseline grid. It wasn’t wrong, but it felt wrong.

That was my “aha” moment.

I realized the AI wasn’t the problem — my design system was.

It knew what a card looked like, but not what a card meant. It didn’t understand why 8px mattered, or how spacing affects rhythm, perception, and flow.

That’s when I started building what I now call High-Fidelity Design Guidelines — a set of rules, stories, and design truths meant for both humans and machines.

Because if AI is our new design partner, it deserves the same clarity and empathy we give our teammates.

1. Components Are Not Just Blocks — They’re Conversations

When I started documenting our design system for AI integration, I realized something profound:
Every component is a conversation between intent and implementation.

Humans intuit meaning — AI does not.

So I began treating components like contracts:

• What are its parts?
• What can change and what must stay fixed?
• How does it behave in different states?
• How should it describe itself in metadata so AI can “read” it?

I started writing descriptions like this inside Figma:

“Use this modal for confirmation actions only. Always include a dismiss button. Do not nest modals.”

Simple. Obvious. Yet this one sentence stopped dozens of inconsistent AI outputs.

I used to think style guides were for humans.
Now I know — clarity is kindness, even for machines.

2. Design Tokens: Teaching AI Your Brand’s Language

The first time our AI used our brand’s primary blue as an error state, I almost cried.

That’s when I realized — tokens aren’t “variables.” They’re vocabulary.

When we talk about “semantic tokens,” we’re really defining meaning.
Instead of blue-500, we now use brand-primary. Instead of gray-100, it’s background-neutral.

Suddenly, AI started “speaking” in the right tone — not because it understood color psychology, but because we gave it the words to describe emotion through design.

Tokens are the grammar of design.
The more structured they are, the more fluent your AI becomes.

We even added “purpose” notes in the token definitions — not just “what color,” but “why this color exists.”

And that “why” changed everything.

3. Accessibility: The First Rule of Designing for Intelligence

When I asked AI to generate a login screen, it gave me a clean, modern layout — perfect alignment, beautiful hierarchy… and text that failed contrast ratios miserably.

That’s when it struck me:
AI doesn’t know empathy. It only knows patterns.

So we baked accessibility into the system itself:

• Accessible contrast built into token pairs
• Keyboard navigation defined per component
• Focus states visually and semantically defined

We even wrote prompts like:

“Ensure color combinations meet WCAG 2.1 AA contrast requirements.”

The AI didn’t just follow the rule — it learned to suggest corrections when I broke them.

That’s when accessibility stopped being compliance — and became culture.

4. Branding Is Not Decoration — It’s Emotional Logic

In our company, branding used to live in marketing slides.
Now, it lives inside our AI.

We defined how the brand feels in tokens, fonts, and even micro-interactions.
Every color tells a story; every icon has intent.

When I gave AI the task to “design a pricing page,” it didn’t just pick colors — it picked emotions.

Because we had taught it the emotional logic of the brand:

• Blue is confidence.
• Yellow is warmth.
• Motion should be subtle, reassuring, not flashy.

Design is emotion structured into logic.
AI can’t feel, but it can follow feeling when we codify it right.

5. Voice and Tone: The Human Soul in Machine Dialogue

One of my proudest design moments wasn’t visual at all — it was linguistic.

We defined our AI assistant’s persona:

“A helpful colleague. Confident, polite, slightly witty, but never sarcastic.”

And suddenly, its replies started sounding like us.

When a user made a mistake, it didn’t say:

“Error 400: Invalid input.”
It said:
“Hmm, that doesn’t look right. Want me to fix it?”

The personality wasn’t hardcoded — it was guided.

We even mapped tones by context:

• Encouraging during onboarding
• Neutral and concise in work mode
• Empathetic in errors

It wasn’t just a chatbot anymore.
It was an extension of our brand’s humanity.

6. Interactions for AI-Driven UX: Designing for Transparency

When AI became part of the workflow, users began to ask a new kind of question:

“Why did the AI do that?”

So we started designing transparency into interactivity:

• A small “AI” tag on generated content
• Optional “Why this suggestion?” tooltips
• Confirmation modals for any irreversible action

Trust doesn’t come from perfection.
It comes from understanding behavior.

If you can explain what AI did — and why — users stop fearing automation and start trusting augmentation.

7. My Biggest Lesson: You Don’t Design Screens Anymore — You Design Systems That Design Screens

Somewhere between writing token specs and testing prompt consistency, I realized something humbling:

I wasn’t designing the product anymore.
I was designing how the product designs itself.

And that’s the future of design systems — not static documentation, but dynamic logic that enables creation.

We are no longer the sole authors of design; we’re the teachers of intelligence.

“Design systems used to scale teams.
Now they scale intelligence.”

Reflections: From Rules to Relationships

When people ask me if AI will replace designers, I always smile.

No.
But it will mirror us.

It will reflect our clarity, our intent, and our blind spots.

And if we don’t define the soul of our systems, the machine will fill it in for us — with cold logic and missing empathy.

So our role isn’t to control AI, but to guide it.
To teach it what we already know — that good design isn’t just functional, it’s felt.

✦ Closing Thought

Designing for AI is not about automation.
It’s about communication.

When we document our systems with care — from tokens to tone — we’re not writing manuals.
We’re writing love letters to clarity.

Because someday soon, AI won’t ask us what to build.
It’ll ask us why.
And that’s when it will finally understand design.

Designing for the New Design Partner: High-Fidelity Guidelines for AI-Native Systems was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.