Processes sales and CS call recordings (Gong, Chorus) on a rolling basis — distinct from per-study research synthesis. Extracts JTBD signals, objection patterns, competitor mentions, and feature requests. Weights by ARR and customer tier. Surfaces structured opportunity candidates to the Phase 1 signal queue continuously, not per research cycle. Best-in-class teams run this as always-on infrastructure, not a periodic research event.

Reads product analytics continuously (Amplitude, Mixpanel, Heap, or equivalent). Monitors for usage pattern anomalies, drop-off points, feature abandonment rates, and workflow completion rates. When a pattern meets a threshold (e.g., 15%+ decline in feature completion over 30 days), surfaces a structured signal card to the PM queue. Best-in-class teams treat behavioral analytics as a discovery feed, not a reporting tool — this agent makes that operational without requiring a PM to live in dashboards.

Compares current user behavioral data against documented persona assumptions on a rolling cadence. When behavior diverges — segments using features in unexpected ways, new usage patterns emerging outside persona boundaries, persona-attributed jobs being completed by non-target segments — surfaces a “persona drift card” for PM + Design. This signal is typically discovered when a customer tells you, not proactively. Best-in-class teams instrument this explicitly.

From a signal brief + problem statement, produces a structured sizing input: ARR at risk from inaction, ARR opportunity from capture, customer tier distribution of affected accounts, adoption rate projection from comparable features. Not a recommendation — a structured evidence package to inform PM prioritization judgment. Best-in-class teams run this before any G1 conversation; it’s the difference between prioritization discussions grounded in numbers vs. conviction.

Before G1 closes, reads the problem statement and surfaces unstated assumptions against a structured taxonomy: user behavior assumptions, technical feasibility assumptions, market assumptions, and scope assumptions. Output: “This problem statement implicitly assumes [X]. Validation status: [none found / supported by signal brief / contradicted by behavioral data].” Does not block G1 — produces an assumption log that the trio reviews. The discipline of making assumptions explicit before spec authoring eliminates an entire class of late-stage scope changes.

When a problem statement is defined, searches the competitive intelligence corpus for analogous features in adjacent products and summarizes how they solved the same job: interaction model, scope decisions made, known user reception signals. Gives PM and Design a starting point for exploration rather than building from first principles every time. Best-in-class teams systematize this; most teams rely on individual memory of what competitors have shipped.

Early engineering input before full Architecture engagement. Reads the problem statement and surfaces likely technical complexity signals from the constitution and companion files: known platform constraints, relevant prior architecture decisions, services likely to be implicated, and conditions that would trigger an Architecture engagement requirement. Not an Architecture review — a pre-screen that helps the trio arrive at G1 with an informed complexity estimate rather than discovering it during spec authoring.

Runs against the structured spec before G2 closes. Checks structural completeness (required sections populated), P7 sufficiency thresholds by feature type, and internal consistency: every state in §2.4 governed by at least one AC; every AC maps to a testable assertion. Outputs a sufficiency report: pass, conditional (gaps flagged), or fail. Catches the most expensive class of generation failures before generation runs.

Reads the draft spec against the Living Dependency Graph (see Cross-Team System). Surfaces undeclared external dependencies before G2 closes: “This spec references [entity X] — cross-team dependency candidate. Contract status: unregistered.” Outputs a dependency candidate list for Engineering to resolve before G2. Makes near-zero undeclared contracts at G2 mechanically achievable rather than memory-dependent.

Goes beyond sufficiency check. Specifically evaluates AC quality against three criteria: testability (can two engineers independently write passing tests for this AC?), independence (does this AC require another AC to be true first?), and state coverage (does this AC’s condition map to exactly one state in §2.4?). Output: structured AC quality report. “AC [X] is ambiguous — two engineers would implement it differently. Suggested rewrite: [draft].” PM resolves before G2 closes.

Before generation begins, reads the spec and the domain constitution companion file and produces a structured constraint inventory: DS rules active for this feature, states with no existing DS coverage (will require design judgment at generation time), architecture constraints from prior decisions, and localization/accessibility flags. Gives Design a complete constraint surface map before the generation session — eliminating the discovery-during-generation pattern that causes generation stops.

