AI-native B2B SaaS · Agentic Replatform
We'd rebuilt the whole company around one feature, then hit a wall — the flow that proved it worked was too rigid to hold what the agent could actually do. The fix wasn't a better stepper. It was realizing the interaction shouldn't feel like querying a database — it should feel like a colleague working through a stack of paper on their desk.
That became "the stack": sheets of data that layer on top of each other as you go deeper, and peel back off as you return. It shipped to every customer and is now core to the platform.
We'd just realigned the company around one feature: AI-generated product copy. It was the thing customers actually wanted, so we cut a stack of features that weren't earning their keep and pointed the team at it.
The first release proved the core bet — that the agent could generate consistent, quality copy at scale. It shipped as a standard SaaS stepper: upload a product file, pick a copy template, generate. It worked, and customers used it.
But a stepper is a straight line, and the agent underneath it wasn't. Everything clever it could do — catch an edge case, hold a ruleset, take feedback mid-generation — had nowhere to live inside three fixed steps.
A stepper is a straight line. The agent underneath it wasn't.
Then we added a second product, data enrichment, and the stepper stopped being merely limiting. It became a wall.
Bolting data enrichment onto the existing stepper would have meant building it inside that same rigid shape — and we knew it wouldn't stop there. Every feature after this one would hit the same ceiling, not just this one. We wanted a platform that was flexible for customers and for us as we kept building on it. Some of the interactions we needed — giving feedback on generated copy, building out rulesets — wanted to be conversations, not form fields, and a stepper can't hold a conversation.
That's what forced the replatform. Not a growth target or a deadline — the shape of what we'd already built no longer fit what we needed it to do next.
Before anyone sketched a screen, I worked with the Head of Product to ask a basic question: what do we actually mean by an "agentic experience"? Out of that came two sets of principles — one for the product, one for the interaction design.
The product principles centered on ideas like agent takes initiative, user verifies, generate first, refine after, and build tools, not features — general-purpose primitives the agent could orchestrate, rather than one-off screens for one-off problems. The design principles pushed the same logic into the interface: agents as first-class users, make the agent do the hard work, hide the complexity, kill your darlings.
Then came desk research — how were other tools solving problems like this? — and out of that, the real tension underneath everything became clear: how do you keep the interaction conversational while still letting someone navigate seriously deep data? A chat window is fine for a question. It's useless for finding one flagged attribute inside five thousand products.
We sketched against that tension. Some ideas died on the page. One had legs.
We'd been designing the agent like a database being queried. The unlock was picturing it like a colleague instead — the way someone actually works through a stack of paper on their desk: agree the plan, pull the sheet that's relevant, look at it, put it back, move to the next one.
Design the interaction the way a colleague works through a stack of paper, not the way you'd filter a spreadsheet.
We called it "the stack." Data shows up as sheets inside the chat, layered on top of each other as you go deeper. Click a data item — a batch of products, a single product, a piece of copy, one attribute — and the agent lays a new sheet over the stack with that detail. A back button at the top of the sheet peels it off again, one level of granularity at a time.
It went from sketch to wireframe to a working prototype in the browser in a couple of days, built against real product data sitting in a local JSON file so it behaved like the real thing rather than a mockup. We tested it internally first, then put it in front of design partner customers.
The high-level pattern landed immediately — partners described it as "fast and natural." What came back afterward wasn't "this doesn't work," it was detail: the back button started as an X and felt too much like closing something rather than stepping back, so it became a double chevron. Action items moved into the header, next to the title, because that's where partners expected to find them.
There's no before-and-after number to point to here — there was no previous version of this pattern to measure against, because we weren't optimizing something that existed, we were replacing the paradigm underneath it. What we can point to: it shipped to 100% of customers, and it's now a core, load-bearing part of the platform, not a pattern that quietly got parked after launch.
When you're designing a new interaction paradigm, don't start from the interface. Find the physical, human equivalent of the work first — how someone would do this with a colleague, a desk, and a pile of paper — and let that shape the interaction. It's a better source of intuition than any existing app, because the person using your product already understands it without being taught.