AGT-503 — Expansion Trigger Agent
Layer 5: Post-Sale Retention · 5-signal expansion scoring · Churn risk gate · Open opp check · UsageMeteringLog as usage signal source
L5 · Agent 03
Specced · v19 original + v25 ripple update
L8 ripple: UsageMeteringLog explicitly named as usage signal source for overage and seat utilization signals
v38 update: tier-migration as expansion type for consumption-pricing tiered platforms
v38.5 update: tier-migration is two-axis (margin axis + control axis)
L8 ripple update (v25)
Update — usage signals explicitly source from UsageMeteringLog
Two expansion signals previously referenced "AGT-804 usage data" without specifying the schema table. UsageMeteringLog now exists as the canonical source.
Consumption overage signal (+40 pts — immediate):
· Reads: UsageMeteringLog WHERE account_id = [account] AND overage_units > 0 AND period_end = [most recent closed period]
· Trigger: any consumption SKU showing overage in the most recent metering period → immediate expansion evaluation, bypasses scheduled daily cycle
· AGT-804 pushes UsageMeteringLog writes in real-time as metering periods close — AGT-503 listens for new records on this account
Seat utilization >80% signal (+30 pts — immediate):
· Reads: UsageMeteringLog WHERE account_id = [account] AND sku_id LIKE 'SKU-SEAT%' ORDER BY period_end DESC LIMIT 2
· Trigger: (units_consumed / commit_units) > 0.80 for 2 or more consecutive metering periods → immediate expansion evaluation
· Requires 2+ consecutive periods to avoid false positives from one-time utilization spikes
Both signals bypass AGT-503's scheduled daily cycle when they fire. UsageMeteringLog is the single integration point — AGT-503 does not query the product metering system directly.
Purpose
AGT-503 detects expansion opportunities across the customer base and routes plays to the AM. It never creates a play without first running a churn risk gate (suppresses High/Critical risk accounts) and an open opportunity check (avoids duplicate plays when expansion is already in progress). It is the first agent in the OS to quantify NRR upside — expansion ACV estimates feed AGT-402's bottoms-up forecast and AGT-702's MetricsCalcLog.
Entry paths
| Path | Source | Cycle behavior |
|---|
| AGT-502 Low-tier pass | ChurnRiskLog.expansion_candidate = TRUE (AGT-502 sets when risk tier = Low) | Scheduled daily cycle. Runs after AGT-502 completes. |
| UsageMeteringLog threshold event | New UsageMeteringLog record with overage_units > 0 OR seat utilization > 0.80 for 2+ periods | Immediate — bypasses scheduled cycle. Fires on AGT-804 write. |
Gates (run before any signal scoring)
| Gate | Logic | Result |
|---|
| Churn risk gate | Read CustomerHealthLog.health_score (AGT-501) | High/Critical = suppress entirely. Medium = CSM confirm required before play. Low = proceed. |
| Open opportunity check | Query Opportunities for open expansion opp on this account | Open opp exists = enrichment path only (append context to existing opp, single update to AM). No new play created. |
5-signal expansion scoring
| Signal | Pts | Mode | Source |
|---|
| Consumption overage | +40 | Immediate | UsageMeteringLog.overage_units > 0 — most recent closed period |
| Seat utilization >80% for 2+ months | +30 | Immediate | UsageMeteringLog (units_consumed / commit_units) > 0.80 — 2+ consecutive periods |
| ConvIntelligence feature inquiry + positive sentiment | +30 | Immediate | ConvIntelligence — feature inquiry keyword pattern + overall_sentiment = positive in same conversation |
| New stakeholder engaged | +20 | Digest | Contacts — new persona record created or first engagement logged for this account |
| Cross-sell peer cohort gap | +15–25 | Digest | Peer cohort: segment × vertical × size band, minimum 5 accounts, ≥60% match rate. Gap = peer accounts on SKU that this account doesn't have. |
Immediate signals bypass the scheduled cycle and trigger AGT-503 directly. Digest signals accumulate and are evaluated on the next scheduled run. An account can have both immediate and digest signals; they are scored together on whichever run processes them.
Play types
| Play type | When | Action |
|---|
| New play | No open expansion opp, churn gate passes, signal threshold met | Expansion play created and routed to AM via TerritoryDefinitions (not RepBook) |
| Enrichment path | Open expansion opp already exists | Context appended to existing opp, single contextual update to AM. No new play. |
| Tier-migration play (v38) | Customer is on a low-margin product tier and qualifies for a higher-margin tier (per TOOL-015 GP-uplift projection) | Migration play routed to AM with TOOL-015 decomposition + projected GP uplift + switching-cost class. Distinct from ARR-uplift expansion: revenue may stay flat or even dip slightly while GP improves. |
| Suppressed | High/Critical churn risk, or Medium churn without CSM confirmation | No play. suppressed_reason logged in ExpansionLog. |
Tier-migration expansion (v38) — for consumption-pricing tiered platforms
Some products have multiple consumption tiers with structurally different gross margins (e.g., shared / dedicated / bring-your-own-cloud, or self-service / managed / control-plane). Moving a customer up the tier ladder is an expansion motion even when ARR is flat or down, because realized GP improves materially. AGT-503's classic 5-signal model targets ARR uplift; tier-migration adds a parallel signal + play type targeting GP uplift.
6th signal — tier-migration eligibility
| Signal | Pts | Mode | Source |
|---|
| Tier-migration eligibility | +25 to +50 | Digest (weekly) | TOOL-015 Consumption-Margin Decomposer projects projected GP uplift for default migration scenario. Pts scale with projected uplift: < 5pp = 0 (no signal); 5–10pp = +25; 10–20pp = +35; > 20pp = +50. |
Tier-migration gates (run before play creation)
| Gate | Rule |
|---|
| Switching-cost class threshold | If TOOL-015 returns switching_cost_class = "very_high" AND projected GP uplift < 15pp, suppress play (the math doesn't justify the customer-side disruption). Override allowed by RevOps. |
| Technical-prerequisite check | For migrations requiring customer-side infrastructure (e.g., bring-your-own-cloud destinations), verify cloud account exists or pre-existing technical relationship. AGT-602 Technical Implementation gate — if customer has not deployed any production workloads, suppress play (premature). |
| Onboarding-completion gate | Suppress for accounts with onboarding_status = 'active'. Tier migration on a customer who hasn't fully ramped on current tier is a sales motion that backfires — AM must close the loop on activation first. |
| Revenue-floor gate | Suppress for accounts below a revenue threshold (configurable per segment, default $50K trailing-quarter revenue). Below the floor, tier migration is rarely worth the customer-side engineering work. |
Tier-migration play structure
| Field | Content |
|---|
| Play type | tier_migration (distinct from new_play) |
| Hypothesis | Pre-filled from TOOL-015 output: "Migrating customer from {from_tier} to {to_tier} projects GP uplift of {gp_uplift_pct}pp on trailing-quarter consumption. Switching cost: {switching_cost_class}." |
| credible_alternative_consideration | Pre-filled from TOOL-015 output: the case for NOT migrating, surfaced explicitly so AM has it before the conversation. Brain-discipline mirror. |
| Suggested cadence | Technical conversation + business-case review + customer-side engineering qualification. AM-led, not SDR-led. AGT-602 Technical Implementation engaged early for technical-prerequisite verification. |
| Success criteria | Migration completed AND realized GP uplift over 2 trailing quarters post-migration meets or exceeds 60% of projected. Recorded in ExpansionLog for retrospective analysis (cohort: did our tier-migration projections hold?). |
v38 ripple to ExpansionLog schema: add fields play_type ENUM('new_play','tier_migration','enrichment'), tier_migration_from, tier_migration_to, projected_gp_uplift_pct, switching_cost_class, realized_gp_uplift_pct (post-migration retrospective). Companion v38 ripple to AGT-101 + AGT-103: GP-overlay comp variant rewards reps on realized GP uplift, not just on ARR delta — see AGT-101 v38.
Why tier-migration belongs in AGT-503 and not elsewhere. Tier-migration is a post-sale motion against an existing customer with an existing relationship; AM is the executor; success is measured in GP delta on the same revenue. That's structurally an expansion play, not a new-deal motion. The only deviation from classic expansion is that ARR may not move — which is why the 6th signal scores GP uplift, not ARR uplift, and why AGT-101 v38 introduces a GP-overlay comp variant aligned to this motion.
Tier-migration two-axis extension (v38.5)
v38 modeled tier-migration on a single axis: the margin axis (low_margin → mid_margin → high_margin, mapping to e.g. shared / dedicated / BYOC infrastructure tiers). v38.5 recognizes a parallel and independent control axis that drives a distinct expansion motion: fully_managed → off_the_shelf → low_level_control (per AGT-201 v38.5 gtm_motion_class). Customers can move along either axis independently. Two motions; two play types; two distinct GP-uplift mechanisms.
Two axes, four motion intersections
| Margin axis | Control axis | Migration motion |
|---|
| low_margin → high_margin | (unchanged) | Classic margin-tier migration. Customer moves to dedicated / BYOC infrastructure for technical or commercial reasons. ARR may stay flat; GP uplift. |
| (unchanged) | fully_managed → off_the_shelf | Customer's ML team grows or matures; they want cookbook-style training paths. ARR may grow as workflow scope expands. GP uplift modest. |
| (unchanged) | off_the_shelf → low_level_control | Customer's research team needs custom training loop / alignment / RL behavior. ARR grows materially with R&D budget. GP uplift significant — low-level-control is highest WTP. |
| low_margin → high_margin | fully_managed → low_level_control | Two-axis combined motion. Rare but high-value (e.g., enterprise customer maturing both their infra strategy and their ML team simultaneously). Expensive multi-quarter motion involving AGT-602 throughout. |
7th signal — control-axis migration eligibility
| Signal | Pts | Mode | Source |
|---|
| Control-axis migration eligibility | +20 to +45 | Digest (weekly) | AGT-201 gtm_motion_class_last_evaluated change since prior cycle (forward direction only — reclassification from off_the_shelf to low_level_control fires the signal; reverse reclassification suppresses the signal). Pts scale with revenue size of the account at time of reclassification. |
play_type axis labeling (v38.5 schema extension)
ExpansionLog gains a tier_migration_axis field on tier-migration plays:
| tier_migration_axis | Meaning |
|---|
margin | Shared → dedicated → BYOC (existing v38). GP-uplift driven by infrastructure cost change. |
control | Fully-managed → off-the-shelf → low-level-control. GP-uplift driven by per-unit price increase (low-level-control commands premium pricing) + scope expansion. |
combined | Both axes moving simultaneously. Rare; flagged for SLM review at play creation. |
Play structure differences by axis
| Field | margin axis | control axis |
|---|
| Hypothesis pre-fill | From TOOL-015 GP-uplift projection (existing) | From AGT-201 reclassification event + EnrichmentLog ML-team evidence + ConvIntelligence research-pattern signal |
| Switching cost | Driven by infrastructure customer-side work (BYOC requires cloud account + integration) | Driven by ML-team capacity uplift on customer side. Often lower switching cost than margin-axis BYOC because no customer-side infra change is needed. |
| Technical-prerequisite gate (AGT-602) | Customer-side cloud account exists for BYOC | Customer-side ML / Research team identified; engineering capacity for custom training loop confirmed |
| credible_alternative pre-fill | From TOOL-015 | From conversation-intel: typical case is "team isn't ready / will hire later" — explicitly surfaced so AM has the contrary view |
| Comp signal (AGT-101 v38 GP-overlay) | Realized GP uplift on existing revenue | Realized GP uplift + new revenue from expanded scope (low-level-control plays often add scope) |
Why two axes. A customer may have been on shared infrastructure (low_margin) AND fully_managed (control axis) — classic Uber-style "give me an API and let me ship." Their natural growth path branches: (a) move to dedicated infra for predictable performance (margin axis only) — sales motion is infrastructure-led; (b) grow their ML team and demand custom training (control axis only) — sales motion is research-led; (c) both. AGT-503 must distinguish so the right play type fires with the right cadence + the right comp incentive.