Ekho: an agent that keeps teams aligned, while the decision stays human
Launch the prototype in a new page
MY ROLE ON THE PROJECT
I designed Ekho AI on my own during an agentic design sprint, a focused programme for exploring how to design products where AI agents do real work on the user's behalf. Because it is a personal project, I worked solo and owned every part of it: I framed the problem, made the product and strategy calls, designed the AI interactions and the multi-agent system behind them, and built a prototype. There was no PM or engineering team, so every decision in this case study is mine.
What kept the work grounded was my own experience of working with product and engineering colleagues at real Stage Gates, which is where the idea came from.
Moving faster with AI saved time on one side but seemed to create more rework on the other
As AI sped up how quickly teams could produce and change work, it saved real time on the making side, but it seemed to push up rework on the other side of the process.
Cycles got shorter, so the formal checkpoints that used to keep Product, Design and Engineering aligned, such as Ready for Design and Ready to Build reviews, started happening less consistently, while the volume of documents, transcripts and design files grew and each of those sources changed more quickly.
We were still aligning but rework, scope drift and the familiar question of when exactly something had been decided started to happen more often, each of which quietly costs review time, delivery time and trust in the plan.
Alignment didn't disappear, it just got more scattered: quick catch ups, conversations over chat and doumentation sent over email (and never read)
I kept seeing this in my own work and in the wider team.
At the same time, engineering moving faster changed the shape of my own days. When developers can build and change things quickly with AI, design becomes the slower link, and I found myself spread across more work in parallel, jumping between projects and picking each one back up mid-thought. Holding an accurate picture of what had been decided across all of them, from memory, stopped being realistic.
Sitting with this pushed me to separate two kinds of ambiguity.
Ambiguity about the problem itself, meaning what users need and what solution might work, is a normal part of a designer's job and research can shrink it.
Ambiguity about the team's shared understanding is different: what was decided, what is still open, and which source is now current. That second kind does not shrink with more exploration, and it needs its own kind of support.normal part of a designer's job and research can shrink it. Ambiguity about the team's shared understanding is different: what was decided, what is still open, and which source is now current. That second kind does not shrink with more exploration, and it needs its own kind of support.
Source: Upwork
Turning a personal workaround into a product direction
Before Ekho existed, I had already started using AI myself to pull sources together and rebuild context before I presented work, comparing transcripts, documentation and design files to catch inconsistencies that would otherwise show up too late. That habit is what made me wonder whether the same behaviour could become something a whole team relies on, rather than a private trick of mine. I set my objective as reducing late surprises at the moments when work crosses from one stage to the next.
Before designing any screen, I fixed one principle that shaped everything after it: Ekho reads, compares and surfaces, and it never decides or acts on the team's behalf.
Before designing any screen, I fixed one principle that shaped everything after it: Ekho reads, compares and surfaces, and it never decides or acts on the team's behalf.
Scoping memory to a project, with a quick way in for first-time use:
My first model was the simplest one: let users pick a set of sources, run a single scan and read the result.
It handled quick checks well, but a project is not a one-off. It keeps changing, and a single scan would have to be rebuilt from scratch every time something moved.
I chose a persistent project with its own knowledge library instead, because it gives Ekho a clear boundary around what it is allowed to know for that piece of work.
To avoid forcing everyone through a long setup before they saw any value, I kept Quick Scan as a lightweight second way in, one that can be saved into a project later if the work turns out to be worth revisiting.
Making several specialist agents feel like one assistant
Working through the checks each gate needed, I realised a single generalist assistant was not enough, because the questions involved, such as whether two sources contradict each other or whether something expected is simply absent, really do call for different lenses.
My first direction made those agents visible and selectable, so a user could choose which one to run.
I moved away from it because it hands the coordination back to the very people Ekho is meant to help: they would have to learn what each agent does, judge which is relevant, and stitch the review together themselves.
I chose a single Ekho instead, with an orchestrator that passes the review to specialist agents behind the scenes.
During a scan the user watches those perspectives work through the project one after another, and each finding shows which agent raised it, so the reasoning stays traceable while the mental model stays simple. For the agent characters I borrowed from famous fictional detectives and added small touches that might make someone smile.
Choosing findings a team can question over a single readiness score:
The result of a scan could have been one number, a readiness percentage that is quick to glance at.
The longer I looked at that option, the more it worked against the problem I was solving. A score does not tell anyone what the inconsistency actually is, how Ekho reached it, or what to do next, and it would have turned Ekho into one more opaque authority instead of a tool that explains itself.
I built the result as a report of individual findings, each carrying its evidence and a plain statement of how confident Ekho is.
I split findings into two types because they ask for different responses.
A conflict is two sources disagreeing on the same point, and it usually needs a clarification or a decision.
A data gap is something expected that is missing or cannot be validated, and it needs either more information or a deliberate acknowledgement that it is still unknown.
For a team this means acting on a specific, evidenced issue before a gate rather than arguing about a number, and it keeps uncertainty visible and actionable instead of hidden behind a confident total.
Keeping the last decision with people, not for the tool
Spotting an inconsistency is not the same as knowing what to do about it, so each finding can be resolved, deferred, sent back for clarification, or corrected when Ekho has read the situation wrongly.
The line between resolving and deferring mattered most to me. Both take a finding off the immediate list, but they leave different traces: one records that the issue was handled, the other records that the team saw it and chose to wait. I wanted the project history to hold on to that difference rather than flatten every closed item into the same thing.
For closing the loop, Ekho could in principle comment on a document, message a colleague or update a source directly, which would save the most time. I deliberately stopped short of that.
Ekho drafts a message from a finding, adapted for Slack, Teams or email, and the user reviews it and decides whether to send.
That drew a boundary I kept across the whole product: sources are what Ekho reads from, channels are where the person communicates, and Ekho never edits, posts or sends on its own.
Making sure a stale report never looks current
A scan can only ever reflect what Ekho could see at one moment.
If an old report kept looking authoritative after its sources had shifted, Ekho would create exactly the false confidence it was built to prevent, so a report is marked as needing a rescan the moment its underlying sources change. I extended this with Monitoring, which lets a team schedule recurring scans and notice drift between formal gates instead of only when someone happens to remember.
The same concern shaped Ask Ekho, a conversational way to ask what the latest decision on something was or where a requirement first came up. An open-ended assistant would have made it hard to tell what any answer rested on, so I scoped every conversation to a single project. Answers stay grounded in that project's sources, and if those sources have moved on since the last scan, the answer is flagged as possibly stale.
Treating transparency and human oversight as design constraints
As I understand it, a workplace tool like this would sit in a lower-risk category, so I treated those expectations as a design reference rather than a compliance claim I am in a position to make.
In practice they reinforced decisions I had already been drawn to: confidence that is explained, evidence that is visible, honesty about missing information, no autonomous actions, and a per-project boundary that also limits how much of a team's conversation the system ever holds.
What I would measure with a real team
Ekho is a prototype and I have no outcome data, so I cannot claim it reduced rework or improved alignment. If a team used it, these are the things I would track, grouped by the question each one answers:
Whether it does its job: how often a design or PRD changes after a review or handoff in ways that could have been caught earlier, the time from first draft to team acceptance, and the number of issues surfaced that would otherwise have been found late or missed.
Whether it eases the anxiety around gates: how prepared people feel going into a review or handoff, and how many unpleasant surprises they report during one.
Whether people trust it (or overtrust it): how often they override or disagree with Ekho's findings, which tells me both whether its judgement is sound and whether people trust it enough to act on it.
What I took away
Complexity can live inside the system without reaching the user, as long as the reasoning behind a result stays traceable.
Showing evidence and admitting uncertainty earned more trust, in my own testing of the flows, than a single confident answer ever could.
Keeping the final decision with people made the product both easier to design and easier to justify, and it is the principle I would carry straight into other agentic work.
The honest next step is validation with a live team, since nothing here has been proven outside the prototype.
Check out more projects
What an AI sales tool taught me about trust and adoption
I designed an AI tool to help sales reps create learning recommendations faster and reduce reliance on SMEs. Early adoption was promising, but over time the project revealed bigger challenges around trust, workflows, and product adoption.
Time from lead to first offer dropped
Revealed how AI adoption depends on trust, existing workflows, and user behavior
Helping QA learners learn more confidently with an AI tutor built for trust
I led the end-to-end design of Ela, QA’s AI-powered learning assistant, transforming an inherited prototype into a trusted and scalable product in just two months. Designed to reduce friction and support learning momentum, Ela is now adopted by 80+ client accounts, holds a 4.5/5 satisfaction score, and has influenced the development of new AI capabilities across the platform.
4.5/5 Avg. Rating
1,178 Client Accounts
+34% Adoption Growth
From guesswork to guardrails: a panel redesign that cut client setup errors by 26%
I redesigned a complex admin tool used daily by Sales and Customer Success teams to configure enterprise client settings. The legacy system made critical errors easy. I rebuilt it around clarity, feedback, and safer workflows, reducing support needs and user stress.
Drop in support tickets tied to misconfiguration
New CSMs reporting higher confidence earlier
Helping Circus Street learners feel at home after a platform transition, without increasing support burden
I unified QA Learning’s Course and Lesson experience during the merger of Circus Street and Cloud Academy into a single platform, helping Circus Street learners adapt to a more complex UX without increasing support burden or disrupting engagement.
0 increase in helpdesk tickets: smooth client transition
Users relied less (-20%) on secondary tabs after restructuring page hierarchy
From hashtag challenge to a learning habit that lifted monthly cashflow by 18%
I designed a 3-month challenge that increased engagement, reduced churn, and boosted cashflow. 20% of participants stayed active three months after—well beyond typical subscription periods.
+18% increase in MoM upfront cashflow
1,178 Client Accounts
+34% Adoption Growth