I was typing the eightieth chat message into Figma

It was the middle of a two-week sprint and I had a Figma frame open with a chat conversation laid out as static screens. One message per frame, one bubble per design, dozens of frames to walk a customer through a returns flow for one of three brands on one of three channels. The client was on the call. They wanted a change to message four. I made the edit, and watched every downstream frame fall out of sync. There was no path to do this work at speed. There was no path to do it on a call. There was no path to do it without inserting a manual handoff between the conversation in my head and the design on the screen.

The project was an agent implementation for a global consumer brand. Several brands under one parent, each with its own agent persona. Web, SMS, email. Where is my order, returns, defective returns, contact center, FAQ. The build team was dozens. Several engineers, several QA, a delivery manager, a product manager, three technical architects, a solutions architect, a UX consultant, a vendor-side engineer, and me. The build of the agent itself was on rails. The bottleneck was design. Specifically, the bottleneck was the gap between what we needed to specify and what our design tool was built to specify.

Figma was built for screens. We were trying to use it to specify behavior. The instrument was wrong. That mismatch is the whole story.

Why the manual process was the wrong shape

The work in a sprint, in the early weeks, was this. Pull transcripts from the live contact center. Read them. Identify the flow shape. Write a script. Render the script into Figma as a static conversation, message by message, bubble by bubble, for each brand and each channel. Walk the client through it. Take feedback. Make changes. Hand the approved design to the build team. Repeat for the next flow.

Two days per section was the floor. Some sections took longer. Every change request was expensive because every change rippled through frames that had been hand-built. The qualitative cost was worse. We were defaulting to a single generic persona across all three brands because the cost of producing three real personas was prohibitive. The work that should have made the agent sound like the brand was the work we kept cutting because it didn't fit the time we had.

A designer reading this is already in the pain. You know the shape. The tools you use were built for the work you used to do. The new work has different requirements and the tools have not caught up.

What I tried first

V1 was a long try at making the existing stack work. I bridged tools with MCP. I wrote plug-ins. I wired up shared files. I worked inside enterprise IT governance, which is a real constraint and not a complaint. Some of it worked. Most of it was slow. Each new integration added a tool to the chain and made the chain less reliable. I was building a worse and worse copy of the manual process. I was treating the orchestrator as a thing that would integrate with the design tool, instead of asking whether the orchestrator could be the design tool.

The shift happened when I stopped trying to make Figma the source of truth. The conversation didn't live in Figma. The conversation lived in the transcripts on one end and in the production agent on the other. Figma was a render of a thing that already existed somewhere else. Once I named that, the question became: what if the source of truth is a manifest, the render is downstream, and the orchestrator owns both?

V2

V2 was an instrument shaped for the work: a single orchestrator with sub-agents for each piece. A transcript reader that pulled patterns out of real customer conversations. A flow writer that turned patterns into a script. A persona mapper that voiced the script for one of the three brands. A channel adapter that took the voiced script and produced its web, SMS, and email forms. A renderer that emitted HTML by default, because the conversation actually lives in HTML, and PPTX optionally, because executives want PPTX. A manifest sat under all of it as the source of truth for what we'd gathered, what we'd written, and what we were going to build.

The renderer couldn't emit anything that wasn't in the manifest. The brand voice, the channel format, the flow shape — all of it had to live there first, or the renderer had no way to produce it. The manifest was the harness. It bounded what the renderer was allowed to produce, and the renderer couldn't invent its way around it. That constraint is what made the output stable across three brands and three channels.

The Figma connection got deprecated. The plug-ins came out. The integration layer got thinner each week as I realized I didn't need most of it.

The team using the tool was three of us: another experience architect, the solutions architect, and me. I built the first version and they came in as it stabilized. They pushed back on outputs that didn't match their judgment. The persona mapper got better because the SA had taste for one of the brands that I didn't. The channel adapter got better because the other XA had been reading SMS support logs for weeks and knew exactly what was off. The tool got more correct through three people using it, not one.

Build time per section dropped from a couple of days to a couple of hours. We did next-day follow-ups after refinement meetings. We delivered the canonical flows across three channels and three personas for three brands. We had time to design with real personas instead of one default. The work that we had been cutting because it didn't fit the time, we stopped cutting.

What the work taught me about the craft

The interesting moment in this project for me, the one I'm still working with, is not the velocity number. It's that I had to learn how to do this work agent-native and I was not good at it on the first try.

I came in with a software engineering mental model. I built the early skills as scripts. I thought I was writing programs that called an LLM. I was wrong, in a specific way. Agent-native architecture is not scripts that call a model. It is sub-agents with judgment, an orchestrator that routes between them, and a manifest that holds the state none of them own individually. The early version of the orchestrator was the wrong shape because I was the wrong shape. I had to see the mistakes to understand how to make the next version multithreaded, agent-native, judgment-shaped.

I anchored the design system work on the platform's tokens partway through. Once the tokens were anchored, the agent could modify the design library cleanly and produce exact copies of the manual designs we'd already approved. In a sense, the manual sprint at the start of the project trained the agent. The hours we spent hand-building frames became the reference set the orchestrator learned to match. I would not call that a plan. The plan was to ship; the reference set was a byproduct of working slowly enough to know what good output looked like.

The personal version

After the delivery I rebuilt the orchestrator on my own infrastructure. Not the same code. Not bound to any vendor ecosystem. More taste-encoded, more content-focused, with generic skills the orchestrator calls instead of platform-specific ones.

The work version was correct for the constraints we built it under - enterprise IT governance, vendor platform, team of three designers using it. The personal version let me see which of those constraints were architecturally necessary and which were environmental. The architecture survives the move; most of the integration layer didn't need to.

The personal version is for me. I will keep it forever and tweak it forever. It is the kind of capability I want available to my hands regardless of what role I am in, what platform I am building on, what the industry is doing this quarter.

What this work is part of

Designing for agents is a new craft. The tools we used for screen design were built for a different problem and they do not bend gracefully to this one. Figma is a render. The conversation is the artifact. The persona is the constraint. The channel is the substrate. The orchestrator is the design surface. None of this was obvious when the project started. Most of it became obvious because of how badly the old tools fit.

I am new to this craft and so is everyone else. The people who shape it over the next few years are going to be the ones who build their own instruments while doing the work, instead of waiting for the instruments to arrive. I built one at work, with a team, under a deadline, for a client whose customers number in the thousands per day. I built one for myself, on my own infrastructure, to keep the capability in my hands.

Building an instrument for a craft that does not yet have the tools is not a side quest. It is what the craft asks of you in the years before the tools arrive.