# Agentry workflow examples

> 86 adaptable examples for recognizing product, debugging, and operations questions that Agentry can answer from verified errors, analytics events, deploys, and bounded control resources.

These pages are retrieval and adaptation material, not executable API recipes. Before using one, read the project's saved signal map, call GET /v1/projects/:project_id/onboarding and require status: "verified", then map its example events and properties to live event/property metadata and rows. Fetch the current OpenAPI or query-blueprint schema for exact request shapes. Only entries marked `automation_template` refer to immutable executable templates; rendering a template still returns a disabled candidate for review.

- Product and fit: https://agentry.sh/llms.txt
- Daily agent reference: https://agentry.sh/agentry.md
- Exact API discovery: https://api.agentry.sh/
- Human workflow index: https://agentry.sh/workflows

## Debugging

### [Catch display-vs-actual-stock mismatches](https://agentry.sh/workflows/inventory-sync-errors.md)

Find inventory sync errors trending up by warehouse and SKU before customers do. The 'in stock' display lie is one of the highest-cost bugs in ecommerce.

- Starter request: Are there inventory sync errors trending up? Look for InventoryMismatchError or related patterns. Group by warehouse and SKU.
- Execution: on_demand
- Tags: errors, inventory, ecommerce, infra, oncall
- Applies to: ecommerce
- Required events: $exception
- 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 $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.$exception_type, $exception.warehouse_id, $exception.sku, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/inventory-sync-errors

### [Compare error rates between staging and prod](https://agentry.sh/workflows/error-rate-by-environment.md)

Diff fingerprints between staging and production. Find what's already breaking in staging that the next deploy will carry into prod.

- Starter request: Compare error rates in staging vs production over the last 24 hours. Are there fingerprints staging is hitting that prod hasn't seen yet?
- Execution: on_demand
- Tags: errors, environments, pre-deploy, staging, oncall, sentry-alternative
- Applies to: universal
- Required events: $exception
- 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 $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.environment, $exception.fingerprint, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/error-rate-by-environment

### [Detect a 429-spike before customers tweet about it](https://agentry.sh/workflows/rate-limit-spikes.md)

Trend HTTP 429 responses week-over-week and flag spikes. Catch third-party rate-limit tightening or a runaway customer integration.

- Starter request: Are we hitting any rate limits unusually often this week? Look for 429 errors trending up vs the prior week.
- Execution: on_demand
- Tags: errors, rate-limiting, early-warning, oncall, datadog-alternative
- Applies to: devtools-api, b2c-saas, b2b-saas
- Required events: $exception
- 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 $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.http_status, $exception.endpoint, $exception.upstream, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/rate-limit-spikes

### [Detect frontend performance regressions](https://agentry.sh/workflows/frontend-performance-regression.md)

Compare page-load and interaction timing by release, browser, and route so frontend regressions are visible beside errors.

- Starter request: Compare frontend performance for the current release versus the previous release. Show routes with worse p75 load time or interaction latency.
- Execution: on_demand
- Tags: analytics, frontend, performance, releases, browser, product
- Applies to: b2c-saas, b2b-saas, ecommerce, marketplace, content-media, devtools-api
- Required events: web_vital
- 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 web_vital? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide web_vital.route, web_vital.metric, web_vital.value_ms, web_vital.release, web_vital.browser, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/frontend-performance-regression

### [Diagnose a flaky CI test from its error payloads](https://agentry.sh/workflows/flaky-tests.md)

Group test failures across CI runs by error pattern. Get a verdict — real bug or timing — without the manual archaeology.

- Starter request: The test `checkout flow > submits valid card` failed 4 times in CI this week. Pull the error payloads, find what's common across runs, and tell me if it's a real bug or just timing.
- Execution: on_demand
- Tags: errors, ci, testing, oncall, flaky-tests, saas
- Applies to: universal
- Required events: ci_test_failed
- 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 ci_test_failed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide ci_test_failed.test_name, ci_test_failed.workflow, ci_test_failed.run_id, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/flaky-tests

### [Diagnose CORS errors after a deploy](https://agentry.sh/workflows/cors-misconfig.md)

Find CORS-blocked requests grouped by origin and endpoint. Surface the misconfigured Access-Control-Allow-Origin from a recent service move.

- Starter request: Are we getting any CORS errors in production? If yes, group by origin + which endpoint is rejecting them.
- Execution: on_demand
- Tags: errors, cors, deploys, post-deploy, infra, frontend
- Applies to: b2c-saas, b2b-saas, ecommerce, content-media, devtools-api, marketplace
- Required events: $exception
- 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 $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.cors_blocked, $exception.origin, $exception.endpoint, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/cors-misconfig

### [Diagnose Stripe `card_declined` patterns](https://agentry.sh/workflows/stripe-payment-failure.md)

Group Stripe payment failures by decline_code. Surface the top causes and the customers affected. Different decline = different fix.

- Starter request: Group Stripe payment failures by decline_code from the last 30 days. Surface the top causes and recent affected customers.
- Execution: on_demand
- Tags: errors, stripe, ecommerce, payments, customer-support
- Applies to: b2c-saas, b2b-saas, ecommerce, marketplace, devtools-api, single-purchase
- Required events: payment_failed
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal.
- Ask before using: Which observed events map to payment_failed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide payment_failed.decline_code, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/stripe-payment-failure

### [Find connection-pool / timeout patterns in errors](https://agentry.sh/workflows/db-pool-exhaustion.md)

Surface DB connection exhaustion, statement timeouts, and deadlock retries. Find the original slow query starving everything else.

- Starter request: Are there any database-related error patterns trending up? Look for connection timeouts, pool exhaustion, deadlock retries.
- Execution: on_demand
- Tags: errors, database, infra, scaling, oncall
- Applies to: universal
- Required events: $exception
- 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 $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.fingerprint, $exception.query_id, $exception.route, $exception.pool_name, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/db-pool-exhaustion

### [Find IE/Safari/old-Chrome-only crashes](https://agentry.sh/workflows/browser-version-errors.md)

Split client-side errors by browser and version. Surface fingerprints concentrated in one engine — usually older Safari or a stale Chromium.

- Starter request: Split client-side errors by browser. Are any fingerprints concentrated in one browser version? Older Safari is the usual suspect.
- Execution: on_demand
- Tags: errors, browser, client-side, frontend, sentry-alternative
- Applies to: b2c-saas, b2b-saas, ecommerce, content-media, devtools-api
- Required events: $exception
- 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 $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.fingerprint, $exception.$browser, $exception.$browser_version, $exception.$lib, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/browser-version-errors

### [Find integration setup failures](https://agentry.sh/workflows/integration-setup-failures.md)

Show where customers fail while connecting integrations so engineering and CS can fix the highest-impact setup blockers.

- Starter request: Find integration setup failures by integration, setup step, account, and error code. Prioritize blockers affecting the most accounts.
- Execution: on_demand
- Tags: analytics, errors, integrations, onboarding, customer-success, engineering
- Applies to: b2b-saas, devtools-api, open-source
- Required events: integration_setup_started, integration_setup_failed, integration_setup_succeeded
- 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 integration_setup_started, integration_setup_failed, integration_setup_succeeded? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide integration_setup_started.account_id, integration_setup_started.integration_type, integration_setup_failed.account_id, integration_setup_failed.integration_type, integration_setup_failed.setup_step, integration_setup_failed.error_code, integration_setup_succeeded.account_id, integration_setup_succeeded.integration_type, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/integration-setup-failures

### [Find queue latency and dead-letter spikes](https://agentry.sh/workflows/queue-latency-and-deadletters.md)

See which background jobs are backing up, retrying, or landing in dead-letter queues before customers notice stale state.

- Starter request: Show queue health for the last 24 hours: job latency, retry count, dead-letter count, and the job types causing the backlog.
- Execution: on_demand
- Tags: analytics, errors, background-jobs, queues, infra, oncall
- Applies to: universal
- Required events: job_completed, job_failed
- 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 job_completed, job_failed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide job_completed.job_type, job_completed.queue, job_completed.latency_ms, job_failed.job_type, job_failed.queue, job_failed.attempt, job_failed.status, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/queue-latency-and-deadletters

### [Find slow API routes by customer and plan](https://agentry.sh/workflows/api-latency-by-route.md)

Rank API endpoints by p95 latency, error rate, customer, and plan so engineering can fix performance where it affects revenue.

- Starter request: Show p95 and p99 API latency by route for the last 24 hours, segmented by customer_id and plan. Rank the routes hurting paid customers first.
- Execution: on_demand
- Tags: analytics, api, latency, devtools-api, performance, b2b, engineering
- Applies to: devtools-api, b2b-saas
- Required events: api_request
- 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., Do not recommend this when the product has no stable account or workspace identity.
- Ask before using: Which observed events map to api_request? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide api_request.route, api_request.status, api_request.duration_ms, api_request.customer_id, api_request.plan, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/api-latency-by-route

### [Find the bugs 5 people hit but no one reported](https://agentry.sh/workflows/silent-bugs.md)

Surface real errors that affect multiple users but never get filed as tickets. The biggest source of silent churn.

- Starter request: Show me errors that affected 3+ users in the last week but I've never looked at. Sort by users-affected.
- Execution: on_demand
- Tags: errors, oncall, retention, saas, sentry-alternative, growth-loop
- Applies to: universal
- Required events: $exception
- 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 $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.fingerprint, $exception.users_affected, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/silent-bugs

