01 / Where I started
I could build the screens, but I couldn’t answer why.
Aida is an AI-powered internal audit intelligence platform. I joined its first release when the designs were roughly 80% complete, finished the remaining product work, then took ownership of the agent flow underneath it.
I knew what each surface was for, but not why the system was shaped that way. Why was the assistant inside the insights document a separate agent from the main conversation AI? Why couldn’t it answer from the earlier conversation? I could ship the screen. I couldn’t yet defend the decision. That gap became the real work.
02 / The reframing
UX now serves the AI, not just the human.
In an AI-native product, UX has two consumers: the human and the agents.
The conversation summary made this tangible. I first read it as a display element for the user to skim. In practice, it also acts as the input for the document generator, avoiding the cost and noise of re-reading an entire conversation every time.
The summary regenerates after each prompt-and-response pair. It is character-capped for the interface, yet detailed enough for a downstream model. A separate form carries the specificity, allowing one concise artifact to serve both readers without maintaining a second machine-only summary.
03 / Taking ownership
From a flow I didn’t understand to one I designed.
The first flow map was difficult to follow. I was still learning the difference between an agent, a rule, and a system prompt. Instead of waiting for clarity, my business analyst and I proposed version two ourselves.
We worked backward from the data: what must be generated first, what depends on what, and where an agent earns its place. Developer guidance helped us shape the proposal into a buildable flow.
Chart agent stays separate and runs only when a chart is needed.
Document sections use distinct agents with focused responsibilities.
Widget agent reads the recent conversation and pre-fills parameters.
04 / The hardest decision
The fan-out, and what has to wait.
One agent writing the entire insights document would be simpler to build, but it would leave the user staring at a skeleton until everything finished.
The fan-out is a latency decision wearing an architecture costume.
A fetch-and-synthesise agent retrieves semi-raw information from the AI-ready database. That payload fans out to section agents for Introduction, Process Covered, Systems Covered, Key Risks, Common Issues, Common Root Causes, and charts when relevant. Each section controls its own formatting, and sections stream into the canvas as they finish.
Independent sections
Process Covered and Systems Covered can start together because neither needs the other’s output.
Dependent sections
Common Root Causes follows Common Issues. Introduction and Title wait until the document’s scope is known.
Human accountability stays wrapped around the generation: conversation remains on the left, editable content sits on the right, and every section carries feedback. That gives the team evidence to distinguish a weak model from a weak prompt.
05 / Testing honestly
Finding the seams between AI and rules.
I validated the widget agent through escalating UAT cases in Google AI Studio, with temperature set to zero, explicit expected outputs, and a fix protocol for each failure mode.
The sequence moved from a happy path to conflict rules, self-correction, ambiguity defaults, relative-date maths, and finally two multi-turn “chaos” transcripts where the user repeatedly changed their mind.
Deterministic business logic
Document classification, chart conflicts, section toggles, and ambiguity defaults were reliable.
Temporal reasoning
Relative dates produced inconsistent windows instead of clean, deterministic ranges.
Multi-turn state
Negation and correction slipped: after “forget Malaysia,” Malaysia could remain in scope.
The failures became design evidence. Dates and correction-tracking are exactly where a rule-based layer should validate AI output.
06 / Reflection
What this project was really about.
I came in to finish a set of screens. I left having owned an ambiguous AI system end to end: learning the concepts mid-project, correcting my understanding, proposing the flow, driving it to a buildable spec, and testing it honestly enough to know where it breaks.
The through-line under every decision was accuracy vs. latency vs. UX, with one question sitting above it: AI or a rule? The answer had to be made feature by feature, not once for the whole product.
That is the judgment this work represents—not only making an interface look right, but deciding why the system should work the way it does.