V1 โ Original Direction
Cloudflare AI Agent Design
LLM AI Agent Design
Client / Industry
Cloudflare / Internet Infrastructure
Linda's Role
AI Product Designer
Skills
Agentic Workflow Design, Human-AI Interaction, Intent Taxonomy, Prototyping
Date
Jun - Aug 2026
1,000+ real prompts analyzed
Intent taxonomy + behavioral analysis to map doing vs. asking
3 trust-critical fixes shipped
Finalizing state, answer identity, and collapsible reasoning - merged to prod
Prototype โ code โ staging
Built in real Cloudflare Kumo components, MR opened, verified live by engineers
01 The Gap โจโจ Chat has patterns. Agents don't. An agent thinks in public, acts in steps, asks for permission, and mutates live accounts. In 2026, there is no settled UX pattern for any of those four. Why it matters for Agentic Design: If users can't parse what the agent is doing, you get two failure modes: they stop trusting and abandon, or they approve what they don't understand. At Cloudflare scale, the second one takes a website down.

02 How I Worked (data-> design -> code) I queried the product data, cloned the dashboard to localhost, built the prototype, opened the merge request, and pushed to staging โ where seven engineers clicked a live link instead of reading a mockup. Every state was checked against Kumo, Cloudflare's design system, and every prototype rebuilt in real Kumo components โ so proposals arrived implementable, not as pictures someone had to translate. AI didn't replace those skills. It compressed the handoff loop. It can generate the code. Checking it against the system is still the designer's job.

03 Research: Who's Actually Askingโจand where I started with intent, not UI. I pulled 1,000 real prompts, removed empty sends / duplicates / internal tests, and classified by intent. Product analytics showed what they did (most never left the sidebar). Prompts showed why. Finding: Most users opened the panel and typed nothing. Those who did type weren't asking for explanations - they were asking the agent to do. And they prefer using sidebar than sphere mode to interact with Agent.

04 Stage 1 โ The Diagnosisโจ Reasoning was competing with the answer. I broke one response into its 4 states: user message, loading, reasoning, answer. Same width, same type scale, same weight. Reasoning filled the panel and pushed the answer below the fold. Users kept waiting after the answer had already arrived. Why we missed it: Full reasoning is useful for engineers to verify behavior. We had designed for ourselves, not for trust.

05 Stage 1 โ ๐ข What Shipped 3 incremental changes to make one agent readable: 1. A finalizing state. We had loading for mid-work, none for the end. Added finalizing โ endless wait became bounded. 2. An identity for the answer. Agent icon on the reply bubble. Reasoning stays openable, but the conclusion is now findable. 3. Named, collapsible steps. Fetching account data, loading zone settings, finalizing response. Closed by default, openable on demand. Impact: Three small, system-compliant changes written and merged by me - the readable foundation Stage 2 needed.


06 Stage 2 โ One Agent Becomes Manyโจโจ The next Agent Lee fans out work across parallel sub-agents. No one had drawn what that looks like in 400px. One agent = one line of work in a sidebar. Multiple agents = parallel, nested work where every step touches a live account. Stage 1 made thinking readable. Stage 2 has to make permission reversible.

07 Stage 2 โ I Drew the Wrong Version Firstโจโจ V1: Plan-first: A beautiful demo. Walkthrough with backend: To generate that plan, the agent must fetch + reason before acting. More logic, more latency, more risk. A wrong plan is worse than no plan. V2: Reason-as-you-go: Linear + gate. Agent responds as it already does, stops before any mutation. View details opens code. Undo actually reverses the work. Cloudflare's launch post says it plainly: the confirmation prompt isn't a UX courtesy, it's the gate. Designing that gate for sub-agents - where one approval can fan out into many actions - is Stage 2. Why V2 got selected? : It could be verified against backend behavior, and confirm-and-undo was the control the enterprise track needed. The truer version beats the impressive one.
08 What Worked, What Didn'tโจโจ What worked: โ Classifying real prompts before designing around team assumptions - intervention intent > explanation intent โ Shipping 3 small trust fixes vs. one big deck โ Prototyping in code - engineers argue with a live link, nod at a mockup What didn't: โ Drew V1 before understanding backend orchestration cost. One earlier conversation would have saved the detour. โ Opening more threads than I close. Convergence is harder than divergence. Takeaway: Every new agent capability is a new interface problem. I spent a summer on two: making one agent's thinking readable, and making a group of them safe to approve. In a space with no playbook, the verifiable version wins.

Password required for full design progress
This case study is password-protected. Enter the access password provided by the project owner.