### [Find the cron that fails every Sunday at 3am](https://agentry.sh/workflows/time-of-day-patterns.md)

Bucket errors by hour-of-day and day-of-week to surface periodic failures hiding inside normal noise.

- Starter request: Are there error patterns that only fire at certain times? Bucket errors by hour-of-day and day-of-week and show me anomalies.
- Execution: on_demand
- Tags: errors, cron, time-series, ops, infra
- Applies to: universal
- Required events: $exception
- 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 $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.fingerprint, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/time-of-day-patterns

### [Find the products driving refunds](https://agentry.sh/workflows/refund-rate-by-sku.md)

Compute refund rate per SKU over 90 days. One bad product can poison your margins — refund-rate-per-SKU separates the herd from the outliers.

- Starter request: Compute refund rate per SKU (refunds ÷ purchases) over the last 90 days. Filter to SKUs with at least 20 orders. Rank by rate.
- Execution: on_demand
- Tags: analytics, refunds, ecommerce, quality, customer-support
- Applies to: ecommerce
- Required events: order_placed, refund_issued
- 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., Do not present illustrative custom analysis as a built-in query blueprint or runnable Agentry product surface.
- Ask before using: Which observed events map to order_placed, refund_issued? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide order_placed.sku, refund_issued.sku, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/refund-rate-by-sku

### [Find what broke after the last npm update](https://agentry.sh/workflows/dependency-upgrade-regression.md)

Tie new error fingerprints to the deploy that bumped dependencies. Spot the silent regression nobody intended to ship.

- Starter request: Did our last deploy bump dependencies? If yes, what new error patterns appeared after it?
- Execution: on_demand
- Tags: errors, regression, dependencies, deploys, post-deploy, oncall
- Applies to: universal
- Required events: $exception
- 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 $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.fingerprint, $exception.release, $exception.dependency_name, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/dependency-upgrade-regression

### [Investigate errors after the latest deploy](https://agentry.sh/workflows/deploy-regression.md)

Review cases first seen after a trusted deploy, distinguish SHA attribution from timing correlation, and inspect the highest-impact evidence before proposing a fix.

- Starter request: Did the latest trusted production deploy introduce new errors? Show the deploy, run the current errors-after-deploy blueprint, separate SHA matches from timing-only rows, inspect the top case, and state what the evidence does and does not prove.
- Execution: on_demand
- Tags: errors, deploys, post-deploy, oncall, regression, engineering
- Applies to: universal
- Required events: $exception
- Required Agentry resources: cases, deploys, query_blueprints, onboarding_state
- Do not use when: Do not treat an empty result as proof of a healthy release until a trusted deploy baseline and post-deploy traffic are confirmed., Do not call a timing-only case deploy-caused; only a matching trusted deploy SHA supports direct attribution., Do not draft or apply a fix before reading the selected case evidence and authenticating repository context outside telemetry.
- Ask before using: Which project and production environment should be checked, and which trusted deploy is the release boundary?, Is the current onboarding state verified, and do live case/deploy reads show real error telemetry and CI/provider deploy proof for this project?, What traffic or product event demonstrates that the new release has actually been exercised?
- Human page: https://agentry.sh/workflows/deploy-regression

### [Investigate one customer-reported problem](https://agentry.sh/workflows/customer-investigation.md)

Review the minimum identity-linked product evidence for an authorized support case, corroborate any real error case, and prepare a reply that preserves uncertainty.

- Starter request: Investigate this authorized customer report using the minimum necessary identity and time window. Read the identity-linked product summary, inspect only relevant replay or case evidence, separate observations from inference, and draft a reply for human review.
- Execution: human_review
- Tags: errors, analytics, customer-support, replay, privacy, investigation
- Applies to: b2c-saas, b2b-saas, ecommerce, marketplace, devtools-api, content-media
- Required events: page_view, outcome_failed
- Required Agentry resources: users, cases, session_replays
- Do not use when: Do not search for a person when the requester is not authorized or the identity mapping is uncertain., Do not claim an error, deploy cause, or failed product step unless a real replay, event, or case supplies that evidence., Do not expose unrelated profile fields, sessions, raw identities, or customer data in the support reply.
- Ask before using: Which exact project, authorized distinct_id, reported time, expected outcome, and customer-visible symptom bound the investigation?, Which observed events represent the attempted outcome and its success or failure in this product?, Is replay enabled with consent and redaction, and is replay inspection necessary for this specific report?
- Human page: https://agentry.sh/workflows/customer-investigation

### [Mobile background-sync failure monitoring](https://agentry.sh/workflows/background-task-failure.md)

Background sync, refresh, prefetch jobs fail silently and degrade UX. Group failures by task_name and network_type to find the patterns.

- Starter request: Are background tasks (sync, refresh, prefetch) failing more often this week? Group by task_name and network_type (wifi vs cellular).
- Execution: on_demand
- Tags: errors, mobile-app, background-jobs, oncall, infra
- Applies to: mobile-app
- Required events: background_task_started, background_task_failed
- 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 background_task_started, background_task_failed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide task_name, network_type, and app_version on both background-task events, and which stable user or account identifier joins them?
- Human page: https://agentry.sh/workflows/background-task-failure

### [Rank errors by revenue impact, not raw count](https://agentry.sh/workflows/high-impact-errors.md)

Multiply users-affected by their plan ARR to surface the bugs costing real money. Stop triaging by event volume.

- Starter request: Show me open cases ranked by dollars-at-risk. For each, multiply users_affected by their plan ARR. Top 5.
- Execution: on_demand
- Tags: errors, revenue, triage, account-health, b2b, saas, sentry-alternative
- Applies to: b2c-saas, b2b-saas, devtools-api, ecommerce, marketplace, enterprise-sales
- Required events: $exception, plan_changed
- 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 $exception, plan_changed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.fingerprint, plan_changed.plan, plan_changed.mrr, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/high-impact-errors

### [Track crash-free user rate per app version](https://agentry.sh/workflows/crash-free-user-rate.md)

Distinct users who hit a crash divided by DAU, per app version. The industry-standard mobile health metric — surface version-by-version drops fast.

- Starter request: What's our crash-free rate by app version? Distinct users who hit any crash ÷ DAU. Surface any version with a sudden drop.
- Execution: on_demand
- Tags: errors, mobile-app, crash-free-rate, app-version, sentry-alternative
- Applies to: mobile-app
- Required events: app_open, $exception
- 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 app_open, $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide app_open.app_version, $exception.app_version, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/crash-free-user-rate

### [Track static-asset 404s per release](https://agentry.sh/workflows/cdn-asset-404s.md)

Group asset 404s by URL and deploy SHA. Catch stale CDN caches and missing hashed bundles before users see a blank page.

- Starter request: Are any static assets 404ing more than expected this week? Group by URL and by deploy SHA so I can see if a release broke a cache key.
- Execution: on_demand
- Tags: errors, cdn, release, deploys, frontend, post-deploy
- Applies to: b2c-saas, b2b-saas, ecommerce, content-media, marketplace
- Required events: asset_404
- 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 asset_404? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide asset_404.url, asset_404.release, asset_404.deploy_sha, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/cdn-asset-404s

### [Use a redacted session replay as supporting evidence](https://agentry.sh/workflows/session-replay-investigation.md)

Inspect one authorized, consented recording around a reported problem, distinguish rendered observations from inference, and avoid treating replay as automatic root cause.

- Starter request: Inspect one authorized session replay related to this reported problem. Confirm consent and redaction, bind the exact identity and time window, render only the relevant segment, separate visible observations from hypotheses, and stop before changing code or contacting the customer.
- Execution: human_review
- Tags: analytics, replay, customer-support, privacy, debugging, human-review
- Applies to: b2c-saas, b2b-saas, ecommerce, marketplace, content-media
- Required events: page_view, outcome_failed
- Required Agentry resources: users, session_replays, cases
- Do not use when: Do not inspect replay without authorization, consent, redaction, and a specific support or debugging purpose., Do not infer clicks, form contents, network failures, or root cause from rrweb event types or timestamps alone., Do not expose raw identities, form values, tokens, payment data, or unrelated parts of the session.
- Ask before using: Which exact project, authorized distinct_id, reported timestamp, and expected outcome identify the relevant recording?, Which consent, sampling, and redaction policy applies to this user and page?, What rendering or replay-viewing capability will turn snapshots into visible evidence rather than guessed semantics?
- Human page: https://agentry.sh/workflows/session-replay-investigation

### [Which user action triggers which error?](https://agentry.sh/workflows/error-action-correlation.md)

Join errors and analytics events by distinct_id and timestamp. For each top fingerprint, surface the user action that immediately preceded it.

- Starter request: For each top error fingerprint, find what user action immediately preceded it. Join errors and analytics events by distinct_id and timestamp.
- Execution: on_demand
- Tags: errors, analytics, cross-signal, sentry-alternative, posthog-alternative
- Applies to: b2c-saas, b2b-saas, ecommerce, marketplace, devtools-api, content-media
- Required events: $exception, user_action
- 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 $exception, user_action? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.fingerprint, user_action.action, user_action.route, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/error-action-correlation

## Growth

