The Situation
As Alexa+ expanded to support both internal and external developers, onboarding into the SDK and agent ecosystem remained complex and highly supported. Builders of varying technical levels were required to jump between documentation, consoles, code, and support channels just to reach a usable starting point. This created ambiguity around required assets, effort, and expectations, and limited scalability by relying heavily on solutions architects and internal engineering support.
The Strategy
Rather than designing a traditional setup wizard, I framed onboarding as an agent-led experience—one that could evaluate the assets a developer provided and actively guide what to do next. The agent reasoned over inputs like APIs, SDKs, or partial agent definitions, identified what was missing, and helped scaffold the remaining steps. This reduced ambiguity while preserving flexibility for different developer entry points.
To communicate the full onboarding framework, I built an interactive jobs-to-be-done flow that maps each developer type across the three integration paths, from first connection through the release lifecycle.
I focused the design on a single, continuous onboarding flow that minimized context switching and helped developers understand both what to do and why. While technical work still occurred across tools, the agent served as the connective layer, maintaining context and managing expectations about effort and complexity throughout the process.
At a product level, I intentionally worked at a high-level conceptual depth to demonstrate the breadth of the developer experience and establish a reusable onboarding framework. This allowed the work to function both as a near-term MLP exploration and a North Star for scalable, self-service onboarding—aligned with company priorities around cost efficiency and developer autonomy.
Key Decisions
- Agent assists where it has signal; humans own what requires judgment. The framework distinguishes between decisions the agent can make autonomously (detecting endpoints, reading manifests, generating scope suggestions) and decisions that require explicit human sign-off (scope ownership, handoff contract, behavioral safety). This wasn’t a UI pattern — it was a product principle that shaped every step of the onboarding flow.
- Three integration types, one continuous experience. Rather than designing separate onboarding flows for API, MCP, and Agent Relay, I designed a single framework that branches at entry and converges at the release lifecycle. The integration type shapes the experience without fracturing it into three separate products.
- Jobs-to-be-done over feature documentation. Each step is framed around what the developer needs to be true before they can move forward, not what the platform does. This reframes onboarding from a configuration task into a series of resolvable developer needs. This makes it easier to identify where the agent could reduce friction versus where it would introduce risk.
- Simulation before testing. Placing Simulate as Step 3 (before Test, Certify, Deploy) was a deliberate sequencing decision. Simulation is low-stakes and developer-controlled; testing is documented and gate-based. Separating them protects developers from reaching a formal gate before they’ve had a chance to find and fix CX issues on their own terms.
The Outcomes
- Created a working prototype that demonstrated the feasibility and value of agent-led onboarding
- Established a shared onboarding framework for future self-service developer tools
- Kicked off cross-team collaboration across design, engineering, and program partners
- Helped scope design investment and clarify where deep UX work was most needed
- Bridged the gap between highly supported 1P workflows and self-supported onboarding for external developers




