Amazon Alexa+ AI Workflow Orchestration
The Alexa platform received thousands of bug reports a day, most of them related or duplicate, with no way to connect them. Each ticket took a minimum of 20 minutes to understand and triage. Updating PMs and leadership was a separate manual process on top of that.
Clustering related bugs (avg 15 tickets per cluster) cut the number of issues needing separate diagnosis by roughly 65%.
I used that scale and lack of context to design a workflow orchestrator wrapped inside agent interfaces and developers' existing tools.
What I delivered:
Modeled ~65% fewer independent bug diagnoses
Built live AI prototypes for web console and IDE plugin
The Strategy
I observed that Alexa+ developer organization was losing time and accuracy across disconnected tools with no shared source of truth. I took it upon myself to map the friction points and discovered that context dropped after task handoffs. By interviewing engineers, solutions architects, and program managers, I was able to identify where automation could speed up the bug fixing process. I also participated in bug bashes to follow the journey of a bug firsthand.
Based on this information, I determined that orchestration had to happen in two different places:
The orchestrator agent needed to serve as a centralized, real-time source of truth.
The individual contributors needed this functionality integrated with existing tools.
To effectively scope a proof of design concept, I prioritized the 1P developer journey. After all, they carried the mental load and stress of addressing anomalies in code and customer experiences.
Grounded answers,
not just confident ones
The orchestrator agent pulled bug reports, ticket status, org direction, and documentation into one place, then did the harder work of interpreting that information for whoever was asking.
A developer got an answer scoped to implementation. A PM got the same underlying facts translated into impact and timeline.
Every answer carried a citation back to its source, so the interpretation was never separated from where it came from.
Context as design material
A PM and an SDE looking at the same bug need different things from it. Without that distinction, everyone gets the same interpretation of raw data, regardless of what they're actually trying to do with it.
The workflow orchestration carries context across surfaces: a conversation that starts in the web console can pick up in the IDE plugin without starting over, and the task carries forward with it.
That continuity reduces task switching and context loss.
Meet users where they’re at
Developers spend most of their day in the IDE, so improvements there have immediate, repeated impact.
The IDE already has rich context about their code (file structure, types, git history) which makes suggestions and fixes far more relevant than external tools.
Most importantly, catching issues at write-time keeps devs in flow and dramatically shortens feedback loops compared to finding problems at commit-time or run-time.