AI design tooling for AFT

The problem

Design demand across AFT far outpaces design headcount, and the gap keeps widening. The knowledge needed to design well was scattered across wikis, documents, dashboards, and internal tools: UX research, design system documentation, accessibility standards, and fulfillment operational context.

So builders duplicated research, reinterpreted standards inconsistently, and leaned on tribal knowledge to fill the gaps. Basic questions were expensive to answer:

• Where does relevant UX research already exist?
• What design system guidance applies to this use case?
• How do operational constraints affect this workflow?
• What standards or requirements must this design meet?

Left unchecked, that isn't just a builder problem. It compounds into the customer experience: inconsistent, harder-to-learn interfaces for the associates and operators who run fulfillment every day, and slower delivery of the improvements they need. Scaling design judgment was the way to protect both.

Approach

I designed and built the platform as a unified system that brings AFT's most critical design knowledge together and makes it usable through AI agents. It supports design work, but it was built for any AFT builder: engineers, product managers, program managers, and operations partners query the same source of truth and get answers grounded in shared standards, research, and operational reality.

1. A knowledge foundation, kept current

Content is structured into intentional domains (UX tenets and traps, design system documentation, UX research, accessibility standards, content guidelines, and fulfillment standard work) so semantic relationships are preserved and answers stay grounded. An automated sync pipeline keeps the knowledge aligned with its upstream sources, so guidance reflects the current standard rather than a frozen snapshot.

2. The intellectual depth behind the agents

The agents aren't a generic chatbot pointed at a document store. They reason over a layered system I helped shape: from a human-collaboration philosophy, to strategic AI-integration guidelines, to a catalog of explainability-and-trust interaction patterns with defined anatomy, up to composition patterns for operator AI experiences. That is what makes the system good at designing here: it encodes why things work in a fulfillment context (gloves, scan-confirm timing, floor constraints), not just generic best practice.

3. Purpose-built agents

An early hosted version shipped with four agents: design assistance, design review, accessibility, and content. Watching how builders actually used them, I deliberately consolidated to two, folding accessibility and content into the agents that already owned those conversations:

• Design Assistant synthesizes research, operational context, and system guidance to support complex design problem-solving, including accessibility and content decisions.
• Design Reviewer evaluates designs and implementations with alignment signals (Stable / Watch / At Risk) and prioritized findings (Must / Should / Could), against an accessibility checklist grounded in Amazon's customer requirements.

Consolidating four agents to two was a deliberate choice for clarity: fewer, more capable collaborators are easier to understand and reach for than a longer menu.

Crucially, the agents don't replace human judgment; they calibrate to it. Guidance is tiered by stakes: low-risk, pattern-based work can be self-served at speed, while higher-stakes decisions route a designer into the loop by design. That tiering is what lets the system give builders real velocity where it's safe, without quietly removing the human review that higher-consequence work demands.

4. Delivery where builders already work

A knowledge base only creates leverage if people actually reach for it. Rather than ask builders to visit a separate tool, I exposed the knowledge and agents through the Model Context Protocol (MCP), an open standard for connecting AI assistants to external context.

This was the breakthrough. The service is published to Amazon's internal MCP registry and distributed through the org's managed agent channel, so it installs as a first-class, official capability rather than a local script someone has to find and wire up themselves. The payoff is agnostic reach: the same shared guidance shows up wherever a builder already works, across editors and AI clients, instead of forcing everyone onto one tool. Meeting people where they are is what turned this from a knowledge base into distribution.

5. A repeatable design pipeline

To produce consistent outcomes rather than one-off answers, I built a set of composable design skills: a pipeline that carries a project through distinct stages, each validating against shared standards, research, and operational constraints before the next begins.

• Discovery stress-tests the idea and resolves key decisions before anything is committed.
• Brief turns those decisions into a structured spec with explicit acceptance criteria.
• Plan breaks the brief into vertical slices that each cut through the whole stack.
• Guided build executes the slices test-first, with a design-compliance and accessibility check at every step.

The result serves both sides of the craft in one flow: it holds a design bar (patterns, research grounding, accessibility) and an engineering bar (test-driven slices, a living decision record, a clean build gate) at the same time. It doesn't replace the designer or the engineer; it gives a small team the leverage of a much larger one, which is the whole point.

Building it

I built and shipped the system end to end: the knowledge architecture, the sync pipeline that keeps it current, the agent behaviors, and the MCP service that delivers them, on enterprise AI infrastructure. It was my first end-to-end application of agentic design and delivery, built by experimenting and iterating directly in production, and evolving it from a single pilot interface into a platform that meets builders in their own environments.

From built to used

Shipping the platform was step one. The harder, more interesting work is the phase I'm in now: closing the gap between people who have installed the tooling and people who have made it part of how they work. A capability nobody reaches for creates no leverage.

So the current focus is activation: onboarding that gets a builder to a useful first result quickly, office hours, and a growing playbook of repeatable “plays” that pair a capability with the exact recipe to apply it. The goal is to move builders from “I have the tool” to “here's how I use it for my problem.” Scaling judgment isn't done when the system exists; it's done when teams reliably use it.

Impact

• Adopted as the directed standard for AI-driven UI work across the org, shifting the default from “design in isolation” to “design against shared context.”
• Moved guidance from a separate destination into builders' existing development environments, reducing friction between intent and execution.
• Reduced dependence on synchronous UX reviews by making on-demand, standards-aligned guidance available to any builder.
• Reinforced team ownership of UX quality through self-service tools supported, not replaced, by the UX team.
• Extends the reach of a small design team across a large builder population and the 1MM+ customers they ultimately serve.

What's next: closing the loop

Today the agents reason from what teams know: research, standards, operational context. The move now shipping is to ground them in what customers actually do. I've integrated product-analytics data into the same platform, which closes the loop at both ends of a project:

• Before building, behavioral data tests assumptions and sharpens hypotheses, so decisions start from evidence instead of opinion.
• After launch, real customer usage shows what worked, feeding the next iteration. The loop runs continuously, inside the same tools builders already use.

The analytics integration is live in production, and the guided plays that turn that data into decisions are rolling out now. It closes the throughline that started this work: real customer behavior, flowing back into the guidance builders act on, turning scarce design capacity into durable, shared leverage.

I've also designed the architecture so the same model can extend beyond a single org: a blueprint for delivering design quality at scale that other teams could adopt without rebuilding it from scratch. That is where I want to take this next.

Reflection

This work changed my sense of what a designer can do. The gap between having an idea and shipping a real system has mostly closed for me, and that shift is hard to overstate: a designer who can also build, with AI as a genuine force multiplier, isn't limited to proposing the work anymore. They can create it.

That's the throughline I want the rest of my career to build on. Designing the systems that scale knowledge, judgment, and craft, and being early to it, is the most energized I've been in my practice. Very little feels out of reach now, and that changes the kind of problems I want to take on next.