update

Agent Twin Discovery

v0.1.0

Agents can now discover, evaluate, and acquire API twins on their own — scan dependencies, browse the catalog, subscribe, and request new twins, all governed by org-level policy.

Agents can now discover, evaluate, and acquire API twins on their own. An agent working on a project that depends on Stripe, Plaid, and Twilio can scan its dependencies, find matching twins in the WonderTwin catalog, subscribe to the ones it needs, and request twins for services that aren’t covered yet — all governed by org-level policy that keeps admins in control.

New capabilities

Twin catalog

Agents browse the full WonderTwin catalog — 37 twins across payments, messaging, CRM, commerce, analytics, and more. Search by name, filter by category or tier (community / commercial). Each listing shows API coverage percentage, endpoint count, SDK language, auth pattern, and webhook support.

Key commands:

  • wt catalog — browse all available twins
  • wt catalog --mine — see what your org has (installed, entitled, available)
  • wt catalog <name> — detail view for a specific twin

Project scanning

Agents detect what a project needs by parsing dependency files. Go (go.mod) and Node.js (package.json) are supported. Each detected SDK is matched against the catalog, showing whether a twin exists and what action is available.

Key commands:

  • wt scan — detect project dependencies and match against catalog

Subscribe

One command to acquire access to any twin. The agent says “I want this” and the backend resolves the outcome based on org state and policy: already entitled, subscribed, trial started, upgrade required, or approval requested.

Key commands:

  • wt subscribe <twin> — acquire access to a twin

Twin requests

When no twin exists, agents can request one. Pro orgs get structured request tracking with deduplication. Community users get a GitHub issue link. Every request is a demand signal that feeds WonderTwin’s build prioritization.

Key commands:

  • wt request <service> — request a twin that doesn’t exist
  • wt request --list — check request status

Discovery policy

Org admins control what agents can do through a policy model. Allow or block community twins, self-build, auto-subscribe, and twin requests. Set spend limits and approval routing. Policy is fetched from the platform — agents follow it deterministically.

Discovery telemetry

Agent interactions (catalog searches, scan results, subscriptions, requests) are captured as discovery telemetry — architecturally separate from twin behavioral telemetry. Agent votes (searches for twins that don’t exist) surface unmet demand.

MCP tools

Six discovery tools available via MCP for agent frameworks that require it: wt_catalog, wt_catalog_detail, wt_subscribe, wt_request, wt_request_list, wt_scan. All return structured JSON.

Portal catalog

Web-based catalog browser at /catalog (public, unauthenticated) and /{org}/catalog (authenticated, with entitlement badges and subscribe actions).

Known limitations

  • No recommendations yet. wt scan --recommend is accepted but returns “coming soon.” Phase 2.
  • Agent votes not emitted by CLI. The telemetry endpoint is built; CLI commands don’t emit events yet. Quick follow-up.
  • Policy management UI not built. Policy can be set via API but there’s no admin page in the portal yet. Defaults work without configuration.
  • Portal uses mock API. The web catalog uses fixture data, not the real wondertwin-app backend. Integration is a follow-up.
  • No approval workflow UI. When policy requires admin approval, the request is recorded but there’s no approve/deny interface yet.

What’s next

v0.1.1 will address UX feedback and wire up the remaining connections — agent vote emission, portal-to-backend integration, and any command adjustments based on early usage. Phase 2 (recommendations, policy management UI, approval workflows) is gated on customer signal from v0.1.0.

→ Read the technical changelog: v0.1.0 release notes