Surface
--theme-bg-primary #001408Design Technologist · Agent-Driven UX
Agent UI Pattern Library
A Design Technologist Case Study
Executive Summary
The Agent UI Pattern Library is a single-file, interactive starter kit of
nine production-ready interaction patterns for AI-native, agent-driven experiences. Streaming output, tool-call
transparency, thinking and planning states, a confidence indicator, a human-in-the-loop interrupt, an honest
error state, an async result card, an empty state, and a multi-agent pipeline. Each pattern is rendered live in
the page, not mocked up flat, and every one is built on Kong's real production design tokens,
the --theme-* palette and the Funnel typeface verified against konghq.com's live stylesheet.
This is a Design Technologist piece, framed for the work the role actually does: establishing how a company designs for AI-native and agent-driven surfaces, shipping prototyping starter kits and conventions, and reducing the drift between design and implementation systems. The library is that starter kit, expressed in the design system it would ship into, and it clears the accessibility bar I hold every artifact to: zero axe-core violations across both the light and dark themes, with Lighthouse 100s for accessibility, best practices, and SEO.
Why Agentic UX Needs Its Own Pattern Language
Conventional UI patterns assume a deterministic system: the user acts, the system responds, the response is known. Agent-driven software breaks all three assumptions. The agent acts on its own initiative, the response streams in over seconds rather than arriving at once, and the output is probabilistic, sometimes wrong, and occasionally requires a human to step in before it executes. A button, a modal, and a toast do not cover that.
The questions an agent interface has to answer are new. What is the agent doing right now, and why? How far along is a multi-step task? How much should I trust this particular answer? This action is irreversible, so do you want me to proceed? Each of those is a distinct interaction problem with its own affordances, and answering them ad hoc, screen by screen, is exactly how a product accumulates drift. A shared pattern language is the fix: it names the problem, fixes the interaction decision once, and bakes the accessibility consideration in so it is not relitigated on every surface.
That is what this library is. Not a mood board of agent screens, but a set of decisions a team can adopt, each tied to the problem it solves and the design system it lives in.
The Nine Patterns
The library groups the patterns into four families: output, loading and progress, trust and control, and results and architecture. For each, the catalog below states the problem it solves, the interaction decision, and the accessibility consideration that made it onto the page.
01 · Output Patterns
01Streaming Text Output
Problem Generation takes seconds and the user needs to see progress, not a frozen panel.
Decision Render tokens in real time with a blinking cursor signaling active generation, and set model output in monospace so it reads as distinct from UI chrome.
A11y The block carries role="status" so a screen reader announces the streamed result, and the cursor is aria-hidden decoration.
02Tool Call Transparency
Problem Agents call tools the user cannot see; an opaque agent is an untrustworthy one.
Decision Surface each tool call as a collapsible row with a lifecycle status badge (done, running, queued, error), so the user can see what the agent did and why without drowning in detail.
A11y The headers are real <button> elements with aria-expanded, and the running badge pulses its background tint rather than text opacity, so contrast never drops below AA mid-animation.
02 · Loading and Progress
03Thinking State
Problem Indeterminate waits cause spinner anxiety; a bare spinner says nothing.
Decision An ambient bounce indicator paired with a descriptive label that names what the agent is working on, with the Kong lime accent appearing only on the bounce peak so the brand reads without overuse.
A11y The animated dots are aria-hidden; the descriptive label inside a role="status" region carries the meaning.
04Step-by-step Planning
Problem Multi-step agent work is a black box; the user cannot tell where it is.
Decision An ordered plan with live per-step status (complete, active, pending). Completed steps reassure, the active step shows progress, and nothing blocks the UI while it runs.
A11y The plan is a semantic <ol> so the order is conveyed structurally, not just visually.
03 · Trust and Control
05Confidence Indicator
Problem A single answer hides how sure the agent is, and users cannot calibrate trust without that signal.
Decision Per-dimension confidence bars mapped to Kong's success, lime, and error semantics for high, medium, and low, so the colors mean the same thing here as everywhere else in the system.
A11y Each bar is a role="meter" with aria-valuenow / min / max and a labelled dimension, so the value is exposed without relying on color alone.
06Human-in-the-loop Interrupt
Problem Some agent actions are high-stakes and irreversible; they must pause for a human before executing.
Decision A lime-bordered block that reads as an active request rather than passive information, with a three-choice affordance covering approve, adjust, and stop the agent.
A11y All three are real <button> elements with a visible lime focus ring; the decision is never gated behind a color the user might not perceive.
07Agent Error State
Problem Agents fail, and a vague failure is worse than none; the user needs to know what broke and what to do.
Decision Honest failure with context: what failed, why, a machine-readable error code for engineering handoff, and retry plus escalate paths that cover most recovery.
A11y The block is role="alert", and the error code uses a tone that holds AA on the near-black surface rather than the raw saturated red, which fails as small text.
04 · Results and Architecture
08Async Result Card
Problem Async work finishes out of band, and the result needs to land as something scannable.
Decision A key-value card that maps to the API response shape, with lime and green semantics separating primary metrics from health signals.
A11y Status colors are rendered at AA-safe tones on the card surface, and the key-value pairs read as labelled values rather than color-coded swatches.
09Empty State
Problem An empty agent surface is a dead end unless it tells the user what to do next.
Decision Direction over decoration: the empty state answers "what do I do next?" with a purposeful icon and a single primary action, not an ornamental void.
A11y The icon is aria-hidden; the title and the action carry the meaning, and the action is a real button.
10Multi-agent Pipeline View
Problem Orchestrated multi-agent work has many moving parts, and the user needs to see where the work is in flight.
Decision A compact linear pipeline whose node states (done, active, idle) show progress at a glance, sized to embed in a sidebar or status bar. It scrolls horizontally inside its own track rather than pushing the page.
A11y The pipeline is a role="list" of nodes; the arrows and glyphs are decorative and hidden from assistive tech.
Why ten entries, nine patterns
The catalog numbers run to ten because tool-call transparency and the streaming output sit together in the output family, but the library is described as nine patterns: the planning and thinking states are two expressions of one loading-and-progress idea. The grouping is what matters, not the count. The point is a coherent family, not a checklist.
Built on Kong's Real Design Tokens
The thing that makes this a starter kit rather than a one-off is that it is design-system-native. The patterns are not painted in a plausible green; they are built on Kong's actual production tokens, so they drop straight into Konnect-style surfaces with zero design drift between Figma and code.
Every hex in the library was confirmed present in Kong's live production stylesheet, the Next.js build served
from konghq.com, and the CSS variable names mirror Kong's real --theme-* custom properties. The
brand typeface, Funnel, is verified as --font-family-funnel in that same CSS and
is loaded here as the display and body face. This is not a guess at the brand; it is the brand, reproduced
honestly.
The Token Reference section at the end of the library lists eleven verified values with their swatches. Two of them, the lime accent and the error red, are surfaced at full saturation for swatch fidelity but rendered as text at AA-compliant tones everywhere else on the page, because they fail contrast as small text on the light surfaces. That distinction, a token can be correct as a swatch and wrong as body text, is the kind of decision that separates design-system fidelity from accessibility theater.
The Accessibility Bar
An accessibility-branded portfolio cannot ship an inaccessible artifact, so the library was hardened, not just
styled. The page carries a real document structure: lang="en", a skip link, a single <main>,
section landmarks with aria-labelledby, and an ordered heading sequence. Decorative SVGs, cursors,
and glyphs are all aria-hidden; interactive controls are real buttons with a visible lime
:focus-visible ring; the demonstration no-ops carry type="button" so they never submit.
The hard-won fixes were in the color. The brief flagged two suspects that actually passed, and the real
offenders were elsewhere: a border token reused as label text at roughly 1.5:1, small status text on the dark
header and footer at 2.2:1, and badge text over translucent tints that axe composites onto the card. Each was
remapped to an AA-safe tone, and a new --kong-text-muted token replaced the border-as-text pattern.
One animation, a running badge that pulsed its opacity, was sampled by axe at the dim end of the pulse and failed;
it now pulses the background tint and holds the text fully opaque.
Verified result
Axe-core ran via Playwright against both the light and dark themes: zero violations in each. Lighthouse
returned 100 for accessibility, best practices, and SEO. The page also ships a print stylesheet and respects
prefers-reduced-motion, flattening every animation for users who ask for it.
I Build the Tools, Not Just the Mockups
This is the thesis behind every piece in the lab, and it traces directly to the Friction Inversion methodology: move the friction so correct behavior is the path of least resistance. A pattern library that lives as static Figma frames asks every engineer to re-derive the same decisions; the friction is on the correct path. A pattern library that ships as working, tokenized, accessibility-clean code puts the friction on the wrong path instead. Copy the pattern and you inherit the right semantics, the right tokens, and the AA-safe colors for free.
That is the Design Technologist remit: not to hand off a picture of a system, but to build the system other people build on. This artifact demonstrates it on the exact surface the role asks for, AI-native and agent-driven UX, in the exact design system it would ship into. It is production-quality, verified against the real brand, and accessible by construction.
Live Artifact
Nine patterns, four families, one accessible starter kit. Open it, toggle the theme, and read the Token Reference at the foot of the page.