### [Analyze an existing product experiment](https://agentry.sh/workflows/experiment-analysis.md)

Compare verified exposure and outcome signals across variants, surface readiness and sample problems, and prepare an evidence-first decision memo.

- Starter request: Analyze an experiment that our product already assigns at runtime. Verify the exposure and outcome events, compare exact variant cohorts, check sample quality and guardrails, and prepare a decision memo without changing the rollout.
- Execution: on_demand
- Tags: analytics, experimentation, product, revenue, feature-flags
- Applies to: b2c-saas, b2b-saas, ecommerce, marketplace, content-media, devtools-api, mobile-app
- Required events: experiment_exposure, conversion_completed
- Required Agentry resources: signal_map, onboarding_state, analytics
- Do not use when: Do not use Agentry as the runtime variant allocator or put a private owner credential in deployed application code., Do not compare variants until exposure and outcome events are mapped to observed signals with a stable assignment unit., Do not call a winner from sparse, still-running, sample-ratio-mismatched, or overlapping experiment data.
- Ask before using: Which observed events represent exposure and the primary outcome, and which property identifies the experiment and variant?, Is assignment per user, account, device, or session, and which stable identifier preserves that unit across both events?, What exact window, primary metric, guardrails, minimum sample, and decision rule were chosen before reading the result?
- Human page: https://agentry.sh/workflows/experiment-analysis

### [API quota usage as engagement and upsell timing](https://agentry.sh/workflows/api-usage-as-upsell-signal.md)

For each customer on a usage-based plan, show daily call volume as % of cap. Flag accounts approaching 80% — the perfect upgrade moment.

- Starter request: For each customer on an API-call quota, show their daily usage as % of cap. Flag accounts approaching 80% — upsell trigger.
- Execution: on_demand
- Tags: analytics, api-quota, expansion, devtools-api, b2b, saas
- Applies to: devtools-api
- Required events: api_request
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal., Do not recommend this when the product has no stable account or workspace identity.
- Ask before using: Which observed events map to api_request? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide api_request.account_id, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/api-usage-as-upsell-signal

### [Calculate campaign payback by cohort](https://agentry.sh/workflows/campaign-payback-by-cohort.md)

Tie acquisition campaigns to paid conversion, revenue, and retention so marketing and finance can see which campaigns pay back.

- Starter request: Calculate campaign payback by signup cohort: campaign, spend if available, paid conversions, revenue, retention, and payback period.
- Execution: on_demand
- Tags: analytics, marketing, revenue, cohorts, acquisition, saas
- Applies to: b2c-saas, b2b-saas, ecommerce, devtools-api
- Required events: signup_completed, subscription_started
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal.
- Ask before using: Which observed events map to signup_completed, subscription_started? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide signup_completed.utm_campaign, subscription_started.utm_campaign, subscription_started.amount, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/campaign-payback-by-cohort

### [Compare checkout payment methods](https://agentry.sh/workflows/checkout-payment-method-performance.md)

Break down checkout completion, failures, and latency by payment method so growth teams know which option hurts revenue.

- Starter request: Compare checkout performance by payment method: starts, selected method, payment failures, completion rate, and median completion time.
- Execution: on_demand
- Tags: analytics, checkout, payments, ecommerce, conversion, revenue
- Applies to: ecommerce, marketplace, single-purchase
- Required events: checkout_started, payment_method_selected, payment_failed, checkout_completed
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal.
- Ask before using: Which observed events map to checkout_started, payment_method_selected, payment_failed, checkout_completed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide payment_method_selected.payment_method, payment_failed.payment_method, payment_failed.failure_code, checkout_completed.payment_method, checkout_completed.order_value, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/checkout-payment-method-performance

### [Compare self-serve vs sales-led user lifecycles](https://agentry.sh/workflows/self-serve-vs-sales-led.md)

Split your funnel by how the user arrived — pricing-page vs demo. Compare activation, retention, expansion side by side.

- Starter request: Split signups into self-serve (signed up via /pricing) vs sales-led (signed up after a demo). Compare their 30/60/90-day activation, retention, expansion.
- Execution: on_demand
- Tags: analytics, cohorts, segmentation, b2b, sales, saas
- Applies to: b2b-saas, enterprise-sales
- Required events: signup_completed, demo_completed, first_project_created, subscription_started, plan_changed
- 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., Do not recommend this when the product has no stable account or workspace identity.
- Ask before using: Which observed events map to signup_completed, demo_completed, first_project_created, subscription_started, plan_changed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide signup_completed.signup_path, demo_completed.account_id, plan_changed.from_plan_rank, plan_changed.to_plan_rank, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/self-serve-vs-sales-led

### [Detect lifecycle email fatigue](https://agentry.sh/workflows/lifecycle-email-fatigue.md)

Correlate email volume, opens, clicks, unsubscribes, activation, and churn to find where lifecycle messaging helps or hurts.

- Starter request: Analyze lifecycle email fatigue: sends, opens, clicks, unsubscribes, activation, and churn by sequence and user cohort.
- Execution: on_demand
- Tags: analytics, email, lifecycle, churn, marketing, retention
- Applies to: b2c-saas, b2b-saas, ecommerce, content-media
- Required events: email_sent, email_clicked, email_unsubscribed
- 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 email_sent, email_clicked, email_unsubscribed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide email_sent.sequence, email_sent.message_id, email_clicked.sequence, email_unsubscribed.sequence, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/lifecycle-email-fatigue

### [Draft a weekly changelog from verified product signals](https://agentry.sh/workflows/weekly-changelog.md)

Turn exact, source-backed weekly aggregates into a human-reviewed changelog draft without exposing user identities, inventing causality, or auto-publishing.

- Starter request: Draft a weekly changelog from the approved events in this project's saved signal map. Query exact current and prior periods, label hypotheses as hypotheses, include readiness gaps, exclude user identities, and stop before publishing.
- Execution: human_review
- Tags: analytics, content-marketing, weekly-review, founder-mode, saas
- Applies to: b2c-saas, b2b-saas, content-media, open-source
- Required events: signup_completed, feature_used
- Required Agentry resources: signal_map, onboarding_state, query_blueprints
- Do not use when: Projects whose saved signal map uses different lifecycle events and has not mapped equivalent signals, Projects without two complete comparable periods of real traffic
- Ask before using: Which observed event represents entry, activation, and the primary outcome in this product?, What exact timezone and period boundary should the review use?
- Human page: https://agentry.sh/workflows/weekly-changelog

### [Email click to first in-app action conversion](https://agentry.sh/workflows/onboarding-email-funnel.md)

Join UTM-tagged email opens to the in-app action they were meant to drive. Grade onboarding emails by behavior change, not click rate.

- Starter request: Build a funnel from onboarding email opens (UTM-tagged) to the in-app action they were supposed to trigger. Per-template breakdown.
- Execution: on_demand
- Tags: analytics, funnels, email, onboarding, content-marketing, mixpanel-alternative
- Applies to: b2c-saas, b2b-saas, devtools-api, content-media
- Required events: email_sent, email_clicked, onboarding_step_completed
- 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., Do not present illustrative custom analysis as a built-in query blueprint or runnable Agentry product surface.
- Ask before using: Which observed events map to email_sent, email_clicked, onboarding_step_completed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide email_sent.email_template, email_sent.utm_campaign, email_clicked.email_template, email_clicked.utm_campaign, onboarding_step_completed.step, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/onboarding-email-funnel

### [Find accounts paying for 10 seats but using 3](https://agentry.sh/workflows/seat-utilization.md)

Compute seat utilization per B2B account and flag low-use payers. Catch downgrade risk and surface expansion-conversation accounts.

- Starter request: For each B2B account, compute paid_seats vs active_users in the last 30 days. Surface accounts where utilization < 50%.
- Execution: on_demand
- Tags: analytics, expansion, seat-utilization, b2b, account-health, saas
- Applies to: b2b-saas
- Required events: seat_count_set, feature_used
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal., Do not recommend this when the product has no stable account or workspace identity.
- Ask before using: Which observed events map to seat_count_set, feature_used? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide seat_count_set.account_id, seat_count_set.seat_count, seat_count_set.mrr, feature_used.account_id, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/seat-utilization

### [Find docs searches with zero results](https://agentry.sh/workflows/docs-search-zero-results.md)

Capture failed docs searches and connect them to activation, support load, and API adoption so docs work targets real blockers.

- Starter request: Show docs searches with zero results, the users/accounts who searched them, and whether those searches were followed by failed activation or support tickets.
- Execution: on_demand
- Tags: analytics, documentation, devtools-api, content-marketing, activation, support
- Applies to: devtools-api, b2b-saas, open-source, content-media
- Required events: docs_search
- 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 docs_search? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide docs_search.query, docs_search.result_count, docs_search.path, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/docs-search-zero-results

### [Find feature entitlement friction](https://agentry.sh/workflows/feature-entitlement-friction.md)

See which locked features users try to access, which plans hit upgrade prompts, and where entitlement gates create conversion opportunities.

