Creation Hub
putting an AI assistant inside the product, not next to it
I architected and shipped Creation Hub, the workspace where our customers plan marketing experiments by talking to an AI assistant. Instead of a chat window that only gives advice, I built one where the AI's answers arrive as working parts of the app — so a user can ask a question, see the numbers, think out loud, and act on the answer without ever leaving the conversation.
Our users had ideas. The product had no way to hear them.
Optimeleon helps marketing teams run experiments on their websites: try a different version of a page, show it to the right visitors, see which one wins. Before Creation Hub, the product could execute an experiment beautifully. What it could not do was help you decide what to try.
The user's actual job — the hard part — happened entirely in their head, or in a spreadsheet, or in a meeting. They would form a hunch about why their page wasn't converting, and then arrive at our app to type the finished conclusion into a form. Every bit of reasoning that led there was thrown away, because the product had nowhere to put it. There was no field for "here's what I think is going on."
That mattered more than it sounds. Someone who already knew what to build got a fine tool. Someone staring at a blank form — which is most people, most of the time — got nothing. And answering the questions that would unblock them meant leaving: check the analytics page for the numbers, go to a different screen to see which experiments were winning, come back, and retype it all into the form. The thinking was scattered across five places and the product owned none of it.
- Users couldn't express reasoning to the product — only conclusions.
- Getting the data you needed to reason meant leaving the page you were working on.
- We had AI capable of doing real analysis, but nowhere to put it that a user could actually act on.
Make the conversation the workspace
The assistant doesn't just talk back. It hands you the tool.
The obvious version of this feature is a chat box that gives advice, which the user then goes and acts on somewhere else in the app. That would have solved nothing — it just adds a sixth place to visit. The thing that makes Creation Hub work is that when the assistant has something for you to act on, it doesn't describe it. It renders it, live, in the conversation.
Ask why a page is underperforming, and the assistant replies with an actual results table you can read — not a paragraph about the numbers. Ask it for ideas, and the ideas arrive as a checklist you tick and save with one click. Ask which audience to target, and it hands you a working audience builder, pre-filled, that you can adjust and attach. The conversation is not a layer on top of the app. For the length of the task, it *is* the app.
To make that possible, I designed the assistant to send the app two different kinds of message: ordinary prose, which streams in word by word so it reads like a real conversation, and instructions to open a specific piece of the app's interface inside the chat. The second kind is what turns advice into work. Building it that way also made the feature cheap to extend — every new capability the AI team added was a new entry in one list, not a new screen.
One foundation, many conversations
The feature supports four different kinds of session — pulling ideas from a customer's existing advertising, from their own website's messaging, from experiments that already won, and from their live traffic data. All four run on the same foundation. Adding the fifth is a day's work, not a project.
Answers you can act on, in place
Every AI output that a user might want to keep — an idea, an audience, a winning result — arrives as something clickable that writes straight into the product. Nothing has to be copied out of the chat and retyped somewhere else. That single rule is the whole feature.
The conversation is disposable. The output isn't.
Chats aren't saved. It's a deliberate choice: what the user wants to keep is the idea or the audience they created, and that's already saved properly, in the product, where the rest of the app can use it. Storing the transcript too would have added real complexity to preserve something nobody would open twice.
Assume the AI will get it wrong
AI output is unpredictable by nature, so I built each piece of the conversation to fail on its own. A bad response from the model breaks one card and nothing else — the user keeps their conversation and simply asks again, instead of watching the screen go blank.
Making it feel like a conversation, not a form submission
If the user asks a question and the screen sits blank for eight seconds before a wall of text appears, they've stopped trusting it. The whole point was to get people thinking out loud, and people don't think out loud at something that feels like a slow form. So the assistant's replies stream in word by word, the way you'd expect them to. Getting that smooth was harder than it looks — the words don't always arrive in the order they were sent, and a naive implementation drops or duplicates text when that happens. I built the display to tolerate it, so what the user sees is always correct even when the network isn't.
The AI kept talking to users in database language
When the assistant analyzed performance data, it would sometimes refer to a page version by its internal database ID — a meaningless string of characters — instead of the name the user gave it. To the user, that reads as gibberish, and it quietly signals that the thing they're talking to doesn't really understand their business. I made the app translate those references back into the user's own names before the message ever reaches the screen, including when the model garbled the formatting on its way out.
Clicking a button had to keep the conversation going
The tricky part of putting real controls inside a chat: when the user ticks three ideas and clicks save, the assistant has to know that happened and pick the thread back up — otherwise the conversation forgets what you just did and the illusion collapses. I made every click speak back to the assistant in its own terms, so the AI stays aware of the user's choices and the conversation carries on naturally from them, rather than the app and the assistant keeping two separate, drifting ideas of what's going on.
Six months of other people building on my foundation
I designed and opened Creation Hub, and then seven other engineers shipped features into it for the next six months — new kinds of session, new in-chat tools, richer reporting. That's the real test of an architecture: not whether it works on day one, but whether people who never read your design can extend it safely. The foundation held. Adding a new AI capability meant writing the new piece and registering it, and the core plumbing didn't need to be touched by anyone after the initial build.
Kinds of guided AI session on one shared foundation
Parts of the product the assistant can open inside the chat
Engineers who extended the feature after I designed it
Commits shipped into the architecture in six months
Rewrites of the core after the initial build
Lines of production code across 51 files
An AI feature isn't finished when the model gives a good answer. It's finished when the user can act on that answer without leaving the conversation.
The instinct with AI is to bolt a chat window onto the side of the product and call it done. But a chat window that only gives advice just adds another place the user has to visit. The value showed up the moment the assistant stopped describing things and started handing them over — the numbers, the ideas, the audience builder — right there in the thread. The engineering that mattered wasn't the model. It was refusing to let the model's output stay as text.
The other lesson was about designing for a component that gets things wrong. AI output is unpredictable, and that isn't an edge case to handle later — it's the normal condition. Building on the assumption that the model would occasionally return something broken, and making sure that only ever cost the user one card rather than their whole session, was the difference between something that demos well and something people trust on a Monday morning.
Full-Stack Engineer, Optimeleon