Cloudflare AI Agent Design

LLM AI Agent Design

Agent Lee is Cloudflare's in-dashboard AI agent, running against real production accounts for ~18,000 daily users at ~250,000 tool calls a day. It resets tokens, purges caches, deploys Workers. As the first product designer on the Agent Experience team, I worked in two stages: making one agent readable, then what happens when one becomes many.

Agent Lee is Cloudflare's in-dashboard AI agent, running against real production accounts for ~18,000 daily users at ~250,000 tool calls a day. It resets tokens, purges caches, deploys Workers. As the first product designer on the Agent Experience team, I worked in two stages: making one agent readable, then what happens when one becomes many.

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.

V1 โ€” Original Direction
V2 โ€” Final Direction
01 / 02

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.

Copyright ยฉ 2026 Linda-in-design. All rights reserved.