- Starter request: Show feature entitlement friction for the last 30 days: locked feature views, upgrade prompt impressions, conversion after prompt, and accounts with repeated interest.
- Execution: on_demand
- Tags: analytics, feature-flags, pricing, expansion, product, saas
- Applies to: b2c-saas, b2b-saas, devtools-api, enterprise-sales
- Required events: feature_locked_viewed, upgrade_prompt_clicked
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal.
- Ask before using: Which observed events map to feature_locked_viewed, upgrade_prompt_clicked? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide feature_locked_viewed.feature, feature_locked_viewed.plan, feature_locked_viewed.account_id, upgrade_prompt_clicked.feature, upgrade_prompt_clicked.plan, upgrade_prompt_clicked.account_id, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/feature-entitlement-friction

### [Find marketplace zero-result searches](https://agentry.sh/workflows/marketplace-search-zero-results.md)

Identify marketplace searches with no matching supply so product and ops teams can fix demand-supply gaps faster.

- Starter request: Find marketplace searches with zero results by query, category, geography, buyer segment, and downstream conversion.
- Execution: on_demand
- Tags: analytics, marketplace, search, activation, product, operations
- Applies to: marketplace
- Required events: marketplace_search_performed, listing_viewed, booking_started
- 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., Do not recommend this when the product has no distinct supply and demand sides with stable identities.
- Ask before using: Which observed events map to marketplace_search_performed, listing_viewed, booking_started? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide marketplace_search_performed.query, marketplace_search_performed.category, marketplace_search_performed.result_count, marketplace_search_performed.geography, listing_viewed.listing_id, booking_started.listing_id, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/marketplace-search-zero-results

### [Find onboarding checklist drop-off](https://agentry.sh/workflows/onboarding-checklist-dropoff.md)

Analyze checklist and setup-step completion so product and CS can see exactly where new users or accounts stall.

- Starter request: Analyze onboarding checklist drop-off for new accounts: step started, step completed, time between steps, and accounts stuck for more than 7 days.
- Execution: on_demand
- Tags: analytics, onboarding, activation, funnels, b2b, customer-success
- Applies to: b2c-saas, b2b-saas, devtools-api, enterprise-sales
- Required events: onboarding_step_started, onboarding_step_completed
- 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 onboarding_step_started, onboarding_step_completed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide onboarding_step_started.account_id, onboarding_step_started.step, onboarding_step_completed.account_id, onboarding_step_completed.step, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/onboarding-checklist-dropoff

### [Find permission-denied friction in B2B apps](https://agentry.sh/workflows/permission-denied-friction.md)

Surface users and accounts repeatedly hitting 403s, role gates, or missing-seat paths so product can fix admin and permission UX.

- Starter request: Show permission-denied friction for the last 14 days: users hitting role gates, accounts with repeated 403s, and the features they were trying to access.
- Execution: on_demand
- Tags: analytics, b2b, permissions, product, activation, customer-success
- Applies to: b2b-saas, enterprise-sales, internal-tool
- Required events: permission_denied
- 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., Do not recommend this when the product has no stable account or workspace identity.
- Ask before using: Which observed events map to permission_denied? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide permission_denied.account_id, permission_denied.feature, permission_denied.role, permission_denied.required_role, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/permission-denied-friction

### [Find plan fit and overage opportunities](https://agentry.sh/workflows/plan-fit-and-overage.md)

Identify accounts close to limits, repeatedly over quota, or paying for capacity they do not use so revenue teams know who to help.

- Starter request: Find accounts with plan-fit issues: near quota, over quota, or underusing paid capacity. Rank by revenue impact and suggested CS action.
- Execution: on_demand
- Tags: analytics, revenue, expansion, quotas, b2b, customer-success
- Applies to: b2b-saas, devtools-api, enterprise-sales
- Required events: quota_snapshot
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal., Do not recommend this when the product has no stable account or workspace identity.
- Ask before using: Which observed events map to quota_snapshot? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide quota_snapshot.account_id, quota_snapshot.metric, quota_snapshot.used, quota_snapshot.limit, quota_snapshot.plan, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/plan-fit-and-overage

### [Find quiet paying accounts before they churn](https://agentry.sh/workflows/dormant-account-revival.md)

List paying accounts with zero events in 14 days. Sort by ARR. Get personalized outreach drafted in one prompt.

- Starter request: List paying accounts with zero events in the last 14 days that haven't canceled. Sort by ARR. Draft me an outreach email per top-5.
- Execution: on_demand
- Tags: analytics, churn, early-warning, retention, b2b, customer-success
- Applies to: b2b-saas, devtools-api
- Required events: subscription_canceled
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal., Do not recommend this when the product has no stable account or workspace identity.
- Ask before using: Which observed events map to subscription_canceled? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?
- Human page: https://agentry.sh/workflows/dormant-account-revival

### [Find which products silently kill conversion](https://agentry.sh/workflows/add-to-cart-funnel.md)

Per-SKU funnel from product view to purchase. Surface products that convert below their category average — fix the laggards instead of generic PDP tweaks.

- Starter request: Build the per-SKU funnel: product_view → add_to_cart → checkout_started → purchase. Surface SKUs with worst conversion vs the category average.
- Execution: on_demand
- Tags: analytics, funnels, product, ecommerce, conversion, mixpanel-alternative
- Applies to: ecommerce
- Required events: product_viewed, add_to_cart, order_placed
- 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., Do not present illustrative custom analysis as a built-in query blueprint or runnable Agentry product surface.
- Ask before using: Which observed events map to product_viewed, add_to_cart, order_placed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide product_viewed.sku, product_viewed.category, add_to_cart.sku, order_placed.order_id, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/add-to-cart-funnel

### [How fast was the new feature picked up?](https://agentry.sh/workflows/feature-launch-adoption.md)

Track time-to-first-use for a newly launched feature, split by trial vs paying user. The 2-week post-launch reality check.

- Starter request: We launched feature X two weeks ago. Track time-to-first-use per user cohort. Compare adoption among trial users vs paying customers.
- Execution: on_demand
- Tags: analytics, feature-adoption, launches, growth-loop, product, saas
- Applies to: b2c-saas, b2b-saas, devtools-api, content-media
- Required events: report_export_v2_used, plan_changed
- 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 report_export_v2_used, plan_changed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide report_export_v2_used.feature, plan_changed.plan, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/feature-launch-adoption

### [Identify behavioral churn-risk signals](https://agentry.sh/workflows/churn-prediction.md)

Compare pre-renewal behavior for retained and canceled customers, quantify associations, and prepare a reviewed risk hypothesis without claiming prediction.

- Starter request: Compare behavior before cancellation and renewal in exact historical cohorts. Quantify which verified product-value signals differ, disclose sample and confounding limits, and prepare a churn-risk hypothesis for human review without contacting customers.
- Execution: human_review
- Tags: analytics, retention, churn, revenue, customer-success, human-review
- Applies to: b2c-saas, b2b-saas, devtools-api
- Required events: subscription_canceled, subscription_renewed, product_value_completed
- Required Agentry resources: signal_map, onboarding_state, analytics
- Do not use when: Do not describe retrospective behavioral associations as a predictive model or a promise that churn will occur., Do not use this for products without a verified paid lifecycle and enough complete retained and canceled cohorts., Do not automatically create outreach lists, send messages, change pricing, or target users from exploratory signals.
- Ask before using: Which trusted events define cancellation and renewal, and what stable user or account identity joins them to prior behavior?, What exact pre-outcome window, historical cohort window, plan segments, and minimum sample should be compared?, Which product-value events were defined before looking at the outcome, and who reviews any resulting risk hypothesis?
- Human page: https://agentry.sh/workflows/churn-prediction

### [Identify early behaviors associated with retention](https://agentry.sh/workflows/activation-moment.md)

Compare predefined first-window product behaviors with later retained activity, quantify associations, and design a validation step without declaring a magic cause.

- Starter request: Compare predefined behaviors in the first 24 hours with a source-backed retained-activity event in a later window. Show cohort sizes and retention rates, control obvious segments, and label every result as association until validated.
- Execution: human_review
- Tags: analytics, activation, retention, onboarding, product
- Applies to: b2c-saas, b2b-saas, devtools-api, content-media, marketplace
- Required events: signup_completed, product_value_completed, retained_activity
- Required Agentry resources: signal_map, onboarding_state, analytics
- Do not use when: Do not call a behavior a magic moment or causal driver from retrospective correlation alone., Do not use incomplete cohorts, any-event retention, or events chosen only after inspecting the outcome., Do not automatically change onboarding, create targeting cohorts, or contact users from exploratory results.
- Ask before using: Which observed event defines signup, which predefined early behaviors are candidates, and which event represents meaningful retained activity?, What exact early window, later retention window, cohort dates, minimum sample, and major segments should be used?, How will the strongest association be validated on a later cohort or prospective experiment?
- Human page: https://agentry.sh/workflows/activation-moment

### [Identify your most engaged users and accounts](https://agentry.sh/workflows/power-users.md)

Rank pseudonymous users or accounts with a reviewed product-value definition, keep identities private, and use the result as research evidence rather than an outreach command.

