The brief
Let a company set up its own finance systems, with an agent doing the heavy lifting.
Getting a company's finance systems running means defining its structure: legal entities, ledgers, chart of accounts, business units, calendars, dimensions, and more, often separately in each application. The work usually takes months and leans on systems integrators to translate how the business maps to a valid configuration.
Leadership wanted an AI agent that could take a company's own documents and data, propose the setup, and keep it consistent across applications. They asked for the vision first, with a tight first scope. I was the only designer, working with a product lead and reviewing regularly with a senior executive.
What I found
The person who presses go isn't the person who knows if it's right.
An implementation admin applies the configuration. The finance teams, from planning to consolidation, are the ones who know whether it reflects how the company actually runs its money. In a consultant-led setup, the consultant carries that knowledge between them. Remove the consultant and that gap is exactly where the agent sits. And while these decisions are easy to click through during setup, they are expensive to unwind after go-live.
So the design question became: how do the people who know check what the agent proposed, before the person with the button applies it?
How I found it: working sessions with product and engineering on how real implementations are staffed, a fictional multi-entity company to test what an AI can and can't read from a business description, and before-and-after workflows for the roles the product would change most. The personas were hypotheses built with internal experts; validating them with customers was a planned next step.
What I designed
Interaction model: a conversation with a living document
Challenge: The agent's output is a large, structured setup document. People need to read it, question parts of it and change it. The AI design patterns available to us were changing month to month, and how AI should appear across the product was still being decided: a single-turn bar across the top of the page, or a persistent chat panel.
What I chose: A hybrid workspace. The conversation sits in a side panel, the agent's output is a document beside it, and a checklist shows each part of the setup and where it stands. I staged the document by what each release could support:
MVP: the document is read-only. People review it and talk to the agent about it.
MVP+: people select an item in the document to give the chat exact context, such as one segment of the chart of accounts.
MVP++: people edit the document directly, and the agent generates the downstream changes.
I built on the core design system team's emerging AI patterns, and fed patterns from this project back into them as they formed.
What I rejected: A single-turn answer below a search bar. It suits quick questions, but a setup document that evolves over weeks needs a persistent home, and a conversation that remembers what came before.
Result: Every flow I designed used this layout, and the staged plan gave engineering a small first target. Each stage adds interaction to the same document, so nothing gets thrown away.
Product strategy: draft the blueprint first
Challenge: An alpha proof of concept, built just before I joined, had shown that AI could create a company's corporate and financial structures from natural language and a strict data template. My early flows started there. The admin picked a template for their type of organization (commercial, federal, or state and local), downloaded it, had experts fill it in, and uploaded it. Nothing useful happened until every expert had replied.
What I chose: Have the agent draft first. Language models were getting better fast at researching and structuring public information, so I proposed that the agent build a company profile and a first-draft structure before onboarding starts. The admin is met with a draft, and experts react to it instead of filling in a blank template. The agent drafts what the information supports and flags what's missing. Internal detail, like a full chart of accounts or a cost center list, still comes from the customer.
I tested it before proposing it. I had the AI research a few public companies and generate their blueprints, then vetted the results with seasoned implementation consultants on our team. I also created a fictional company that sells wildfire alert systems to test other parts of the model.
What I rejected: Keeping my own template as the front door. Templates stayed as one way to add information, not the starting line.
Result: Draft-first became my north-star design for onboarding. My product lead, a former implementation expert, took the findings to senior leadership, who began weighing it from sales, legal and product angles. That decision was still open when my work ended.
Hypothesis: reuse existing screens instead of rebuilding them
Challenge: A new AI-first app raised a scoping question: which of the existing setup screens would be rebuilt for it, which wouldn't, and how products would keep working while they were converted.
What I proposed: Rebuild only what the new experience needs, and bring the rest of the existing screens into the workspace as frames when they're needed. That keeps the rebuild smaller and gives products an interim path while they convert.
Result: An untested hypothesis. The next step was to drop real setup screens into the flows to check whether they fit. My work ended before I got there.
How it earns trust
Every change is visible, explained and approved.
Finance teams won't hand their structure to an agent they can't check. I designed these behaviors into the flows, some for the first release and some for later stages:
Explain its choices. When the agent adds something nobody asked for, such as a secondary ledger to meet US cash-basis requirements, it says why on request.
Confirm before changing. A requested edit is restated and waits for a yes.
Never apply without approval. People review and explicitly submit each part. Nothing is implemented until every required step is approved.
Keep versions. Each confirmed set of structures is saved, so people can step back.
Show progress. A checklist shows each part of the setup and its state.
Flag gaps instead of guessing. The agent says what it couldn't draft and what it needs.
What happened
A staged path from an AI test to a launchable product, with a draft-first north star.
Over about five months, as the only designer and alongside my Expenses work, I delivered personas, before-and-after workflows, design rules from the executive requirements, several rounds of high-fidelity flows, the staged interaction model and a tested draft-first onboarding. An alpha proof of concept, built just before I joined, had shown the AI could create the structures. The next milestone was a beta proof of concept, still mainly a test of the AI, that would carry some of these design ideas and steer the next round of design toward a launchable MVP. I left Oracle in a layoff at the end of August 2025, before the beta was built.
Alongside the flows, I contributed AI interaction patterns to the core design system team and wrote a UX strategy with a toolkit of primers that helped engineers and product managers reason about agents, personas and workflows. I wrote a UX strategy that framed design as part of how the product is built, with lifecycle ownership, shared artifacts the team could learn from, and a roadmap for iterative improvement. Its practical form was a toolkit of primers and models that helped engineers and product managers reason about agents, personas and workflows.
What I'd measure: how often people change what the agent drafted, how often they undo or correct its edits, how often they approve a section without opening it, and the time from onboarding to an approved structure.
What I'd change: I'd test the drafted blueprint against a real customer's internal details much earlier, since public information gets the broad structure right and internal specifics are where the agent's limits show first. I'd agree on success measures with engineering at the start. And I'd put real setup screens into the flows sooner, to test which ones could be reused while that was still cheap to change.
"Chris brings big-picture thinking and strong execution, and he has a real talent for communicating ideas in a way that gets everyone aligned and energized."
— Yuwei Fu, Director of UX and my manager at Oracle