ASAPP builds AI-powered customer service software for large enterprises. Their core product, GenerativeAgent, handles customer conversations autonomously across voice and chat. The next version needed a configuration layer that didn't exist yet.

The previous generation was configured through a single massive block of text instructions. It worked for simple use cases and broke down at scale. Complex multi-step conversations were hard to maintain, changes in one place broke behavior elsewhere, and there was no reliable way to test or audit what the agent would actually do.

The new system replaced that with a structured, step-by-step architecture: discrete nodes, explicit decision logic, and routing conditions that gave enterprise clients auditable control over how the agent behaved at every point in a conversation. The long-term vision was self-serve: enterprise clients configuring their own AI agents directly, with Customer Engineers as support rather than primary builders.

The research team had built a canvas-based flow editor to experiment with the new architecture. Built by ML researchers, for ML researchers. Nodes were hexagons color-coded by transition type. Step names were raw code identifiers. The configuration panel required deep knowledge of internal system concepts and Python to do anything meaningful.

Even I couldn't use it at first. My early work wasn't designing. It was learning. Close working sessions with the research team to understand why specific configurations were built the way they were, why certain decisions lived in the tool versus in the backend, and what the system was actually trying to do.

There was also no stable spec, no established patterns for how to write a good configuration, and a market moving fast enough that slow design cycles weren't just inefficient. They were a competitive risk.

This project was a pilot for a new way of working: what design looks like when the product is being invented alongside the interface. The traditional cycle of wireframes, handoffs, and VQA backlogs wasn't going to work. Sometimes that meant a quick sketch on paper and then opening the codebase. Sometimes it meant writing a precise spec so engineering could move fast without back-and-forth. Sometimes it meant a UX impact analysis written same-day in response to an architecture change.

I came in with no experience in terminal, Git, AI-assisted coding tools, or working in a production codebase. By the end I had my own branch in the repo, had shipped roughly 3,200 lines of UI changes, and had written a framework the team adopted for how designers and engineers collaborate in this model.

The existing design system was under-resourced and had drifted from what was being built. In my prototype branch, I used Shadcn UI and Tailwind CSS calibrated to the existing product's visual language. When the engineering team later evaluated migrating the entire product to a new design system, that branch was cited as early proof the approach worked.

Before proposing anything, I needed to understand the system well enough to have opinions about it. I set up the tool locally, ran the scenario testing environment, and loaded the real flows the research team was actively working on. I also looked at how other companies were approaching similar problems: OpenAI's agent builder, Sierra, Fin, Voiceflow, Retool, Flowise, and others building visual tools for agent and workflow configuration.

Then I analyzed what was actually being built. Across 90 steps in all existing workflow configurations, clear patterns emerged:

The node taxonomy I proposed (Input, Decision, Router, Execute, Start, End) was grounded in that analysis and shaped by what similar tools were doing elsewhere in the industry.

It didn't ship as designed. The underlying configurations kept changing as the research team iterated, and locking in distinct node types would have meant redesigning the canvas every time the architecture shifted. Instead of forcing a taxonomy the system wasn't ready for, the team built a single flexible node that could hold any of those patterns underneath, keeping the door open to revisit the distinction once things stabilized. That decision turned out to be the right one. The node type evolution that eventually shipped months later, distinct types for talking versus doing, arrived at a similar place, but only once the system was settled enough to support it.

Design on this project didn't happen in formal review sessions with the product team. It happened in Slack threads, shared documents, and real-time back-and-forth with researchers and engineers. I initiated and ran a weekly cross-functional working session that became the primary forum for surfacing architectural dependencies and deciding what to expose to users and how. Alongside that, I kept a regular check-in with the design team to get outside reactions and make sure I wasn't missing considerations that were harder to see from inside the work.

I created my own branch and made changes directly in the React application using Claude Code. What shipped directly from my branch:

Complete rework of node rendering with human-readable labels and icon badges. New routing handle system for decision nodes. Floating configuration panel replacing the right sidebar. Flow validator catching unreachable steps and disconnected nodes before deployment. Light theme and design token system. Layout switcher supporting both top-down and left-to-right orientations.

The first large pull request (roughly 3,200 lines across 56 files) created productive friction. The engineering lead's feedback was clear: too large to review safely without tests. What came out of it was a collaborative working document that codified branching strategy, PR standards, and code review expectations for designer-generated code.

After that I changed how I operated. I built project memory files that captured the team's engineering conventions so I could apply them consistently without re-learning them on every contribution. Showed up to daily standups. Created and moved Jira tickets, updated statuses, wrote PR descriptions in the team's format. The goal wasn't just to ship UI. It was to actually be part of the team.

The work happened in three phases:

On May 14, 2026, the workflow tooling was enabled for American Airlines' production environment. The A/B test was running at 20% of live traffic across three real workflows (TSA PreCheck, flight rebooking, rewards) with no red flags and plans to scale to 40%.

Beyond American Airlines, Customer Engineers were independently building and iterating on configurations for additional enterprise clients, expanding adoption beyond the first production case.

Customer Engineers who previously needed Python knowledge and GitHub access were building and iterating on production workflows independently. The design system approach used in the prototype branch was later validated as the path forward for the broader product.

The product is still being iterated on: new features, CE feedback, ongoing work toward the external production MVP. The foundation built during this period is what makes that iteration possible.

The node type evolution was a known risk from the start, agreed on between product and design. Throughout the build, I made a point of stepping back and looking at the configuration with fresh eyes, the way a new user would. Once we launched the MVP and CE feedback started coming in, the signals were clear: overwhelm, questions, confusion. It wasn't a shock, but it still felt like an "uh oh" moment. We moved quickly. Prioritized node types, got designs in front of CEs fast, and iterated in tight cycles. CEs responded well. They felt hopeful, and many said they appreciated being brought into the iteration loop so directly. That fast feedback cycle became part of how the team worked.

The large initial PR was genuinely new territory, for me and for the org. The process that came out of it wasn't a correction to a mistake. It was the work of figuring out something that didn't have a playbook. Engineers were understandably resistant at first. There's a lot of noise right now about AI tools taking work away from engineers. What this was actually doing was the opposite, freeing them from VQA cycles, button size debates, copy changes, pixel pushing. I could handle that myself, which meant they could focus on deeper, more complex work. Getting to that shared understanding took time, documentation, and a real feedback loop. That's what made it stick.

What I'd keep: being in the work. Running the actual flows, sitting in the research meetings, having real opinions about architectural decisions. That's what made the design credible.