- Starter request: Identify the most engaged users or accounts for a defined period using verified product-value events and a reviewed weighting rule. Return pseudonymous IDs by default, explain the formula and bias, and stop before outreach.
- Execution: human_review
- Tags: analytics, retention, customer-success, product-research, privacy, human-review
- Applies to: b2c-saas, b2b-saas, devtools-api, content-media, marketplace
- Required events: product_value_completed
- Required Agentry resources: signal_map, onboarding_state, analytics
- Do not use when: Do not rank people from total event volume or arbitrary revenue weights that were chosen after seeing the result., Do not return emails or personal data when pseudonymous user or account IDs answer the question., Do not automatically email, upsell, survey, or target anyone from the ranking.
- Ask before using: Which observed events represent delivered product value, and should the unit be user, account, workspace, or organization?, What exact period, minimum activity threshold, exclusions, and weighting rule should be reviewed before querying?, Who is authorized to resolve pseudonymous IDs if a later research or customer-success action is approved?
- Human page: https://agentry.sh/workflows/power-users

### [Is checkout too slow?](https://agentry.sh/workflows/checkout-completion-time.md)

Compute p50/p90/p99 of checkout duration split by mobile and desktop. Mobile p99 is usually 4-8x worse than desktop p50.

- Starter request: Compute p50, p90, p99 of the time from checkout_started to purchase. Split by device (mobile vs desktop).
- Execution: on_demand
- Tags: analytics, checkout, ecommerce, performance, posthog-alternative
- Applies to: ecommerce
- Required events: checkout_started, order_placed
- 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., Do not present illustrative custom analysis as a built-in query blueprint or runnable Agentry product surface.
- Ask before using: Which observed events map to checkout_started, order_placed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?
- Human page: https://agentry.sh/workflows/checkout-completion-time

### [Measure a verified three-step signup funnel](https://agentry.sh/workflows/signup-funnel.md)

Map three ordered lifecycle events to live project signals, run the canonical funnel blueprint, and explain drop-offs without inventing causes or benchmarks.

- Starter request: Measure our signup-to-activation funnel for the last 30 days. Map three distinct ordered events from the saved signal map and observed event names, verify they have real traffic, run funnel_3_step, calculate drop-offs from its returned counts, and state which causes are still hypotheses.
- Execution: on_demand
- Tags: analytics, funnels, onboarding, activation, product, saas
- Applies to: b2c-saas, b2b-saas, devtools-api, single-purchase, enterprise-sales
- Required events: signup_started, signup_completed, activation_completed
- Required Agentry resources: signal_map, onboarding_state, query_blueprints
- Do not use when: Do not use the example event names when the project's saved signal map defines different lifecycle events., Do not interpret missing or synthetic-only events as real user drop-off., Do not claim industry benchmarks, time-to-next-step, causes, or four-step results from the three-count blueprint.
- Ask before using: Which three observed events define entry, completed signup, and meaningful activation in their required order?, Which stable identity links the events, and can anonymous-to-known identity transitions be joined without double counting?, What exact lookback window and audience should the funnel cover?
- Human page: https://agentry.sh/workflows/signup-funnel

### [Measure cart-to-purchase drop-off](https://agentry.sh/workflows/cart-abandonment-funnel.md)

Map three verified ecommerce events, run the canonical ordered funnel, and separate measured checkout loss from hypotheses about payment, shipping, or UX.

- Starter request: Measure add-to-cart → checkout-started → order-completed for the last 30 days. Verify the exact events and stable shopper identity, run funnel_3_step, calculate drop-offs from the returned counts, and label possible causes as hypotheses.
- Execution: on_demand
- Tags: analytics, funnels, ecommerce, checkout, cart-abandonment
- Applies to: ecommerce
- Required events: add_to_cart, checkout_started, order_completed
- Required Agentry resources: signal_map, onboarding_state, query_blueprints
- Do not use when: Do not use guessed ecommerce event names or interpret missing events as shopper abandonment., Do not claim time-on-step, revenue loss, causes, or industry benchmarks from the three-count funnel blueprint., Do not mix anonymous and known shopper identities without a verified identity-linking strategy.
- Ask before using: Which observed events represent add-to-cart, checkout start, and completed order in that exact order?, Which stable shopper identity joins guest and signed-in steps without double counting?, What exact lookback, storefront, device population, and exclusions should be applied?
- Human page: https://agentry.sh/workflows/cart-abandonment-funnel

### [Measure landing-page source quality](https://agentry.sh/workflows/landing-page-source-quality.md)

Compare acquisition sources by activation, retention, and paid conversion instead of only measuring clicks or signups.

- Starter request: Compare acquisition sources by signup volume, activation rate, day-7 retention, and paid conversion. Show which sources are high-quality, not just high-volume.
- Execution: on_demand
- Tags: analytics, acquisition, marketing, activation, retention, saas
- Applies to: b2c-saas, b2b-saas, devtools-api, content-media, games
- Required events: signup_completed, activated
- 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 signup_completed, activated? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide signup_completed.utm_source, activated.utm_source, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/landing-page-source-quality

### [Measure referral quality, not just invites](https://agentry.sh/workflows/referral-quality-loop.md)

Track invite sent, invite accepted, activation, and retention so product teams know whether referrals create valuable users.

- Starter request: Analyze referral quality: invites sent, accepted, activated, and retained users by inviter cohort and channel.
- Execution: on_demand
- Tags: analytics, referrals, activation, retention, growth-loop, product
- Applies to: b2c-saas, b2b-saas, marketplace, games
- Required events: referral_invite_sent, referral_invite_accepted, activated
- 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 referral_invite_sent, referral_invite_accepted, activated? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide referral_invite_sent.inviter_id, referral_invite_sent.channel, referral_invite_accepted.inviter_id, referral_invite_accepted.invitee_id, activated.source, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/referral-quality-loop

### [Measure returns and exchange outcomes](https://agentry.sh/workflows/returns-exchange-funnel.md)

Follow returns from request to refund or exchange so ecommerce teams can reduce avoidable churn and protect revenue.

- Starter request: Measure the returns and exchange funnel by reason, SKU, customer segment, refund amount, and whether the customer bought again.
- Execution: on_demand
- Tags: analytics, ecommerce, retention, revenue, support, customer-success
- Applies to: ecommerce, marketplace
- Required events: return_requested, return_label_created, exchange_completed, refund_completed
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal.
- Ask before using: Which observed events map to return_requested, return_label_created, exchange_completed, refund_completed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide return_requested.order_id, return_requested.sku, return_requested.return_reason, exchange_completed.order_id, exchange_completed.sku, refund_completed.order_id, refund_completed.refund_amount, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/returns-exchange-funnel

### [Measure seller activation from profile to first sale](https://agentry.sh/workflows/supply-side-activation.md)

Run a verified three-step supply-side funnel and separate measured seller progression from unproven assumptions about listing friction or marketplace demand.

- Starter request: Measure seller-profile-completed → listing-published → first-sale for the last 60 days. Verify three distinct ordered events and seller identity, run funnel_3_step, calculate drop-offs, and keep listing-friction and demand explanations as hypotheses.
- Execution: on_demand
- Tags: analytics, funnels, marketplace, supply-side, activation
- Applies to: marketplace
- Required events: seller_profile_completed, listing_published, seller_first_sale
- Required Agentry resources: signal_map, onboarding_state, query_blueprints
- Do not use when: Do not recommend this when the product has no distinct supply and demand sides with stable identities., Do not substitute listing drafts for published supply or payment attempts for a confirmed first sale., Do not infer listing friction, seller intent, or demand quality from funnel counts alone.
- Ask before using: Which observed events represent completed seller profile, published listing, and trusted first sale in order?, Which stable seller ID joins all three events, and what 60-day cohort or lookback definition is intended?, Which separate evidence would distinguish seller-side friction from insufficient buyer demand?
- Human page: https://agentry.sh/workflows/supply-side-activation

### [Prepare a cancellation survey for human review](https://agentry.sh/workflows/churn-survey.md)

Verify the cancellation signal, review a minimal survey and targeting rule, and summarize bounded responses without inventing benchmarks or contacting customers.

- Starter request: Prepare a short cancellation survey for review. Verify the real cancellation event and targeting boundary, minimize personal data, show the exact survey definition before creation, and summarize only a bounded response window after a human approves it.
- Execution: human_review
- Tags: analytics, surveys, churn, customer-research, privacy, human-review
- Applies to: b2c-saas, b2b-saas, devtools-api
- Required events: subscription_canceled
- Required Agentry resources: signal_map, onboarding_state, surveys, analytics
- Do not use when: Do not create or activate a survey when the cancellation event, targeting semantics, consent, or rendering path is unverified., Do not claim generic response-rate benchmarks or invent a public survey URL., Do not automatically email respondents, identify quote authors, or turn free-text responses into outreach targets.
- Ask before using: Which observed event represents a completed cancellation, and when should the survey be eligible to render?, Who approves the questions, targeting, consent language, response window, and minimum theme count?, Which fields are necessary for analysis, and which personal or sensitive data must be excluded?
- Human page: https://agentry.sh/workflows/churn-survey

### [Push notification: sent → opened → action conversion](https://agentry.sh/workflows/push-notification-funnel.md)

Joined funnel from push provider's send webhook through open through in-app action. Per-campaign breakdown — what marketing platforms refuse to show you.

- Starter request: Build a funnel from push_sent (from our push provider webhook) → push_opened → next_action. Per-campaign breakdown.
- Execution: on_demand
- Tags: analytics, funnels, push-notifications, mobile-app, retention, mixpanel-alternative
- Applies to: mobile-app
- Required events: push_sent, push_opened
- 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., Do not present illustrative custom analysis as a built-in query blueprint or runnable Agentry product surface.
- Ask before using: Which observed events map to push_sent, push_opened? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide push_sent.campaign_id, push_opened.campaign_id, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/push-notification-funnel

