[001] AI Is Executing. Nobody Is Defining What It Should Execute.
The models are powerful. The infrastructure is ready. But the most critical layer — the one that decides whether AI helps or harms — is missing from almost every product being built today.
Picture this.
A product team demos their new AI travel agent. It works. The model responds in 400 milliseconds. The booking goes through without a single error.
Then someone checks the result. The system just booked a red-eye through Atlanta for a user who explicitly hates layovers. It optimized for price. The user was optimizing for sanity.
The room goes quiet. Not because the technology failed. It didn’t. The silence is because everyone realizes the same thing: nobody told the system what mattered to the human on the other side.
The Gap Is Not Technical. It Is Human.
There is a gap at the center of almost every AI product shipping right now.
Not a compute gap. Not an infrastructure gap. Not a talent gap.
A translation gap.
Nobody has defined — with precision, with depth, with structural rigor — what the AI is supposed to accomplish for the person using it.
Not at the surface level. At the level that matters:
What is this person actually trying to achieve in their life? What does success feel like for them — not just look like on a dashboard? What do they want to keep in their own hands? What context would flip the entire equation?
This is the work that separates AI products people integrate into their lives from AI products people try once and delete.
This work has a name. It is design.
What AI Actually Needs to Serve Humans
An AI system that acts on behalf of users — booking travel, managing communication, executing tasks — needs more than instructions.
It needs a model of the human it serves.
Not a demographic profile. Not a marketing persona pinned to a whiteboard. A working model of:
The goal beneath the request. “Book a flight” is a surface instruction. “Arrive at my daughter’s recital feeling like the logistics didn’t consume my week” is the actual job.
What success really means. Functionally. Emotionally. Socially. How this person wants to feel and be perceived when the task is done.
The autonomy boundary. What they want to control themselves. Where they genuinely welcome delegation. These two zones are different for every person, every context, every level of trust.
The context triggers. When the same request means something completely different. A “quick dinner reservation” on a Tuesday night versus the night before an anniversary — same words, different universe.
Without this model, AI operates on the surface of requests. It does what was asked. Not what was needed.
The result is technically correct. Humanly insufficient.
Users feel that gap immediately. Even when they cannot name it.
Engineers Build Engines. Designers Build the Destination.
Here is why this is a design problem. Not an engineering problem. Not a product problem.
Engineers build systems that execute any instruction perfectly. What no engineering process produces is the translation of messy, contextual, emotionally charged human goals into instructions precise enough for a machine to act on well.
Product managers define features and prioritize roadmaps. What they do not do is sit with a user long enough to understand that the job is not “book a flight” but “protect my energy for the things that actually matter this week.”
This translation — from human intent to system behavior — is a design skill.
It requires methods designers have spent decades developing: deep user research, contextual inquiry, Jobs-to-be-Done analysis, the ability to construct accurate models of human motivation from incomplete and contradictory evidence.
It also requires something no method can teach: genuine curiosity about why people do what they do. And the patience to stay with that question until the real answer surfaces.
Designers carry this. It is what the profession has always cultivated — even when the output was “just” an interface.
Now the output is an AI system that acts in the world on behalf of real people.
The translation has never mattered more.
The Interface Was a Shock Absorber. AI Ripped It Out.
In the era of interface design, imprecision was expensive but recoverable.
A designer misread user intent. Built the wrong screen. Users hit friction. Some gave up. The product underperformed. The team iterated.
Bad, yes. But bounded.
A confused user clicked the wrong button. Saw an error message. Navigated back. Tried again. The interface — however flawed — gave them control over every step. It absorbed the designer’s mistakes like a shock absorber on a rough road.
When AI acts autonomously, that shock absorber is gone.
A misunderstood intent does not produce a confusing screen. It produces an AI that confidently does the wrong thing. Books the wrong flight. Sends the message the user was not ready to send. Makes the purchase the user was still considering. Optimizes for price when the user was optimizing for peace of mind.
And it does this at the speed of automation. Sometimes irreversibly. With the confidence of a system that has no idea it is wrong.
The buffer is gone. Imprecision is no longer absorbed by the interface. It becomes system behavior.
This is why the translation layer matters now more than at any point in design history. Not because understanding intent is a new idea. It has always been central to good design. But because the cost of getting it wrong has increased by an order of magnitude — and the cost of getting it right flows directly into whether the product works at all.
What I Found When I Went Looking
I have spent the past several years building AI systems inside large organizations — at Verizon, at Dyson, across multiple enterprise environments. I did not start with AI. I started with people.
At Verizon, I ran hour-long interviews with 16 designers. Not about AI. About their actual work. What surfaced: 40+ distinct friction points, ranked by severity and business impact. The AI architecture came from that diagnosis — not from whatever tools were available.
Here is what I have consistently observed:
The conversation about what the AI should do for users is almost always the shortest conversation in the room.
Engineers spend weeks on model selection and infrastructure. Product managers spend months on feature prioritization. Designers, when they are in the room at all, get brought in to make the interface look right — after the fundamental decisions about what the AI does and why have already been made.
The translation layer is being skipped. Or worse: filled in by assumption.
But the diagnosis revealed something I had not anticipated.
The translation layer does not just need to be filled. It needs infrastructure underneath it.
Teams were not failing because they lacked understanding of their users. Many had strong instincts about user intent. They were failing because the organizational knowledge that should have fed the translation — past decisions, research findings, contextual rationale — was scattered. Tribal. Inaccessible.
The translation layer was empty not from lack of skill. From lack of architecture.
So I built both. Knowledge infrastructure first — a three-layer system that made everything the organization knew queryable. Then the agents that operated on top of it: validation systems, edge case detection, strategic design scaffolding, and a thinking partner built for human-AI-human collaboration.
The result was not faster design. It was different design. More strategic. More considered. Operating at the level the role always should have required.
That work taught me what the abstract argument never could:
The translation layer is not a single act of understanding. It is an architecture.
It has components. It requires infrastructure. And those components can be named.
The Translation Architecture: Five Interlocking Systems
Through this work — and the thinking it forced — I arrived at a set of interconnected frameworks that give the translation layer structure.
System 1: Jobs-to-be-Done as Operating Instructions
JTBD has been a research framework for 30 years. In the AI era, it becomes something more direct: the operating instructions for how an AI system behaves.
The functional, emotional, and social dimensions of the job do not inform an interface. They become the parameters that govern system behavior.
SYSTEM SPEC: Intent Model
Inputs:
- User research (contextual inquiry, JTBD interviews)
- Behavioral data (usage patterns, abandonment signals)
- Contextual variables (time, environment, emotional state)
Output:
- Structured job statement with functional/emotional/social layers
- Success criteria (measurable, specific, testable by AI)
- Context triggers (conditions that change the job entirely)
Success Criteria:
- AI can act on the model without human clarification 80%+ of the time
- Users confirm the system “understood what I actually needed”
Constraints:
- Must update as user behavior evolves
- Must handle ambiguity gracefully (ask, don’t guess)
System 2: The Autonomy Map
Every job has parts worth delegating and decisions worth owning. The map between these two — for a specific user, in a specific context — determines where the AI acts and where it steps aside.
Most product teams never build one. They draw the line by default. Users feel the mismatch immediately.
System 3: The Autonomy Dial
Once something is delegated, how autonomous should the AI be? Four positions:
SYSTEM SPEC: Autonomy Dial
Positions:
1. SUGGEST — AI recommends, human decides and acts
2. CONFIRM — AI prepares action, human approves
3. NOTIFY — AI acts, human is informed after
4. AUTONOMOUS — AI acts, no notification needed
Calibration Inputs:
- Reversibility (can this be undone?)
- Familiarity (has user done this before?)
- Stakes (what’s the cost of getting it wrong?)
- Context (routine Tuesday vs. high-stakes Thursday)
Constraints:
- Not a single setting. A contextual, evolving calibration.
- Trust accumulates through consistent correct behavior.
- Dial moves toward autonomy as trust is earned, never assumed.
System 4: Knowledge Architecture
AI is only as good as the context it can access. The knowledge layer — structured, queryable, maintained — transforms a general-purpose model into something that can serve specific humans in specific situations.
Without it, the translation layer has nothing to work with.
System 5: Agentic UX Patterns
Six interaction patterns that create the conditions for earned autonomy:
SYSTEM SPEC: Earned Autonomy Patterns
1. Intent Preview — Show the user what you understood before acting
2. Autonomy Dial — Let the user adjust delegation levels
3. Explainable Rationale — Show why the AI chose this action
4. Confidence Signals — Communicate certainty levels honestly
5. Action Audit — Provide full history of autonomous decisions
6. Escalation Pathway — Clear route back to human control
Success Criteria:
- Users report feeling “in control” even when AI acts autonomously
- Trust metrics increase over time, not just at launch
- Recovery from errors is graceful, not catastrophic
None of these are theoretical. Each emerged from building systems that real people use. From watching where they succeeded. From understanding why they broke when they broke.
What This Means for Design: The New Deliverables
The translation layer is not an abstraction. It is a set of specific, buildable, testable artifacts that determine whether AI systems serve humans or merely respond to them.
Intent models that feed system behavior, not just interface decisions.
Job statements. Success criteria. Context triggers. Structured precisely enough that an AI system can act on them. These are not research documents. They are system specifications.
Autonomy architectures that earn trust over time.
Not a single setting. A designed relationship between what the AI does and what the human controls — calibrated by domain, by context, by the trust the user has actually developed through experience.
Knowledge infrastructure that gives AI real context.
Not a folder of documents. A living, queryable system that makes organizational intelligence accessible to every agent and every team member.
Agent designs scoped to specific structural roles.
Not “AI that helps.” Agents with defined inputs, defined processes, defined outputs — each filling a role that was previously unfilled.
This work happens before Figma opens. It determines the quality of everything built afterward. And it requires designers who operate at the level of systems architecture — not because interface craft is dead, but because the craft now serves a system that extends far beyond the screen.
The Claim, Stated Plainly
AI is the most consequential technology shift in design history.
Not because it threatens to replace designers. Because it creates a category of work that designers are uniquely equipped to do — and that no one else is doing well.
The work is translation. Taking the complex, contextual, human reality of what people are trying to accomplish and converting it into the precise, structured, operationalizable form that AI systems need to act well on behalf of people.
That translation has an architecture. Intent models. Autonomy frameworks. Knowledge infrastructure. Interaction patterns designed for earned trust. These are not peripheral additions. They are what determines whether an AI product works.
This translation is the difference between AI that serves humans and AI that merely responds to them. Between AI that earns trust and AI that produces impressive demos. Between AI that people integrate into their lives and AI that people try once and abandon.
The field is wide open. The frameworks exist. The work is available.
This newsletter is the map.
P.S. — I want to be honest about something. When I first started building AI systems, I did not think of myself as a “translation architect.” I thought of myself as a designer who happened to work on AI. The shift was not intellectual — it was visceral. I watched a system I helped build send a notification to a user at 11pm about a task they had deliberately postponed to reduce their stress. The system was “working correctly.” The user felt surveilled. That moment broke something in how I thought about my role. The technology was not the problem. The missing layer — the one that should have known what this person was actually trying to protect — was. I have been building that layer ever since. Some days I am not sure I have it right. But I am certain it is the work that matters most.
This is the thesis behind everything I write in Intent First. Each article goes deeper into one component of the translation architecture — from JTBD as system design language to Autonomy Maps, from Knowledge Architecture to the six patterns of Agentic UX.
If you are building AI products and the translation layer in your process feels thin — that is the conversation I find most valuable. Reach out.
#AIDesign #UXDesign #DesignLeadership #FutureOfDesign #IntentFirst #ProductDesign #AgenticAI