Integrated with design generation. When variants are generated, produces companion microcopy: button labels, error messages, empty states, tooltips, and inline help text — consistent with brand voice guidelines and UX writing standards in the constitution. Currently copy is authored after design approval, often by a different person, creating copy/design misalignment that surfaces at G3 or in QA. Best-in-class teams generate copy and UI simultaneously from the same spec.

At generation time, flags UI elements likely to have l10n/i18n implications: string lengths that won’t work in German/French/Japanese, date/number formatting embedded in layout, RTL considerations, character set assumptions. Surfaces before G3 so Engineering is not discovering localization complexity mid-implementation. Most teams discover l10n issues in QA. Moving this upstream is one of the cleanest engineering cycle time wins available.

After variant selection, assesses the selected interaction model against established usability heuristics (Fitts’s Law for target sizes, Miller’s Law for information chunking, progressive disclosure principles). Produces a structured “interaction cost report”: friction points, estimated cognitive load per step, comparison against the current baseline interaction model where one exists. Not a gate — a second opinion that Design can act on before G3. Best-in-class design teams use this as a UX quality forcing function that scales with volume.

Extends beyond the output generation agent’s QA test cases. Generates actual test code scaffolds from the acceptance criteria and state list: unit test structure (describe/it blocks with test data placeholders), e2e test setup (Playwright/Cypress spec scaffolds keyed to user journeys), and integration test contracts for declared service dependencies. Engineering Lead populates; doesn’t start from scratch. This is one of the highest-leverage engineering time savers in the workflow — test authoring from spec is mechanical work that should be automated.

Cross-references the analytics plan against what’s technically instrumentable given the current telemetry infrastructure and the engineering spec. “Event [X] in the analytics plan requires [capability Y] which is not in the current instrumentation layer.” Flags plans that sound good but will produce no data. Also validates that the analytics plan covers the JTBD completion signal — the critical missing piece in most feature analytics plans. Analytics plans that can’t be implemented are discovered at G4 or post-ship under current practice.

Before G3, reads acceptance criteria against the codebase architecture and the engineering spec. Produces a structured implementability assessment: “AC [X] requires access to [service Y] via [method Z]. Contract status: [registered / unregistered]. Estimated complexity: [low / medium / high]. Known constraints: [list].” Reduces G3 feasibility revision cycles — the most expensive revision type because it routes back to Design. Engineering Lead reviews assessment before G3; uses it to structure the review conversation.

Runs on schedule or as pre-gate check. Reads the spec amendment log, architecture review records, and spec gap log. Cross-references against the decision log. Surfaces any spec-altering event without a corresponding decision log entry. Makes it structurally impossible to clear a gate with a silent amendment. Addresses rework cause #2 (absent decision logs) mechanically — same principle as embedding measurement capture as a blocking gate criterion rather than a monitoring task.

From the unit of work brief and two-step review results, generates a structured PR description: what changed, why (spec reference), AC coverage (which ACs this PR addresses), testing notes, and spec section cross-references. Engineering Lead reviews before submitting. Reduces documentation overhead without reducing information quality — and produces PR descriptions that code reviewers can actually use rather than vague summaries. Compounds with the decision log integrity agent by making spec-to-PR traceability consistent.

From the feature flag model and rollout plan in the engineering spec, generates feature flag configuration, segment targeting rules, and rollout schedule. Engineering Lead reviews; agent reduces manual configuration work and eliminates a class of rollout errors that come from manually translating spec intent into feature flag logic. Connects directly to the stability window framework (48h default, 24h floor) — rollout schedule generated against that constraint.

Reads git commit history, ADO state transitions, PR timestamps, and gate sign-off records. Reconstructs phase cycle times without human recall. Flags where transitions can’t be inferred — which is itself a data quality signal (missing artifacts). At rollout scale, manual measurement is the reliability ceiling. This agent removes it.

Monitors companion files against change events in the constitution, DS component library, and pattern registry. Triggers on: constitution amendment, component deprecation, new pattern promotion, new architecture decision. Flags: “[Domain] companion file — last updated [date]. Events since: DS token [X] deprecated. Review required before next generation session.” Context quality is the generation quality ceiling; staleness degrades it silently.

When a pattern candidate is confirmed for promotion by Design and DS Team, drafts the pattern documentation: usage guidance, variant descriptions, accessibility notes, do/don’t examples, and code reference. DS Team reviews and approves; doesn’t author from scratch. Eliminates the most common pattern compounding failure: the pattern is identified, confirmed, and then never documented because documentation is manual and time-consuming.