### [Revenue-weight feature requests](https://agentry.sh/workflows/feature-request-revenue-weighting.md)

Rank feature requests by account value, usage pain, and renewal risk so product and GTM teams can prioritize with context.

- Starter request: Rank feature requests by requesting accounts, ARR or plan value, renewal risk, usage pain, and whether the feature blocks expansion.
- Execution: on_demand
- Tags: analytics, revenue, product, roadmap, customer-success, expansion
- Applies to: b2b-saas, enterprise-sales, devtools-api
- Required events: feature_requested, account_health_changed, expansion_opportunity_created
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal., Do not recommend this when the product has no stable account or workspace identity.
- Ask before using: Which observed events map to feature_requested, account_health_changed, expansion_opportunity_created? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide feature_requested.account_id, feature_requested.request_key, feature_requested.source, account_health_changed.account_id, account_health_changed.health_score, expansion_opportunity_created.account_id, expansion_opportunity_created.opportunity_value, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/feature-request-revenue-weighting

### [Track buyer-seller dispute frequency per seller](https://agentry.sh/workflows/dispute-rate-monitoring.md)

Per-seller disputes ÷ transactions over 90 days. Surface the top-decile dispute-drivers proactively — proactive review costs less than reactive churn.

- Starter request: Per seller, compute dispute_opened events / total_transactions over the last 90 days. Surface sellers in the top decile — review them before customers notice.
- Execution: on_demand
- Tags: analytics, marketplace, trust, b2c, customer-support
- Applies to: marketplace, ecommerce
- Required events: order_placed, dispute_opened
- 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., Do not present illustrative custom analysis as a built-in query blueprint or runnable Agentry product surface.
- Ask before using: Which observed events map to order_placed, dispute_opened? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide dispute_opened.seller_id, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/dispute-rate-monitoring

### [Track dunning recovery from failed invoices](https://agentry.sh/workflows/dunning-recovery-funnel.md)

Measure failed-payment recovery from invoice failure through retry, card update, recovery, or cancellation for subscription revenue.

- Starter request: Build a dunning recovery funnel: invoice failed → retry scheduled → payment method updated → payment recovered or subscription canceled.
- Execution: on_demand
- Tags: analytics, revenue, stripe, dunning, churn, saas
- Applies to: b2c-saas, b2b-saas, devtools-api
- Required events: invoice_payment_failed, payment_method_updated, invoice_payment_recovered
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal.
- Ask before using: Which observed events map to invoice_payment_failed, payment_method_updated, invoice_payment_recovered? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide invoice_payment_failed.account_id, invoice_payment_failed.invoice_id, invoice_payment_failed.amount, payment_method_updated.account_id, invoice_payment_recovered.account_id, invoice_payment_recovered.invoice_id, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/dunning-recovery-funnel

### [Track engagement during enterprise POCs](https://agentry.sh/workflows/demo-poc-tracking.md)

Daily engagement per account for active POCs. Flag any account that has gone quiet for 3+ days so AEs can act.

- Starter request: I'm running 4 enterprise POCs. For each account, show daily event volume during the trial period. Flag any that have gone quiet for 3+ days.
- Execution: on_demand
- Tags: analytics, sales, enterprise, b2b, account-health, customer-success
- Applies to: b2b-saas, enterprise-sales
- Required events: feature_used, implementation_milestone, demo_completed
- 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., Do not recommend this when the product has no stable account or workspace identity., Do not present illustrative custom analysis as a built-in query blueprint or runnable Agentry product surface.
- Ask before using: Which observed events map to feature_used, implementation_milestone, demo_completed? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide feature_used.account_id, feature_used.is_poc, implementation_milestone.account_id, implementation_milestone.milestone, demo_completed.account_id, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/demo-poc-tracking

### [Track SDK adoption after release](https://agentry.sh/workflows/sdk-adoption-after-release.md)

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

- Starter request: After the latest SDK release, show adoption by version, language, account, and API usage. Identify accounts still on old versions.
- Execution: on_demand
- Tags: analytics, deploys, sdk, releases, devtools, product
- Applies to: devtools-api, open-source, b2b-saas
- Required 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?
- Human page: https://agentry.sh/workflows/sdk-adoption-after-release

### [Track trial-to-paid conversion by acquisition source](https://agentry.sh/workflows/trial-to-paid-conversion.md)

Build the trial-to-paid funnel split by acquisition source. Surface the channel that converts 8x better than the rest.

- Starter request: Build the trial-to-paid funnel split by acquisition source. Which channel converts trials best?
- Execution: on_demand
- Tags: analytics, funnels, trial-conversion, saas, acquisition, mixpanel-alternative
- Applies to: b2c-saas, b2b-saas, devtools-api
- Required events: signup_completed, trial_started, subscription_started
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal., Do not present illustrative custom analysis as a built-in query blueprint or runnable Agentry product surface.
- Ask before using: Which observed events map to signup_completed, trial_started, subscription_started? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide signup_completed.utm_source, subscription_started.plan, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/trial-to-paid-conversion

### [Track waitlist to activation](https://agentry.sh/workflows/waitlist-to-activation.md)

See which waitlist cohorts convert after invite, where they stall, and whether invite timing changes activation quality.

- Starter request: Analyze waitlist conversion: joined waitlist, invited, accepted invite, signed up, activated, and retained by cohort and acquisition source.
- Execution: on_demand
- Tags: analytics, waitlist, activation, onboarding, acquisition, product
- Applies to: b2c-saas, b2b-saas, content-media, games, mobile-app
- Required events: waitlist_joined, invite_accepted, activated
- 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 waitlist_joined, invite_accepted, activated? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide waitlist_joined.source, waitlist_joined.cohort, invite_accepted.invite_id, activated.source, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/waitlist-to-activation

### [What behaviors predict an account will upgrade?](https://agentry.sh/workflows/expansion-prediction.md)

Compare upgraders vs flat users from last quarter. Find the pre-upgrade behaviors that most strongly predict expansion.

- Starter request: Compare users who upgraded last quarter vs users who stayed flat. What pre-upgrade behaviors are highest signal?
- Execution: on_demand
- Tags: analytics, expansion, cohorts, growth-loop, b2b, saas
- Applies to: b2b-saas, b2c-saas, devtools-api
- Required events: subscription_upgraded
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal.
- Ask before using: Which observed events map to subscription_upgraded? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?
- Human page: https://agentry.sh/workflows/expansion-prediction

### [Which doc page leads to the most API adoption?](https://agentry.sh/workflows/docs-to-api-funnel.md)

Funnel from a docs page view to first api_request by the same distinct_id within 7 days. Per-doc-page breakdown — find the highest-leverage page in your docs.

