How interfaces change when agents are the primary actors, and why the design-to-code transition is being rebuilt from scratch. Companion to
problem-space.mdPhase 4 (Design) andstrategic-insights.md(Design Phase Gap).
Last updated: 2026-04-13
## Part 1: Agentic UX Patterns — Designing for Agent-First Products
This is the "AU design" sub-discipline called out in the problem-space map. As of April 2026, the patterns are crystallizing fast.
### The Six Core Patterns (Smashing Magazine Framework)
The most complete pattern library for agentic UX comes from Smashing Magazine's February 2026 deep-dive. These patterns map to three phases of any agent interaction:
Pre-Action Phase: Establishing Intent
1. Intent Preview (Plan Summary)
The foundational pattern. Before any autonomous action, the agent summarizes what it plans to do in clear, jargon-free language. User chooses: Proceed, Edit Plan, or Handle Myself.
Example: A travel assistant detecting flight cancellation shows:
- → Cancel original flight and process refund
- → Rebook next available non-stop flight
- → Update hotel reservation with late arrival
- → Send updated itinerary
Success metrics:
- → Plans Accepted Without Edit > 85%
- → Override Frequency < 10%
When it's non-negotiable: Irreversible actions, financial transactions, information sharing, significant changes.
Atelier implication: Every card type is an Intent Preview. A research card shows "I'll investigate X, Y, Z" before starting. A backend card shows "I'll create these endpoints with these schemas" before generating code. The card IS the plan summary — morphed to the task type.
2. Autonomy Dial (Progressive Authorization)
Users define preferred autonomy per task type. Four tiers:
| Level | Agent behavior | User role | |-------|---------------|-----------| | Observe & Suggest | Notifies but never proposes | Full control | | Plan & Propose | Creates plans for review | Approver | | Act with Confirmation | Prepares familiar tasks, awaits final ok | Supervisor | | Act Autonomously | Executes pre-approved tasks, notifies after | Auditor |
Critical detail: The dial must be per-task-type, not global. You might want autonomous scheduling but manual-review email sending. Nuanced trust differences.
Success metrics:
- → Setting Churn rate (monthly changes per user) — high churn means volatile confidence
- → Trust Density breakdown (% of users per setting)
Atelier implication: Each card type can have its own autonomy level. Research cards might be "Act Autonomously" (low risk). Backend cards with database changes might be "Act with Confirmation" (high risk). This is a natural extension of card-type morphing.
In-Action Phase: Providing Context
3. Explainable Rationale
Proactively answers "Why?" with concise justification grounded in user preferences and prior decisions.
Design principle: Ground explanations in user precedent: "Because you said X, I did Y."
Atelier implication: The memory rail connects here. When an agent makes a decision, the rationale references project memory: "Using PostgreSQL because the research card on database options concluded X." Memory becomes the source of rationale.
4. Confidence Signal
The agent surfaces its own certainty levels. Methods:
- → Percentage-based scores ("Confidence: 95%")
- → Scope declarations ("Scope: Travel bookings only")
- → Visual indicators (green check = high, yellow question = uncertainty)
Target: Pearson correlation > 0.8 between model confidence and user acceptance.
Atelier implication: Card status-as-glow from the existing design system maps directly to this. A card glowing amber could mean "working but uncertain" — prompting the user to review before proceeding.
Post-Action Phase: Safety and Recovery
5. Action Audit & Undo
Persistent chronological logs with time-limited undo. The ultimate safety net enabling delegation.
Key insight: Knowing mistakes can be easily reversed creates psychological safety, which is what enables users to increase autonomy over time. Without undo, users stay at "Plan & Propose" forever.
Success metrics:
- → Reversion Rate > 5% → disable automation for that task type
- → Safety Net Conversion: users upgrading to autonomous mode after successful undo
Atelier implication: The board IS the audit log. Each card's history is visible. Git-backed undo is already in the architecture. The missing piece: making the undo affordance prominent and time-windowed.
6. Escalation Pathway
Agent recognizes uncertainty and escalates rather than guessing. Patterns:
- → Request clarification ("You mentioned 'next Tuesday' — do you mean September 30th or October 7th?")
- → Present options for selection
- → Human intervention trigger ("This seems unusual; shall I flag for review?")
Healthy range: 5-15% escalation frequency. Too low = agent overconfident. Too high = agent useless.
Atelier implication: A card that "blocks" and requires human input is an escalation. The board should visually distinguish blocked-on-human cards from actively-working cards. This is already partially in the PRD with status indicators.
### The Governance Layer
Effective agentic UX requires:
- → Autonomy Policy Documentation — formal constraints per task type
- → Agent Risk Register — proactive failure modes
- → Action Audit Logs — regular review
- → Cross-functional oversight (legal, product, UX research, engineering, support)
### The Implementation Roadmap Pattern
The pattern across all agentic UX frameworks:
Phase 1: Foundational Safety — Intent Preview + Action Audit + Undo. User comfort with proposals while maintaining full control.
Phase 2: Calibrated Autonomy — Introduce Autonomy Dial. Deploy Explainable Rationale. Users self-pace trust escalation.
Phase 3: Proactive Delegation — Enable autonomy only after Phase 2 demonstrates confidence. Target low-risk pre-approved tasks first.
Key principle: "Autonomy emerges from technical capability, but trustworthiness stems from intentional design."
## Part 2: Generative UI & Agent-Driven Interfaces
### The A2UI Protocol
A2UI (Agent-to-User Interface) is an open-source spec enabling agents to generate interactive UI through declarative JSON rather than code. This is the technical answer to "how do agents control what the user sees?"
The problem it solves: "The Chat Wall"
Traditional conversational AI hits limits when requiring structured input or complex output. A restaurant booking needs "What day? What time? How many?" — much better as a form than a chat exchange.
How it works:
Agent Reasoning → Emit (JSON message) →
Client Renderer → Render (native UI components) →
User Interaction → Signal (typed event, not free text) →
Agent Reasoning (cycle repeats)
Security model: Agents can only request components from a client-approved catalog (Card, Button, TextField, etc.). No arbitrary code execution — declarative data, not imperative HTML/JS.
| Aspect | A2UI | HTML/iFrames | |--------|------|-------------| | Format | Declarative JSON | Imperative HTML+CSS+JS | | Security | High (approved components only) | Low (remote code risk) | | Cross-Platform | Native rendering on all platforms | Browser-engine dependent | | LLM-Friendly | Simple JSONL, incremental streaming | Complex, error-prone |
Companion protocol — AG-UI:
- → A2UI defines content (UI structure via JSON)
- → AG-UI defines transport (bi-directional, real-time communication)
- → Together: streaming agent-generated interfaces with structured user responses
Atelier implication: Atelier's morphing card types are a custom implementation of this same concept — the workspace changes shape based on the task. A2UI validates the pattern technically. Atelier's advantage: the rendering is opinionated (design taste) rather than generic (protocol-driven). But understanding A2UI matters because:
- → If A2UI becomes a standard, Atelier could emit A2UI-compatible card definitions
- → Agent-authored cards could use a subset of A2UI for extensibility
- → The "trusted component catalog" model maps to Atelier's card-type system
### Generative UI (Broader Pattern)
Generative UI = parts of the interface generated, selected, or controlled by an agent at runtime rather than being fully predefined.
Real-world example: An agent dynamically switches UI based on intent:
- → "Product Search" → renders Comparison Table
- → "DIY Project" → renders interactive Timeline/Checklist
- → "Data Analysis" → renders Chart + Filter Panel
This is exactly what Atelier's card-type morphing does — the difference is that Atelier predefines the card types with craft, while Generative UI generates them on the fly. The hybrid: predefined card types for common tasks (research, backend, design) with a generative fallback for novel task types.
## Part 3: The Design-to-Code Handoff Revolution
### What Changed in 2026
February 26, 2026: OpenAI and Figma announce partnership embedding Codex directly into design-to-dev pipeline.
One week later: Figma announces integrations with BOTH OpenAI Codex and Anthropic's Claude Code via MCP.
The new paradigm: Design-to-code is no longer about exporting specs. It's about agents reading the design file directly and generating code from native Figma properties — variables, design tokens, components, variants, auto layout rules.
### How Figma MCP Works
The Figma MCP server provides five tools:
- →
get_design_context— reads a Figma file and extracts layout, components, tokens - →
get_variable_defs— extracts design system variables - →
get_code_connect_map— maps Figma components to code components - → Plus write capabilities (beta): create/modify frames, components, variables directly
Two approaches:
- → Official Figma MCP (beta, requires Dev seat): tight integration, supports Code Connect
- → Framelink MCP (community, free): uses Figma API, extracts layout JSON + image assets
### What Actually Breaks
Even with MCP, the handoff is far from solved:
1. Design System Disconnection Generated output doesn't use design system components. Colors are hard-coded. Typography overrides system defaults. CSS is written manually where it shouldn't exist. The model has no understanding of what the design system is unless explicitly told.
2. Code Connect Scaling Problem The official MCP server requires mapping each Figma component to codebase components — manual work that doesn't scale for large design systems. Framelink lacks this feature entirely.
3. Token Extraction Gaps
Figma's raw style export doesn't always honor semantic relationships. Agents extract primitive values instead of design token references (e.g., #3B82F6 instead of --color-primary).
4. Responsive Behavior Auto layout captures flexbox relationships, but complex responsive breakpoints and media query logic require explicit documentation within Figma. Agents can't infer responsive behavior from a single frame.
5. State Management Figma captures static variants (default, hover, loading). Dynamic interactions (transitions between states, animation timing, gesture responses) need additional context through annotations or Code Connect metadata.
6. The Accuracy Gap Even with perfect Figma files, generated code provides a "useful starting point" that requires manual adjustments for production. Corner radii repositioned, spacing misaligned, component structure flattened.
### What Does Work
The fundamental insight from LogRocket's analysis:
"Design habits like thoughtful layer naming, consistent use of components, auto layout, and mapping text, color, and spacing values to local variables have become the very foundations that enable coding agents to accurately implement our designs."
Good design system hygiene has always been best practice. Now it's a prerequisite for AI-assisted development. The designers who follow these practices get dramatically better agent output. The ones who don't get garbage.
Success factors for near-perfect output:
- → Structured component libraries with named variants
- → Figma variables storing semantic design tokens
- → Auto layout for all responsive containers
- → Clear layer naming and hierarchy
- → Code Connect mappings for component → code references
### Rate Limiting and Cost
- → Starter plan / View seats: limited to 6 MCP tool calls per month
- → Dev seat required for full access
- → Write features will eventually be usage-based paid (currently free beta)
## Part 4: What This Means for Atelier's Design Phase
The problem-space map identified the Design Phase as a gap:
"Every tool is engineering-first. None center design."
The research deepens this into three specific opportunities:
### Opportunity 1: Agent-Readable Design Specs
If Atelier's cards generate structured design specs (not just task descriptions), those specs become input for Figma MCP and Code Connect. The card produces a design spec → Figma MCP reads it → agent generates code that matches the design system.
What this looks like: A design-flow card doesn't just describe "build a checkout flow." It produces:
- → Component list with variant states
- → Design token references (not raw colors)
- → Auto layout specifications for responsive behavior
- → Interaction specifications (hover states, transitions, timing)
- → AU (Agentic User) specifications — how agents will interact with the built product
This is the spec-as-memory concept applied to design.
### Opportunity 2: The Taste Layer
The research confirms: "When average output becomes easier to generate, taste becomes more valuable" (Figma 2025 report). Atelier's design taste IS a moat because:
- → Generated code quality correlates with design file quality
- → Most developers don't know how to structure Figma files for MCP
- → Atelier can encode design best practices into its card-type templates
- → The product itself demonstrates the craft standard
### Opportunity 3: Animation & Interaction as First-Class Concerns
Current state: "AI can write Framer Motion code, but it can't judge whether a 200ms spring vs a 300ms ease-out feels right."
Nobody has built a tool that treats animation specifications as structured data that flows from design → build → test. Atelier's animation rules (AnimationRules.md) already exist as a document. The opportunity: make them machine-readable card metadata that agents use when implementing.
## Part 5: The Linear Precedent — Issue Tracking → Agent Orchestration
### Linear's Pivot (March 2026)
Linear CEO Karri Saarinen declared "issue tracking is dead." Linear is repositioning from project management tool to agent orchestration platform.
Current state:
- → 25% of all new issues in enterprise workspaces are now created autonomously by agents
- → Coding agents installed in 75% of Linear enterprise workspaces
- → Agent workload volume up 5x in three months
- → Beta AI agent works across web, mobile, desktop, and Slack/Teams/Zendesk plugins
Planned features:
- → Coding agent to write code and fix bugs directly from issues
- → Codebase Q&A
- → Code diff presentation within Linear
- → MCP support (customer-requested)
- → Usage-based pricing beyond a threshold for advanced automation
Pricing: Skills and automations require Business ($16/user/month) or Enterprise plans.
### Why This Matters for Atelier
Linear's move validates the "orchestration hub" category — the idea that the tool where you track work naturally becomes the tool that manages agents doing that work.
The convergence:
- → Linear starts with issues → adds agents
- → Atelier starts with agents → adds project structure
- → They're approaching the same destination from opposite sides
The divergence:
- → Linear is team-scale, enterprise-focused, text-first
- → Atelier is solo/small-team, design-first, workspace-morphing
- → Linear treats agents as automation; Atelier treats agents as the primary worker with human curation
The risk: If Linear ships a compelling coding agent + MCP integration, it could absorb Atelier's orchestration value. Mitigation: Atelier's differentiation is in the phases Linear doesn't touch — research, design, memory, and the craft layer. Linear will never be a design tool. But it will be a strong orchestrator for the build phase.
Basecamp parallel: Basecamp is also pivoting to "agent-driven" with command-line access for any AI agent. The project management tool → agent orchestrator move is an industry trend, not a Linear-specific play.
## Part 6: The Solo Founder Workflow (Primary User Profile)
### The "Vibe CEO" Model (2026)
The research reveals a crystallizing pattern for how solo founders actually work with AI agents:
Daily workflow structure:
- → Morning review (2 hours) — review agent outputs from overnight/previous day
- → Deep strategy (3 hours) — architecture decisions, product direction, user research
- → Shipping (2 hours) — product updates, deploying, testing
- → Financial/planning (1 hour) — metrics, pricing, roadmap
Key shift: Solo founders spend 80% of time on strategy and high-judgment decisions, delegating execution to agents. "Direction over execution" is the operating philosophy.
Tool stack (typical):
- → Claude/ChatGPT for strategy and reasoning
- → Cursor/NxCode for development
- → Perplexity/NotebookLM for research
- → Make.com/n8n for automation
- → Midjourney for visual assets
- → Vercel/Stripe for infrastructure
- → Total monthly cost: $0-$500
### Context Engineering as Infrastructure
The biggest workflow evolution: solo founders now treat context as infrastructure, not conversation.
60,000+ GitHub repositories include agent instruction files (CLAUDE.md, AGENTS.md, .cursorrules).
What context engineering means in practice:
- → System instructions encoding architectural decisions
- → Retrieved documents (customer tickets, analytics, competitor research) auto-injected into agent context
- → Structured memory storing customer preferences, product decisions, brand guidelines
- → MCP servers connecting agents to live infrastructure
The "context engineering decay" problem: Context files are living documents requiring weekly reviews. Stale context produces stale agent output. Nobody has solved automatic context maintenance.
### Where the Solo Founder Workflow Breaks
The research identifies consistent pain points:
- → Tool fragmentation — 5-8 tools, none talk to each other, context dies at each boundary
- → Context engineering overhead — maintaining CLAUDE.md, .cursorrules, memory files across tools is manual
- → No unified "here's where my project is" view — project state is scattered across Linear, GitHub, Figma, Notion, terminal
- → Review bottleneck — solo founder is the only reviewer; agent output piles up while they sleep
- → Isolation/burnout — the "vibe CEO" model sounds efficient but is cognitively exhausting with no team to share decisions
### What Solo Founders Would Pay For
From the research:
- → Speed + not losing work (the #1 ask)
- → Unified project view across research, design, build, test
- → Memory that persists across sessions and tools
- → Cost tracking — knowing how much agent usage costs per feature/project
- → Quality gates — confidence that agent output is good enough to ship
Price sensitivity: $0-$150/month for tools. Free handles 80% of daily needs. Paid tools must justify with clear time savings.
## Sources
### Agentic UX
- → Designing for Agentic AI — Smashing Magazine
- → A2UI Protocol Guide — DEV
- → Generative UI Guide — DEV
- → Agentic Design Patterns — Medium/ProCreator
- → UX Design for Agents — Microsoft Design
### Design-to-Code
- → Structuring Figma Files for MCP — LogRocket
- → Figma MCP Server Guide — Figma
- → Figma MCP CTO Guide — Alex Bobes
- → OpenAI & Figma on Killing the Handoff — Product School
- → Figma AI Design Update April 2026 — DEV