[bitpshr]

Summary

When someone asks for a voice agent, onboard didn't know when it was done. A site that only embeds the agent widget never counted as wired, so check kept asking for SDK code, and the flow always ended by offering a text-to-speech clip. This makes the agent case end the way you'd expect:

• The widget counts. A page or component with <elevenlabs-convai> is wired, in check and right after sign-in.
• Only code that reads the key has to load it. The agents' browser SDKs (@elevenlabs/react, @elevenlabs/client, @elevenlabs/react-native) and the widget packages connect without the key, so an app that only uses those isn't sent to load_key. A server SDK, or code that names ELEVENLABS_API_KEY, still is.
• The last step is the agent. When the code names an agent the key can open, check ends on done with a link to talk to it and its dashboard page, instead of the TTS clip:
  • It looks up at most 3 IDs, the code's first, then the env file's (not .env.example), then agents.json, and stops at a 401/403.
  • An agent limited to an allowlist, or a private one, gets its page instead of the talk-to link. A private agent with no server code says the page can't connect until auth is off or a server signs the conversation.
  • An ID the key can't open (a docs sample, another account's) is skipped, and everything else gets the usual test request.
  • Links use the residency's app host (eu.residency.elevenlabs.io etc.), and the global app for any other saved value, as the API does.

Bumps the version to 1.9.0, since 1.8.0 is out. #175 still says 1.7.2 and will need a bump when it's rebased.

Testing

• cargo test: everything passes (onboard integration 28, workflow unit 246). New or changed:
  • a plain site with only the widget ends on done with both links and no load_key, both from check and right after sign-in
  • allowlisted and private agents get their page; a private agent behind the widget alone says what to change
  • a 404 (with a body) and a stand-in ID get the test request; a page without the widget still gets write_code
  • at most 3 lookups, and only 1 when the key can't read agents; a TTS app makes none
  • the widget from npm in a Vite app, and @elevenlabs/react in Next.js with the ID in .env.local, both end on the agent
  • only code that reads the key has to load it; the ID matcher and its order; residency hosts
  • an agent ID in the key's env file counts even outside the app (a monorepo's root .env.local) or under another --env-path name, and comes before agents in the project's other env files (.env.test etc.)
  • Dropping the non-2xx skip or the 401 stop makes these tests fail.
• Not run end to end with a real coding agent and sign-in yet.

[Copilot]

🟡 Changes recommended

The scan misses agent IDs stored only in a custom or external env file, causing browser-SDK apps to receive a TTS test offer instead of agent links.

1 open issue

• Read explicitly selected env files when detecting agent IDs · New

What changed in this PR

Updates onboarding so voice-agent projects finish with relevant agent links rather than a text-to-speech test offer, and bumps the CLI to 1.9.0.

Changes:

• Recognizes embedded widgets and skips key-loading guidance for browser-only integrations.
• Looks up project agent IDs and provides residency-aware links with guidance for private or allowlisted agents.
• Adds unit and integration coverage for agent discovery, access restrictions, and lookup limits.

File	Description
tests/​onboard_test.rs	Adds integration coverage for agent completion and lookup limits.
cli/​elevenlabs/​workflow/​onboard/​tests.rs	Tests widget detection, agent IDs, regional links, and key-loading decisions.
cli/​elevenlabs/​workflow/​onboard/​test_request.rs	Recognizes widget integrations in test-result messaging.
cli/​elevenlabs/​workflow/​onboard/​project.rs	Adds widget detection, key-use checks, and agent ID discovery.
cli/​elevenlabs/​workflow/​onboard/​connect.rs	Routes wired projects appropriately after sign-in.
cli/​elevenlabs/​workflow/​onboard/​check.rs	Adds agent lookups, completion links, and access guidance.
Cargo.toml	Bumps the package version to 1.9.0.
Cargo.lock	Synchronizes the locked package version.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Agent detection misses legacy unprefixed IDs and prioritizes unrelated env files over the selected env file, causing missing or incorrect agent links.

1 open issue

• Prioritize the selected env file’s agent ID · New

1 previously missed issue

In code that hasn't changed since last review

Recognize legacy unprefixed agent IDs

cli/​elevenlabs/​workflow/​onboard/​project.rs:473

This only searches for agent_, but existing agents can also have unprefixed 20-character IDs—for example, J3Pbu5gP6NNKBscdCdwB, returned by the create/list fixtures in wiremock/wire-test-cases.json. Such an ID in a widget or env file produces no candidates, so check still offers a TTS request instead of the agent links, even when the key can open it. Please also recognize legacy IDs in explicit agent-ID fields and add a regression case.

1 resolved since last review

• Read explicitly selected env files when detecting agent IDs

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Unrecognized saved residency values use the global API but generate unsupported residency-domain links, leaving successful agent lookups with unusable links.

No open issues 🎉

1 previously missed issue

In code that hasn't changed since last review

Fall back to sign-in origin for unsupported residency values

cli/​elevenlabs/​workflow/​onboard/​check.rs:231

An unrecognized saved residency such as euu-residency still uses the global API via settings::base_url_for, but this branch generates links on euu.residency.elevenlabs.io. A successful agent lookup therefore ends on done with unusable links. Restrict this branch to supported residency values so unknown values fall back to the sign-in origin, matching the API routing behavior.

1 resolved since last review

• Prioritize the selected env file’s agent ID

_{Review effort: Balanced}