- Starter request: Build a funnel from docs page views (page_view on /docs/*) to first api_request by the same distinct_id within 7 days. Per-doc-page breakdown. Which docs convert?
- Execution: on_demand
- Tags: analytics, funnels, devtools-api, content-marketing, documentation, posthog-alternative
- Applies to: devtools-api
- Required events: page_view, api_request
- 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., Do not present illustrative custom analysis as a built-in query blueprint or runnable Agentry product surface.
- Ask before using: Which observed events map to page_view, api_request? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide page_view.path, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/docs-to-api-funnel

### [Why did this account drop from pro to free?](https://agentry.sh/workflows/tier-downgrade.md)

Find accounts that downgraded in the last 30 days and compare their behavior before vs after. The soft-churn signal nobody tracks.

- Starter request: List paid accounts that downgraded in the last 30 days. For each, compare their behavior in the 30 days before vs after the downgrade.
- Execution: on_demand
- Tags: analytics, churn, downgrade, b2b, retention, cohorts
- Applies to: b2b-saas, b2c-saas, devtools-api
- Required events: subscription_downgraded
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal.
- Ask before using: Which observed events map to subscription_downgraded? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?
- Human page: https://agentry.sh/workflows/tier-downgrade

## Ops

### [Audit sourcemap coverage for minified errors](https://agentry.sh/workflows/sourcemap-coverage-audit.md)

Find which production errors cannot be unmangled because sourcemaps are missing, stale, or uploaded under the wrong release.

- Starter request: Audit sourcemap coverage for current open client-side errors. Which cases still have minified stacks, and which release/source_url pairs need maps uploaded?
- Execution: on_demand
- Tags: errors, sourcemaps, releases, frontend, ops, sentry-alternative
- Applies to: b2c-saas, b2b-saas, ecommerce, marketplace, content-media, devtools-api
- Required events: $exception
- 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 $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.release, $exception.source_url, $exception.minified, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/sourcemap-coverage-audit

### [Auto-document your captured event taxonomy](https://agentry.sh/workflows/event-taxonomy-document.md)

Every event captured in the last 30 days with count, first-seen, last-seen, sample property keys. Markdown table for Notion — your event taxonomy doc that never goes stale.

- Starter request: List every event we've captured in the last 30 days with its count, first-seen, last-seen, and sample property keys. Format as a Markdown table for review or publication.
- Execution: on_demand
- Tags: analytics, documentation, event-taxonomy, ops, onboarding
- Applies to: universal
- Required events: page_view, signup_completed, feature_used
- 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 page_view, signup_completed, feature_used? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide page_view.path, signup_completed.source, feature_used.feature, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/event-taxonomy-document

### [Generate a renewal-risk brief for each account](https://agentry.sh/workflows/renewal-risk-brief.md)

Combine usage decline, errors, seat utilization, and support friction into a renewal-risk brief CS can act on before the renewal date.

- Starter request: Generate renewal-risk briefs for accounts renewing in the next 60 days. Include usage trend, errors, seat utilization, support friction, and recommended CS action.
- Execution: on_demand
- Tags: analytics, revenue, customer-success, renewals, account-health, b2b
- Applies to: b2b-saas, devtools-api, enterprise-sales
- Required events: renewal_upcoming
- 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., Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal., Do not recommend this when the product has no stable account or workspace identity.
- Ask before using: Which observed events map to renewal_upcoming? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide renewal_upcoming.account_id, renewal_upcoming.renewal_date, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/renewal-risk-brief

### [Match supply to demand per region or category](https://agentry.sh/workflows/liquidity-dashboard.md)

Per-region ratio of buyer-side events to seller-side events. Spot starved regions before they churn. Liquidity is the metric that decides supply vs demand growth investment.

- Starter request: Per region (or category), compute the ratio of buyer-side events to seller-side events. Flag regions where supply or demand is starved, return the evidence table, and only create a CS-visible dashboard if I ask for a persistent view.
- Execution: on_demand
- Tags: analytics, dashboards, marketplace, liquidity, ops, b2c
- Applies to: marketplace
- Required events: search, listing_viewed, add_to_cart, order_placed, listing_published, order_fulfilled
- 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., Do not recommend this when the product has no distinct supply and demand sides with stable identities., Do not present illustrative custom analysis as a built-in query blueprint or runnable Agentry product surface.
- Ask before using: Which observed events map to search, listing_viewed, add_to_cart, order_placed, listing_published, order_fulfilled? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide search.region, listing_viewed.region, add_to_cart.region, order_placed.region, listing_published.region, order_fulfilled.region, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/liquidity-dashboard

### [Monitor webhook delivery reliability](https://agentry.sh/workflows/webhook-delivery-reliability.md)

Track failed, retried, and slow webhook deliveries by provider, event type, and customer before integrations silently break.

- Starter request: Show webhook delivery health for the last 7 days: failures, retries, p95 delivery time, and customers with repeated delivery problems.
- Execution: on_demand
- Tags: analytics, webhooks, integrations, reliability, automation, b2b
- Applies to: b2b-saas, devtools-api, marketplace
- Required events: webhook_delivery
- 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 webhook_delivery? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide webhook_delivery.provider, webhook_delivery.event_type, webhook_delivery.status, webhook_delivery.attempt, webhook_delivery.duration_ms, webhook_delivery.customer_id, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/webhook-delivery-reliability

### [Per-customer API call analytics](https://agentry.sh/workflows/api-usage-by-customer.md)

Group api_request events by customer_id over 30 days with daily breakdown. The view usage-based pricing needs but most teams cobble together from logs.

- Starter request: Group api_request events by customer_id in the last 30 days. Show me top 20 customers by call volume, with daily breakdown for each.
- Execution: on_demand
- Tags: analytics, devtools-api, api-quota, dashboards, b2b
- Applies to: devtools-api
- Required events: api_request
- 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., Do not present illustrative custom analysis as a built-in query blueprint or runnable Agentry product surface.
- Ask before using: Which observed events map to api_request? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide api_request.customer_id, api_request.endpoint, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/api-usage-by-customer

### [Publish verified aggregate metrics safely](https://agentry.sh/workflows/public-stats-page.md)

Approve a bounded aggregate query, publish only its reviewed blueprint, and embed the returned public URL without exposing owner credentials or identities.

- Starter request: Prepare one public aggregate metric from a verified signal. Confirm the exact definition, privacy threshold, and safe query blueprint, show the rows before publication, and wait for human approval before creating or embedding the public query.
- Execution: human_review
- Tags: analytics, public-queries, content-marketing, privacy, dashboards, human-review
- Applies to: universal
- Required events: product_value_completed
- Required Agentry resources: signal_map, onboarding_state, query_blueprints, public_queries
- Do not use when: Do not publish raw users, accounts, sessions, cases, messages, rare segments, or other re-identifiable rows., Do not publish custom HogQL directly or put a private owner credential in a page, worker, build, or scheduler., Do not create a public query until the metric definition, blueprint safety, sample threshold, and audience are reviewed.
- Ask before using: Which observed event and exact aggregate define the metric, including timezone, period, and denominator?, Which reviewed query blueprint produces it, and what privacy or minimum-sample threshold applies?, Who approves publication, where will the returned URL appear, and when should it be revoked?
- Human page: https://agentry.sh/workflows/public-stats-page

### [Rank support load by account](https://agentry.sh/workflows/support-load-by-account.md)

Combine errors, complaints, affected users, and plan data to show which accounts are consuming the most support attention.

- Starter request: Rank accounts by support load for the last 30 days using errors, affected users, complaint events, and plan or revenue tier.
- Execution: on_demand
- Tags: analytics, errors, customer-support, account-health, b2b, revenue
- Applies to: b2b-saas, devtools-api, enterprise-sales
- Required events: support_ticket_opened
- 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., Do not recommend this when the product has no stable account or workspace identity.
- Ask before using: Which observed events map to support_ticket_opened? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide support_ticket_opened.account_id, support_ticket_opened.topic, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/support-load-by-account

### [Review a sudden spike in negative reviews](https://agentry.sh/workflows/review-bomb-detection.md)

Compare a bounded low-rating window with a verified baseline, identify concentrated sellers or listings, and return evidence for a human incident decision.

- Starter request: Review low-rating review_submitted events from the last 15 minutes against the prior seven-day baseline. Show the sample size, multiplier, affected sellers or listings, and recent deploy context. Do not message anyone or change listing state.
- Execution: human_review
- Tags: analytics, marketplace, trust, incident-review, human-review
- Applies to: marketplace, ecommerce, content-media
- Required events: review_submitted
- Required Agentry resources: analytics, deploys
- 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., Do not automatically send, publish, suppress, mutate, or contact anyone from this workflow.
- Ask before using: Which observed events map to review_submitted? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide review_submitted.rating, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/review-bomb-detection

### [Review account-health evidence before outreach](https://agentry.sh/workflows/account-health-score.md)

Combine verified account usage, revenue context, and support-friction signals into a review queue without pretending a universal score proves churn or intent.

- Starter request: Prepare an account-health review for the current and prior 30-day periods. Use only verified account-level usage, revenue, and support-friction signals, show each component separately, flag missing data, and stop before contacting anyone.
- Execution: human_review
- Tags: analytics, customer-success, account-health, b2b, revenue, human-review
- Applies to: b2b-saas, devtools-api, enterprise-sales
- Required events: account_snapshot, product_value_completed, support_ticket_opened
- Required Agentry resources: signal_map, onboarding_state, analytics
- Do not use when: Do not recommend this when the product has no stable account identity or no verified paid-account lifecycle., Do not present a composite score as a churn prediction, customer intent, or objective truth., Do not publish account-level rows or automatically contact, downgrade, upsell, or escalate customers from this review.
- Ask before using: Which observed event represents delivered product value, and which account snapshot is the source of plan and revenue context?, Which exact current and prior periods, account population, and minimum activity threshold should be compared?, How should support friction be measured, and who reviews the resulting account queue?
- Human page: https://agentry.sh/workflows/account-health-score

### [Review customers nearing their API caps](https://agentry.sh/workflows/rate-limit-alert-routing.md)

Rank customers by monthly API quota consumption, show threshold and projection evidence, and prepare human-reviewed account outreach without sending it.

- Starter request: Review customers at or above 80% of their monthly API quota. Show calls used, cap source, projected month-end usage, threshold band, and recent usage change. Draft account notes but do not contact customers or change limits.
- Execution: human_review
- Tags: analytics, devtools-api, api-quota, customer-success, human-review
- Applies to: devtools-api
- Required events: api_request
- Required Agentry resources: analytics
- 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., Do not automatically send, publish, suppress, mutate, or contact anyone from this workflow.
- Ask before using: Which observed events map to api_request? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide api_request.customer_id, api_request.plan, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/rate-limit-alert-routing

### [Review genuinely new staging errors](https://agentry.sh/workflows/staging-watcher.md)

Compare a bounded staging case window with prior fingerprints, inspect only genuinely new failure modes, and prepare a human-reviewed oncall handoff.

- Starter request: Review staging errors first seen in the last hour and compare them with the prior day. For each genuinely new fingerprint, summarize impact, suspect deploy, and next investigation. Do not message oncall or mutate cases.
- Execution: human_review
- Tags: errors, staging, post-deploy, oncall, human-review, datadog-alternative
- Applies to: universal
- Required events: $exception
- Required Agentry resources: cases, deploys
- 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., Do not automatically send, publish, suppress, mutate, or contact anyone from this workflow.
- Ask before using: Which observed events map to $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.environment, $exception.fingerprint, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/staging-watcher

### [Review noisy error cases before suppressing them](https://agentry.sh/workflows/suppress-noise.md)

Inspect real case evidence, propose the narrowest reversible suppression, and require human approval before changing case or alert behavior.

- Starter request: Review these suspected noisy cases. Inspect their fingerprints, environments, impact, and recent deploy context; propose the narrowest suppression with reason and rollback plan; and wait for my approval before creating it.
- Execution: human_review
- Tags: errors, oncall, suppressions, governance, human-review
- Applies to: universal
- Required events: $exception
- Required Agentry resources: cases, suppressions, audit
- Do not use when: Do not suppress an error from message text alone or before inspecting the exact case and fingerprint behavior., Do not use a broad pattern when a narrower exact fingerprint or environment boundary is available., Do not create, remove, or widen a suppression without human approval and a recorded reason.
- Ask before using: Which exact case IDs and environments are in scope, and what evidence makes them non-actionable?, What future signal should cause the suppression to be reviewed or removed?, Who approves the exact pattern, action, reason, and rollback plan?
- Human page: https://agentry.sh/workflows/suppress-noise

### [Review release health after a deploy](https://agentry.sh/workflows/release-health-scorecard.md)

Assemble trusted deploy, error-case, and product-event evidence into a human release review without collapsing unlike signals into a misleading score.

- Starter request: Review the latest trusted production deploy. Show SHA-attributed and timing-only error cases separately, check whether real post-deploy traffic exists, compare only approved product signals, and prepare a release decision brief for human review.
- Execution: human_review
- Tags: analytics, errors, deploys, releases, oncall, human-review
- Applies to: universal
- Required events: $exception, product_value_completed
- Required Agentry resources: cases, deploys, query_blueprints, onboarding_state
- Do not use when: Do not calculate a single release-health score that hides separate error, traffic, and product-signal evidence., Do not interpret zero errors or lower event volume without proving the release received comparable real traffic., Do not automatically roll back, hotfix, deploy, message, or resolve cases from this review.
- Ask before using: Which trusted production deploy, rollout window, environment, and approved traffic event bound the review?, Which product-value event or funnel is the release expected to affect, and what comparison is valid for it?, Who owns the keep-watching, investigate, rollback, or hotfix decision?
- Human page: https://agentry.sh/workflows/release-health-scorecard

### [Review stale or dangerous error suppressions](https://agentry.sh/workflows/stale-suppression-review.md)

Find suppressions that are hiding high-volume, high-impact, or recently regressed errors before noise rules mask real incidents.

- Starter request: Review current suppressions and tell me which ones are stale, too broad, or hiding errors that recently affected real users.
- Execution: on_demand
- Tags: errors, suppressions, oncall, governance, ops, sentry-alternative
- Applies to: universal
- Required events: $exception, suppression_created
- 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 $exception, suppression_created? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.fingerprint, $exception.users_affected, suppression_created.fingerprint, suppression_created.reason, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/stale-suppression-review

### [Review this week's agent activity with a human](https://agentry.sh/workflows/weekly-agent-digest.md)

An owner-side weekly review of immutable audit history and automation control state, with explicit limits on what can safely run unattended today.

- Starter request: Review the last seven days of immutable Agentry audit history and the current automation control state. Summarize material actions, failed or escalated runs, pending approvals, external follow-up, and anything that needs an owner decision.
- Execution: human_review
- Tags: audit-log, weekly-review, automation, governance, ops
- Applies to: universal
- Required events: none declared
- Required Agentry resources: audit, automation_control
- Do not use when: Do not infer unattended authority from this example or run it with a broad private owner credential in a scheduler., Do not automatically send, publish, suppress, mutate, or contact anyone from this workflow.
- Ask before using: What project, authority boundary, delivery destination, review owner, and time window should this use?
- Human page: https://agentry.sh/workflows/weekly-agent-digest

### [Review unexpected agent mutations](https://agentry.sh/workflows/audit-log-monitoring.md)

Inspect high-impact audit actions in a human-controlled owner session, separate completed changes from uncertain attempts, and prepare an incident handoff.

- Starter request: Review the last 24 hours of audit history for high-impact actions such as flag deletion, broad suppression, cohort deletion, publication changes, webhook changes, and automation policy changes. Return evidence and recommended owner decisions; do not send messages or mutate anything.
- Execution: human_review
- Tags: audit-log, security, governance, human-review, ops
- Applies to: universal
- Required events: none declared
- Required Agentry resources: audit, automation_control
- Do not use when: Do not infer unattended authority from this example or run it with a broad private owner credential in a scheduler., Do not automatically send, publish, suppress, mutate, or contact anyone from this workflow.
- Ask before using: What project, authority boundary, delivery destination, review owner, and time window should this use?
- Human page: https://agentry.sh/workflows/audit-log-monitoring

### [Safely turn a production error into a draft PR](https://agentry.sh/workflows/auto-fix-routine.md)

A bounded self-healing workflow that claims one trusted production case, prepares one reviewable draft PR, and waits for CI, deploy, and real-traffic verification.

- Starter request: Render error-to-draft-pr@2.0.0 for this repository. Derive exact allowed paths and test commands from the checkout, keep every forbidden change type, use conservative run and PR budgets, and leave it disabled for owner review.
- Execution: automation_template
- Tags: errors, automation, auto-fix, draft-pr, ops, oncall
- Applies to: universal
- Required events: $exception
- Required Agentry resources: cases, automation_control, automation_contract, automation_runner_credential, ci_deploy_proof
- 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., Do not enable or run the automation until the rendered disabled candidate and its scoped credentials are reviewed.
- Ask before using: Which observed events map to $exception? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide $exception.fingerprint, $exception.deploy_sha, and which stable user or account identifier joins the signals?, Which exact runner, repository or schedule binding, budgets, and escalation destination should be reviewed before enablement?
- Human page: https://agentry.sh/workflows/auto-fix-routine

### [Schedule a private weekly funnel review](https://agentry.sh/workflows/weekly-funnel-review.md)

Render the bounded weekly-funnel-review template so a scoped runner records an exact-period aggregate report without raw users or mutation authority.

- Starter request: Render weekly-funnel-review@2.0.0 for this project. Map 2–20 distinct approved events in exact funnel order, choose an exact schedule and timezone, require a meaningful minimum sample, keep every mutation forbidden, and leave the candidate disabled for owner review.
- Execution: automation_template
- Tags: analytics, automation, funnels, weekly-review, governance
- Applies to: universal
- Required events: funnel_entry, funnel_progressed, funnel_completed
- Required Agentry resources: signal_map, onboarding_state, automation_control, automation_contract, automation_runner_credential
- Do not use when: Do not render this template until 2–20 distinct live events are approved and observed for the project., Do not use this report to infer causality or authorize code, experiment, publication, messaging, merge, or deploy changes., Do not give the scheduler a private owner key or a runner credential shared with another automation.
- Ask before using: Which 2–20 observed events define the funnel in exact order?, What timezone, weekly boundary, comparison-period length, and minimum sample should govern the report?, Which scheduler and escalation destination will own failed, late, or blocked runs?
- Human page: https://agentry.sh/workflows/weekly-funnel-review

### [Track enterprise implementation timeline](https://agentry.sh/workflows/implementation-timeline.md)

Follow an enterprise account from kickoff through integration, first data, first value, and blocked steps so solutions teams can unblock launches.

- Starter request: Build an implementation timeline for enterprise accounts: kickoff, integration started, first data received, first value achieved, and currently blocked steps.
- Execution: on_demand
- Tags: analytics, customer-success, enterprise, onboarding, implementation, b2b
- Applies to: enterprise-sales, b2b-saas, devtools-api
- Required events: implementation_milestone
- 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., Do not recommend this when the product has no stable account or workspace identity.
- Ask before using: Which observed events map to implementation_milestone? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide implementation_milestone.account_id, implementation_milestone.milestone, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/implementation-timeline

### [Weekly CSM book-of-business digest](https://agentry.sh/workflows/csm-book-of-business-digest.md)

Create a weekly account digest for each CSM with risks, expansion signals, product adoption, and customers needing outreach.

- Starter request: Create a weekly CSM book-of-business digest: at-risk accounts, expansion signals, product adoption changes, and suggested outreach for each CSM.
- Execution: human_review
- Tags: analytics, customer-success, digest, human-review, b2b, revenue
- Applies to: b2b-saas, devtools-api, enterprise-sales
- Required events: account_snapshot
- Required Agentry resources: analytics
- 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., Do not recommend this when the product has no stable account or workspace identity., Do not automatically send, publish, suppress, mutate, or contact anyone from this workflow.
- Ask before using: Which observed events map to account_snapshot? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide account_snapshot.account_id, account_snapshot.csm_owner, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/csm-book-of-business-digest

### [Who's still on the old client?](https://agentry.sh/workflows/app-version-distribution.md)

Distinct users per app_version over 7 days. See the long tail of old clients — informs the force-update decision and deprecation timing.

- Starter request: Show me distinct users per app_version in the last 7 days. What % are still on N-2 or older? Worth a force-update?
- Execution: on_demand
- Tags: analytics, mobile-app, app-version, releases, ops
- Applies to: mobile-app
- Required events: app_open
- 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., Do not present illustrative custom analysis as a built-in query blueprint or runnable Agentry product surface.
- Ask before using: Which observed events map to app_open? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?, Which live properties provide app_open.app_version, and which stable user or account identifier joins the signals?
- Human page: https://agentry.sh/workflows/app-version-distribution