From Figma to Agents: What 15 Years of Product Design Taught Me About Building AI

I started in film school. Then I was a VFX compositor in New York, working on Budweiser Super Bowl spots and Coca-Cola ads, until I saw someone using an iPhone on the subway in 2007 and understood the screen had moved. So I moved with it — about fifteen years designing and shipping product and mobile apps across studios and startups. That run started at Fuzz in NYC, building native apps for Disney, Wegmans, AB InBev, Shake Shack, and The Met, products that touched millions of users, and continued through Teeps, sndr, Cloud Nerd, and others. After that, enterprise delivery: I ran Salesforce programs as a senior consultant and project manager — a $2.5M healthcare platform redesign that lifted engagement 45%, a multi-state insurance portal that went live with zero errors. Now I build agentic AI infrastructure — Coquina, the Forge runtime, dozens of autonomous workers running on hardware in my house.

On paper that looks like three careers. From the inside it's one, and the throughlines are clearer than I expected. Here's what fifteen years of product design actually taught me about building AI.

Designing for Users Became Designing for Agents

The first thing I noticed building agent systems is how much it rhymes with interface design — just for a stranger user.

When you design a screen, you obsess over the contract between the product and the person: what's the affordance, what state are they in, what happens when they tap the wrong thing, how do you communicate an error so it doesn't feel like a dead end. Good design is mostly about making state legible and making failure recoverable.

Agents need exactly the same things. An agent calling a tool needs a clear contract — unambiguous inputs, a predictable output shape — the same way a user needs a button that obviously does one thing. An agent needs predictable state, because an agent that can't tell what state it's in makes the same class of mistake a confused user makes. And an agent needs good error states more than a user does, because a user can improvise around a bad error message and an agent will faithfully drive off the cliff your bad error state built.

I spent years learning that a confusing empty state or a vague error message is a design failure, not a user failure. Building agents, I learned the same lesson with higher stakes. When my job-scanner worker returned zero results, the bug wasn't the agent being dumb — it was an unclear contract between the task and the model. Fix the contract, fix the behavior. That's a design instinct, applied to a non-human user.

Product Discovery Became Build-vs-Buy

The second throughline is discovery. Before you build a feature, the discipline is figuring out what problem you're actually solving and whether building is even the right move. That muscle transfers directly to AI, where the most expensive mistake is building infrastructure you should have bought, or buying a platform you should have built.

When I built Coquina, the discovery question wasn't "can I build a memory system" — of course you can build a memory system. It was "is the memory problem for AI agents real, underserved, and shaped like infrastructure?" That's a product-discovery question, not an engineering one. The answer is why Coquina exists as raw memory with auto-linking and schema-on-read instead of as yet another wrapper around an embedding store. Discovery told me where the gap was before I wrote the code.

Same instinct, every worker I build: is this a thing I should own, or a thing I should call an API for? Fifteen years of "should we even build this" makes that a reflex instead of an afterthought.

Design Systems Became Reusable Agent Patterns

This one is almost a direct port. A design system is a set of reusable components with consistent behavior, so you stop reinventing the button and start composing from primitives you trust. The whole value is that consistency lowers the cost of the next thing you build.

My worker architecture is a design system for agents. The overnight chain isn't a pile of one-off scripts — it's a set of workers that share contracts: how they read and write shared memory, how they coordinate on the GPU, how they declare dependencies, how they report state. When I build a new worker, I'm composing from patterns I already trust, the same way I'd assemble a screen from a component library instead of hand-rolling every element.

A reusable pattern is a reusable pattern whether the consumer is a designer dragging a component onto a canvas or me declaring a new node in a DAG. The discipline of "make it once, make it consistent, reuse it" is identical. Design systems taught me to think in primitives. Agent infrastructure is where I cash that in.

"Ship It, Prove It Works" Was Always the Job

The deepest throughline isn't a technique. It's a stance.

Every job I've had rewarded the same thing: ship something real and prove it works. In product design, that meant an app in the store that millions of people actually used, not a prototype in a deck. On the Salesforce side, "prove it works" meant a multi-state portal that launched with zero errors — in enterprise delivery, the proof is the launch, and a launch that breaks is a strategy that failed. Now it means an overnight chain that runs unsupervised while I sleep and has the results waiting when I wake up.

Different mediums, same bar. I don't trust a feature because it looks good in Figma; I trust it because it survived contact with real users. I don't trust a worker because the code is clean; I trust it because it ran in production and produced the right output against a real need. Demos are claims. Shipped-and-running is proof. That bias — toward the working thing over the impressive-looking thing — is the most valuable habit design and enterprise delivery beat into me, and it's the one I rely on most building AI.

Why This Bridge Matters

There's a story the industry tells where design people and AI-infrastructure people are different species. I don't buy it, because I've been both, and the skills that made me good at one are the skills I lean on hardest at the other.

Designing for a user and designing for an agent are both about clear contracts, legible state, and recoverable failure. Product discovery and build-vs-buy are the same question pointed at different layers. Design systems and reusable agent patterns are the same instinct for composing from trusted primitives. And "ship it, prove it works" is the throughline under all of it — the thing that's been the actual job since the first app I put in the store.

I didn't leave product design to build AI. I brought it with me. If you're looking for someone who builds agentic systems with a designer's eye for the contract and a shipper's bias for proof, that's exactly the bridge I stand on: reed@grainlabs.io.