Ekho: an agent that keeps teams aligned, while the decision stays human
MY ROLE ON THE PROJECT
I designed Ekho AI as a personal exploration of agentic product design, focused on how AI agents can do meaningful work on a user’s behalf.
I owned the work end to end: framing the problem, defining the product strategy, designing the AI interactions and multi-agent system, and building the prototype. Without a PM or engineering team, I was responsible for the product and design decisions throughout the project.
The idea came from a real problem I had experienced firsthand while working with product and engineering teams through Stage Gates, where preparing the right evidence, surfacing risks, and aligning stakeholders can become a significant part of the work.
Launch the prototype in a new page
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, but got more scattered than ever: quick catch ups, conversations over chat and (tons of) AI written documentation 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 bottle neck, 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.
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 orchestrator instead, 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 stop Ekho before that happens.
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 plan to measure
Ekho is still 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.
