AI-native B2B SaaS · Agent Interaction Design
Ocula's copy generation agent needed an interaction model, and there was nothing in the standard SaaS design toolkit to reach for. User journeys and wireframes assume a fixed, deterministic flow. An agent is probabilistic: it adapts, takes initiative, and needs to be briefed, not routed through a form. There was no existing playbook for that inside the company.
I built one: a set of agentic principles, research into the two very different customer personas the agent had to serve, and a Goal, Rules, and Success Criteria framework applied to every step of the interaction, replacing the fixed journey a SaaS flow would normally use.
Ocula's customers create product copy at scale, from small teams with a single generalist to large specialist copywriting departments with strict brand guidelines. The existing template creation process was entirely manual: a customer submitted template details through an online form, a solutions engineer built the base template by hand, samples were generated and sent back, feedback came in through customer support, and only then was the template available to use. Replacing that manual chain with an agent meant the agent had to do real judgment work, not just fill in a form faster.
The instinct is to design an agent the way you'd design any SaaS feature: map the user journey, wireframe the screens, ship it. That approach assumes the system behind the screen is deterministic and static, the same input always produces the same path through the same steps. An agent isn't that. It's probabilistic and dynamic: the right response depends on what it's seen before, and it needs to adapt and improve rather than follow a fixed rule.
There was nothing internally to reach for here. No prior agent product to borrow patterns from, no team playbook for what an agent's "user journey" even means when the journey isn't fixed.
SaaS design thinking is deterministic and static, built for fixed journeys. An agent is probabilistic and dynamic, so it can't be designed with a fixed journey at all.
It needs principles, goals, and rules to operate within, not a flow to follow.
I started by setting out ten agentic principles before designing any specific interaction, so every later decision had something to check itself against: agent first, not UI first. Agents must take initiative. Reduce human work, not just speed it up. No static rules, everything must adapt and improve. Minimise cognitive load for users. Agents should learn from external signals. The agent should have a personality and memory. Success is measured by completion, not engagement. Agents seek feedback and approvals. Agents must show their working.
With the principles set, I researched who the agent actually had to serve. Two personas came out of it, and they wanted opposite things from the same tool. An eCommerce manager runs a small team or works solo, wears every hat, has thin existing copy and no strict guidelines, and mainly wants their copy improved. A specialist copywriter sits in a large department with strict brand guidelines and a tone of voice that has to be matched exactly, and wants new copy generated that's indistinguishable from what they'd write themselves.
Next I mapped the journey as it actually worked, before touching the agent at all: a customer submits template details in an online form, a solutions engineer builds the base template, samples get generated and sent over, feedback comes back through customer support, and only then does the template go live. From that as-is map, I designed the to-be journey: the user provides or chooses sample copy for a tone of voice reference, content structure and rules get defined, copy rules get defined, and a template is generated that the user gives feedback on directly, no solutions engineer or support ticket in the loop.
For every step in that to-be journey, I asked a single question: how can the agent support this, specifically? The question wasn't what screen goes here. It was what the agent can actually do at that point, inferring from the examples it's been given, suggesting structure and rules from best practice, working with the user directly to define rules or get clear, actionable feedback.
To make each of those steps buildable, I gave every agent interaction a Goal, a set of Rules, and Success Criteria, the same structure repeated at every step instead of a screen-by-screen spec. For the reference-gathering step, for example: the goal was to get three consistent product description examples the agent could use as a tone of voice reference. The rules were to prioritise getting real references from the user, support them with best-practice generated descriptions where they didn't have any, and update the references based on feedback. Success was three references supplied, a consistent tone of voice across them, and the user's explicit approval to use them.
The rules themselves got defined conversationally, not configured. This is a real exchange from teaching the agent a copy rule:
Assistant: To make sure I use language that best represents your brand, are there any words or phrases I should avoid? User: Yes, don't use "bargain," "cheap," or "budget." Assistant: Got it. Are there words you'd like me to use instead, or just avoid those in particular? User: Use "value" instead.
That one exchange is the agent taking initiative, seeking feedback, and showing its working, three of the ten principles, playing out in a single conversation instead of a form field.
There's no dashboard number for a design method. What held up was the method itself: the same principles, persona research, and Goal/Rules/Success Criteria structure applied cleanly across every step of the journey, from reference gathering through to template generation, without needing a different design approach for each one. Two personas with close to opposite needs were both served by the same underlying framework rather than a fork in the product.
Both personas, the generalist doing everything themselves and the specialist matching strict brand guidelines, get an agent that adapts to how they actually work, instead of one fixed flow that suits neither of them.
A repeatable method for designing agent behaviour, principles plus Goal/Rules/Success Criteria, that doesn't require inventing a bespoke design approach for every new agent interaction.
You can't wireframe a probabilistic system. You can brief it: give it principles, goals, rules, and examples, the same way you'd brief a new colleague, then let it work within them.