# Track SDK adoption after release

> Measure whether developers upgrade to a new customer-facing SDK version after launch and which accounts remain behind.

## Agent adaptation contract

- Canonical human page: https://agentry.sh/workflows/sdk-adoption-after-release
- Execution mode: on_demand
- Immutable automation template: none
- Applies to: devtools-api, open-source, b2b-saas
- Required example events: sdk_initialized, sdk_method_called
- Required Agentry resources: none declared
- Do not use when:
  - Do not use until the example events are mapped to observed project signals, the current onboarding state is verified, and live event/property reads prove the required data is present.
- Ask before using:
  - Which observed events map to sdk_initialized, sdk_method_called? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?
  - Which live properties provide sdk_initialized.sdk_version, sdk_initialized.language, sdk_initialized.account_id, sdk_method_called.sdk_version, sdk_method_called.language, sdk_method_called.account_id, sdk_method_called.endpoint, and which stable user or account identifier joins the signals?

This is an adaptable workflow example, not an API recipe. Map event and property names to the project's saved signal map, require status: "verified" from GET /v1/projects/:project_id/onboarding, and confirm the required signals through live event/property metadata and rows. Fetch current OpenAPI or query-blueprint details before making calls. Do not infer unattended authority from this page.

## Why this matters

SDK launches do not create value until customers actually upgrade. Product and developer relations teams need to know whether a release is spreading or sitting unread in a changelog.

## What you get

- Adoption curve by SDK version and language
- Accounts still using deprecated versions
- API usage volume by version
- Upgrade targets for CS or developer relations

## Walk through it

**You:**
> Did customers adopt the SDK version we released last week?

**Agent:**
> I'll find the latest release, then group SDK initialization and method calls by version.

```text
Endpoint: GET /v1/projects/:project_id/deploys
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fdeploys&method=get
Use query parameters, not a JSON body.
Query/filter concept:
  limit: 5
```

```text
Endpoint: POST /v1/projects/:project_id/analytics/query
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fanalytics%2Fquery&method=post
Custom HogQL goes in the OpenAPI-defined `query` field.
Concept fields:
  query: "SELECT properties.sdk_version AS version, properties.language AS language, count(DISTINCT properties.account_id) AS accounts, count() AS events FROM events WHERE event IN ('sdk_initialized','sdk_method_called') AND timestamp > now() - INTERVAL 30 DAY GROUP BY version, language ORDER BY accounts DESC"
```

## The output

The agent returns adoption by version and language, then calls out large customers still on old versions. It should recommend docs, outreach, or compatibility fixes depending on the pattern.

## Setting it up

Emit SDK usage events from the customer's application or API edge when requests include SDK metadata. Do not imply Agentry has an SDK; this workflow is about your product's customer-facing SDKs.

## Variations

- *"Show Python SDK adoption after the release."*
- *"Which enterprise accounts are still on deprecated versions?"*
- *"Compare error rate by SDK version."*