One Slack message at 1AM.
No brief, no PM. Few months later an AI agent that moves money
Rho had the data, the modules and the customers. What it did not have was a way to ask for anything.
Agentic Experience Layer · Fintech AI · Lead Designer · Shipping to beta · 2026
The Context
Rho had everything except accessible intelligence. Cards, expenses, banking, treasury, AP, accounting. All there, all powerful, all completely separate. Users had to know which module to open, what to do in it, and how to connect the dots themselves.
Competitors were starting to move, and our customers, tech savvy founders who use AI all day, expected more.
Friction
Finance work needs expert knowledge. Tasks span many systems. Time lost to manual navigation across silos.
Pressure
Leadership needed an AI answer, fast. No roadmap, no spec. Design put on the spot to figure it out and deliver.
What I saw
We already had the data. We just had to connect it and put it behind natural language. The intelligence was already there, unused.
We were not starting from zero on who. The ICP was known and I had already built the personas with the Head of Product. Founders, bookkeepers and controllers each hire the product for a different job.
The chatbot came first. My job was deciding whether it lived
Built for support, not for the product. It aggregated what the company already knew and answered questions so fewer reached human agents. Or that was the hope.
I did not design it. My job was deciding whether it lived. It ran for a year across 2024 and 2025. I built custom Amplitude dashboards and events to track it, reviewed LogRocket sessions, and talked to customers.
Of the tickets the bot could answer, only 23% ever reached it.
The rest went straight to human agents. When the bot answered but could not act, users asked support to do the work in their name. The users who found it came back. The failure was discovery and the action gap, not the answers. Add the operating cost, and the decision made itself.
We killed it.
That behavior became the brief for the agent. Users will take knowledge from a bot. The moment work needs doing, they go where action happens.
Buried in the help center. It could suggest reading. It could not do anything.
AI should not just answer. It should act.
Everyone defaults to adding a chatbot. A chatbot answers questions. I designed for an agent that does the work. One prompt, show me where we could save money, orchestrating expenses, cards, treasury, fraud, transaction and credit data at once, then taking action across all of them.
The real design problem was not the prompt box. It was trust and safety. When AI acts on money, every action needs guardrails, confirmation, and a clear sense of what it is about to do. That is not a feature. That is the entire business challenge.
The architecture - simplified, not a screen. One prompt, multiple systems, two trust layers.
Validating in code, not in a research cycle
Traditional research was too slow for this. We talked to customers early, watched competitors, then beta tested with hand-picked cohorts behind a LaunchDarkly flag. We chose which customers got which experience.
v1 was conservative on purpose. Rho customers do not like big changes. Full chat first was too far, too fast. The beta ran with roughly 20 customers, weighted toward founders, and feedback split cleanly by persona.
Founders
Wanted the full LLM experience. More agent, not less.
Bookkeepers and controllers
Wanted to stay in their tables and close the books.
We asked beta customers to run their most common tasks and scored each attempt: success, partial, fail. Success meant the task completed without the user working around the agent. Roughly three in four succeeded, with a human confirming every action. Observed sessions, not instrumentation.
We tested multiple entry points. For v1, decision was to proceed with conservative Dashboard to Agent approach.
“I no longer need to set filters or spend time crunching numbers in the table. One prompt and I get more than I ever needed.”
Founder, beta customer
I built v1 conservative because I read the customer base as change-averse. Founders told me the opposite. v2, in progress, is adaptive by persona: from one interface for everyone to the system meeting each role where it works.
Decisions made, driven by business
Instead of: Shipping the fastest possible agent and adding safety later.
Because: Moving money is not the same as showing a chart. Every action previews what it will do, with confirmation scaled to risk.
Cost: Deliberate friction. Power users will ask to turn it off, and we will have to decide when to let them.
Used the data we already had
Instead of: Waiting for new data infrastructure.
Because: The intelligence was sitting there unused. Connecting existing data models to a natural language layer got us to working software in weeks.
Cost: It forced squads across the company to rewrite microservice APIs on nobody's roadmap. We inherited an organizational negotiation, not just a design problem.
Instead of: High fidelity Figma prototypes handed to engineering.
Because: Working software in a custom environment, built on the design system and Storybook library, let us test with real customers in days.
Cost: Patterns were born in code faster than documentation could follow. Consistency debt landed on the design org and the handover became mine to manage. The AX components are being folded back into the system now: the correct order, later than ideal.
The hard part was not the design
A Slack message at 1 AM.
First meeting at 10 AM.
No brief, no vision, no roadmap, no PM.
The whole brief.
Leadership handed the directive to design and data engineering and we ran it hackathon style as a separate team. Product joined later.
Connecting the system meant squads across the company rewriting their microservice APIs to serve data individually and cross-dependently. That work was on nobody's roadmap.
Engineering pushed back. Rewriting microservice APIs for a project with no PM and no roadmap was work nobody had budgeted. I did not win that argument: leadership's mandate carried it. What I could do was make it cheaper to obey. We scoped the minimum system that could work now and scale later, so squads were rewriting toward a target instead of a vision. They were not happy. They built it anyway.
Moving from monolith to microservices had been the right direction for years without a strong enough push. This project became the forcing function.
When there is no roadmap, the architecture is the strategy.
Decide how it works and you have decided where the company goes.
From one Slack message to Switching banks in one Slack message
Ask Rho to migrate data out of Mercury, in Slack, without opening the app. The agent picked it up, pulled the history, and mapped it across the money stack. No forms. No migration project. Without the need to open settings page.
Where it stands
Shipping: Claude integration is the first step of releasing our agentic experience. Internally tested, releasing to beta customers now. The prototype I built is being productionized by engineering.
Tested: Validated with more than 20 beta customers behind a feature flag.
Observed: Roughly three in four prompts succeeded with a human in the loop, scored across observed sessions.
In progress: Agent message component is being added to the design system and component library.
Honest pain point: API latency. Some services take too long to respond and it degrades the experience. Fixing service response time is now an engineering priority.
Instrumenting: beta was scored by observation. Production telemetry is being built now. Prompt success rate, agent action acceptance rate, and time to complete tasks that previously required manual table work.
What I would fix
The waiting experience
When the agent calls slow services, the user stares at a thinking state with nothing to do and no sense of progress. We prioritized correctness of actions over perceived speed, and we underestimated how much latency would shape the experience.
The fix: streaming the agent's reasoning as it works, optimistic responses where actions are reversible, and progressive disclosure of partial results instead of one big answer at the end
Why it shipped this way: v1 had to prove the agent could act safely before it could act fast. Trust first, speed second. Now speed is the debt to pay.
Reviewing at volume
The agent presents each bill as a tile. One object, one card. At six open bills that is scannable. Users with 50 or more flagged it immediately, and they were right: a tile grid at that volume is clutter, not clarity.
The fix: Response adapts to volume. Small sets stay as tiles. Large sets shift to patterns built for review at scale, dense list, grouping, bulk actions, so the agent shows customers how to work through the queue instead of handing them a wall.
Why it shipped this way: tiles covered the 85% case, most customers do not carry that many open bills, cards or entities at once. The component already existed in the design system with the frontend library ready, and the business call was to ship urgently on what we had rather than build a new pattern first.
© 2026 · Thanks for scrolling, human