After a pattern is promoted, identifies all active features currently in G0–G2 that could benefit from the newly promoted pattern and notifies the relevant trios. Makes pattern compounding active rather than passive — currently, a newly promoted pattern only benefits the next feature if the designer happens to know it exists. This agent makes pattern reuse systematic across the domain rather than designer-memory-dependent.

Takes the original job statement from the spec and the analytics plan’s success events. Continuously measures: what % of users who attempted the job completed it? Surfaces trajectory (improving/declining/stalled) and segments by customer tier, account size, usage cohort, and entry path. When completion rate falls below threshold or trajectory declines over a defined window, generates a structured signal card that routes back to Phase 1 as an opportunity candidate. This is the primary mechanism for closing the discovery loop — without it, post-ship signal is informal and PM-dependent.

Distinct from the feedback agent (which monitors telemetry events against the analytics plan). Synthesizes qualitative friction signals across: session recording tools (Fullstory, FullSession), support tickets tagged to the feature, in-app feedback responses, and CSM escalations. Produces a weekly synthesis: top friction points by user segment, friction trend (increasing/decreasing), specific interactions generating the most abandonment, and sentiment themes from support. Routes to Design as a structured friction report rather than a pile of individual signals.

From post-ship signal (JTBD completion rate, friction synthesis, usage patterns, VoC signals about the shipped feature), generates ranked enhancement candidate briefs in the Phase 1 signal brief format. These feed directly back into the Phase 1 queue — closing the discovery loop structurally rather than relying on PM memory and attention. PM reviews and decides whether to promote. This makes the FDLC a self-generating system rather than a one-directional pipeline.

At a defined interval post-ship (typically 60–90 days), calculates feature ROI against the original opportunity sizing from Phase 1: ARR impact (adoption × ARR tier weighting), adoption rate vs. projection, usage trajectory (growing / flat / declining), support cost delta (support tickets tagged to this feature vs. baseline), and JTBD completion rate trend. Produces a structured evidence package for CPO review and rollout decision-making. Makes the business case for the workflow retroactively verifiable against real outcomes.

When a service owner merges a contract change, agent reads the LDG, identifies all dependent teams with active features in G1–G4, and sends a structured notification to each: “Service [X] contract version [N→N+1]. Breaking changes: [structured diff]. Your features affected: [list by feature name]. Action required by: [date based on each feature’s current gate position].” This makes it structurally impossible for a contract change to be invisible to dependent teams. Under current practice, dependent teams discover contract changes from test failures.

When multiple teams’ specs reference the same shared entity, service, or data model, agent identifies the alignment opportunity or conflict before both proceed to G2. “Specs [A] and [B] both declare a dependency on [service X]. Their data shape declarations for [entity Y] differ: [structured diff]. Alignment needed before both proceed to G2.” Catches the scenario — common in enterprise software — where two domain teams independently design against the same service with different assumptions and only discover the conflict when both try to ship.

Based on historical data accumulated across features, produces a risk score per declared dependency: “High risk — [service X] has been a source of mid-build interruptions in [N] of [M] features that declared this dependency. Common failure pattern: [contract staleness / unclear ownership / versioning gaps].” Flags high-risk dependencies for early Architecture engagement at G1 rather than waiting for the standard G2 declaration. Requires enough feature history to be meaningful — a post-rollout capability.

When a DS component or shared platform component is scheduled for a change (version, deprecation, or API modification), agent identifies: all active feature specs using this component (from the LDG + spec corpus), estimated impact severity per feature (breaking change vs. compatible vs. visual-only), and recommended engagement timeline per trio. DS Team and affected trios are notified with enough lead time to plan around the change — not discover it as a mid-sprint surprise. Closes the feedback loop between DS evolution and active feature work.

As multiple domains develop features independently, similar interaction patterns emerge independently — each team reinventing the same solution. This agent compares validated prototypes across domains and surfaces alignment opportunities: “Domain A’s [feature X] and Domain B’s [feature Y] have implemented structurally similar patterns for [interaction type]. Candidate for cross-domain consolidation or shared pattern promotion.” Currently this discovery is entirely accidental. Most compound design system debt originates from this exact failure mode. This agent makes convergence detection systematic across the domain portfolio.