Product Discovery Agent — Engineering Guide

InfinitySDLC Engineering Guides · 02/12

A discovery agent should not invent requirements. Its job is to assemble evidence, expose contradictions and turn uncertainty into product hypotheses that a team can accept, test or reject.

Reference engineering design, not a report of a completed client deployment. Sections 2.1–2.6 and the implementation blueprint build on the Enterprise AI Agent Mesh handbook. Sections 2.7–2.12 add engineering recommendations and explicitly illustrative scenarios. Numerical examples are not client results.

The useful deliverable is not a longer product requirements document. It is a decision package that explains what is known, which sources support it, what remains uncertain and which investigation would change the decision.

Evidence can justify a hypothesis. Only an explicit product decision can turn that hypothesis into an authoritative requirement.

The Header diagram is a conceptual overview. Its opportunity maps, user stories and backlog outputs remain proposals until the corresponding human review. Illustration prepared for Infinity Technologies. Open the diagram at full size.

2.1 Inputs and outputs

Run discovery read-only by default. Creating a draft document or proposed ticket set is a separate, narrowly scoped write capability. The agent must never silently change the authoritative backlog.

2.2 Integrations and MCP servers

The handbook separates discovery access into five tool groups. These are internal interface examples, not a claim that every vendor exposes the same ready-made MCP server.

• Work management: search issues, retrieve epics and issue history, list labels and create draft issues. Normalize Jira, Linear or Azure DevOps behind an internal schema.
• Knowledge: search documents and retrieve specific versions from Confluence, SharePoint, Drive or an internal wiki, preserving access controls.
• Customer evidence: return redacted conversation excerpts, account segments and issue categories from approved CRM or support sources.
• Analytics: execute parameterized queries over approved metrics and datasets. Do not expose an unrestricted warehouse SQL interface.
• Repository context: provide semantic code search, dependency graphs, API catalogs and ownership lookup.

Expose a small, coherent tool surface before adding more integrations. Anthropic’s tool-design guidance recommends distinct, task-oriented tools and bounded, relevant responses rather than a large catalog of low-level wrappers.

2.3 Discovery RAG design

Keep durable product knowledge and high-volume customer evidence in separate logical indexes. Tag customer material with date, segment, product version, geography and source channel. Retrieval should diversify evidence so that one noisy customer or recent ticket does not dominate.

The handbook proposes a starting allocation of 30% authoritative product or strategy documents, 30% customer evidence, 20% analytics summaries and 20% technical constraints.

Engineering qualification: these percentages are a retrieval-budget heuristic, not a representative customer sample or a statistical confidence model. Tune them against discovery tasks; do not manufacture evidence to fill an empty category.

evidence_query = {
  "problem": "bulk user onboarding failures",
  "facets": [
    "customer", "analytics",
    "product_docs", "code_constraints"
  ],
  "time_window": "180d",
  "min_distinct_accounts": 5,
  "require_contradictory_evidence": True
}

A minimum account count is an investigation constraint, not permission to invent missing accounts. If only two relevant accounts are accessible, return that limitation and the unresolved coverage gap.

2.4 Agent workflow

1. Parse the discovery question and define what must be established for a useful answer.
2. Retrieve authoritative context and known constraints.
3. Collect evidence across accounts and channels; aggregate rather than copying raw transcripts.
4. Query product analytics for frequency, funnel or cohort evidence.
5. Inspect the implementation and integration boundaries.
6. Generate competing hypotheses instead of one polished narrative.
7. Produce an evidence matrix with source identifiers, supporting and contradicting evidence, freshness and uncertainty.
8. Draft requirements only after a human selects or approves a hypothesis.

# Illustrative example from the source handbook
Hypothesis H3:
  Onboarding fails primarily for
  SCIM-mapped enterprise groups.
Confidence: 0.74
Support:
  - support_case:CS-1882 (v2026.08)
  - metric:scim_sync_error_rate.enterprise (8.3%)
  - code:identity/scim/group_mapper.py@9d41a2
Contradictions:
  - Two SMB accounts show the same symptom
    without SCIM.
Open test:
  - Compare failures by group size and
    directory provider.

The handbook’s 0.74 value is illustrative. Without a defined calibration procedure, it must not be presented as a 74% probability that the hypothesis is true. The 8.3% metric is also an example, not an observed Infinity customer result.

2.5 Model allocation

Use evaluated local models for bulk transcript classification, deduplication and first-pass clustering where data policy and measured quality make that appropriate. Use Claude or Codex for eligible cross-source synthesis involving code and product documentation.

For repository-heavy discovery, run the coding harness in a read-only workspace and return structured findings through the control plane. The sandbox, outbound network policy and downstream credentials—not the prompt alone—enforce the boundary. OpenAI’s Codex security documentation distinguishes sandbox restrictions from approval policy; configure both for the intended discovery role.

Local hosting is not, by itself, a privacy guarantee. Embedding services, rerankers, telemetry, backups and export destinations must follow the same data policy. Model choice should not alter who can retrieve evidence or authorize a backlog change.

2.6 Evaluation

• Evidence recall: recover relevant sources from a curated discovery set.
• Contradiction detection: surface evidence that weakens the preferred hypothesis.
• Requirement traceability: cite approved evidence or explicitly label assumptions.
• Privacy: minimize customer text and prevent retrieval into unauthorized contexts.
• Freshness: distinguish old product behavior from current versioned decisions.

2.7 Build an evidence ledger, not a pile of citations

A link to a document does not establish that the document supports a particular claim. Persist claims and their evidence relationships as structured records. Keep direct observations, interpretations, assumptions and decisions distinguishable throughout synthesis.

For each evidence unit, retain a stable source reference, the relevant span or query result, source version, observation time, extraction time, access classification and the entity to which it refers. Keep the quoted span short; retain enough context to preserve negation and qualifications.

This is a proposed lineage model. The important relationship is not simply “cites,” but whether an observation supports, contradicts or limits the scope of a claim. A customer saying that a workflow is slow supports that customer’s experience; it does not establish how common the issue is.

claim_id: CL-017
kind: hypothesis
statement: Large directory groups may explain
  onboarding failures better than SCIM alone.
status: needs_discriminating_test
supports: [EV-102, QUERY-014]
contradicts: [EV-119]
unknowns: [non_scim_group_size_distribution]
source_versions: [support_export_v3, repo_commit_9d41a2]
review_owner: product_owner
# Illustrative contract; identifiers are examples.

When a source changes, mark dependent claims for review rather than silently rewriting a previously approved conclusion. An approved requirement retains its original evidence snapshot until an owner accepts an explicit revision. This makes it possible to answer a question that plain RAG usually leaves unresolved: which decisions need reconsideration because this fact changed?

2.8 Count customers, not messages

Five tickets, a CRM note and an interview excerpt can all describe one incident at one account. Treating them as seven independent confirmations inflates the apparent evidence. Resolve source lineage and account aliases before calculating prevalence.

Use a tenant-scoped pseudonymous account identifier and a separate incident or conversation identifier. Preserve uncertain matches for review; automatically merging two similar complaints can erase a real independent observation. Pseudonymization reduces unnecessary exposure but does not make the underlying data anonymous.

Define the unit and denominator first

Before an analytics tool runs, require the unit of analysis: user, account, onboarding attempt or event. Then fix the eligible population, date window, product version, success or failure definition, exclusions and treatment of retries.

For an account-level question, repeated events from a single account must not inflate the numerator. For an attempt-level operational question, retry behavior may matter and should be reported explicitly rather than removed indiscriminately.

Return the numerator and denominator alongside the rate, query identifier, execution time and data-completeness status. PostHog’s funnel documentation illustrates why metric semantics matter: step ordering, filters and conversion relative to the first or previous step change what the result means.

Keep commercial importance separate from prevalence

A strategic account may justify investigation even when the issue is rare. Store that commercial judgment separately; do not relabel an important customer as statistically representative. Likewise, an executive request is a decision input, not independent proof of user demand.

When sources are unavailable, distinguish no_matching_evidence, access_denied, source_unavailable and query_truncated. Only the first describes a completed search without a match. None establishes that the problem does not exist.

2.9 Separate confidence, coverage and decision readiness

One model-generated confidence number compresses several different questions: did retrieval find the relevant material, do the citations support the wording, is the sample broad enough, and is the proposed explanation causal? Record these separately.

Start with a reviewable status such as supported_observation, plausible_hypothesis, contradicted or insufficient_evidence. Numerical probabilities require a defined prediction target and calibration against appropriate labeled outcomes; a similarity score or a model’s self-rating is not a substitute.

Also distinguish authority from recency. A newly written draft is not automatically more authoritative than an approved policy. A newer observation can nevertheless contradict an old product assumption. Store lifecycle status and effective dates so that the agent can explain the conflict instead of choosing whichever document ranks first.

2.10 Ask the question that separates competing explanations

Consider the handbook’s onboarding example. SCIM is a standardized protocol for identity provisioning, but an association with SCIM-enabled accounts does not prove that SCIM causes the failures. Larger group sizes, directory-provider differences, a product release or incomplete telemetry are alternative explanations.

Make the next investigation explicit. The agent should propose the smallest authorized test that would distinguish the leading explanations, rather than generating more summaries of the same evidence.

This is an illustrative investigation plan, not measured findings. Observational comparisons can narrow an explanation; they do not automatically establish causality. A proposed production experiment still requires the relevant product, privacy and operational approvals.

Each test proposal should identify its owner, required access, decision-changing result and stopping condition. Stop with an explicit evidence gap when a key source is inaccessible, contradictions remain material or the authorized investigation budget is exhausted. “More research” is not an unlimited tool budget.

2.11 Hand off a requirement as a controlled artifact

The transition from research to delivery is where a persuasive but weakly supported statement can become expensive. Require a structured handoff with the selected hypothesis, accepted assumptions, rejected alternatives, affected users, scope boundaries and verification criteria.

requirement_id: DRAFT-017
status: proposed
selected_hypothesis: H3-revised
evidence_snapshot: discovery-run-017-v2
problem: Group-level failures are difficult to diagnose.
in_scope:
  - Actionable diagnostics for authorized admins
out_of_scope:
  - Replacing the identity provider
acceptance_criteria:
  - Failed operations expose an actionable reason.
  - Diagnostics do not reveal other tenants' data.
  - Existing successful flows remain unchanged.
open_decisions:
  - Supported provider and group-size coverage
approval:
  role: product_owner
  decision: pending
# Illustrative example, not an approved backlog item.

Do not invent performance thresholds or supported-platform commitments. A target belongs in a requirement only when its basis and owner are recorded; otherwise leave it as an open decision. The Planning & Architecture Agent receives the accepted package, not an unrestricted license to reinterpret the discovery narrative.

Make draft creation idempotent and bind approval to the version reviewed. If material evidence changes before creation, return the package for review. If the tool times out, reconcile the existing draft identifier before retrying. These are artifact-management controls, not instructions to the model to “be careful.”

2.12 Test whether the agent can disagree and abstain

Preserve the handbook’s hard tests and extend them with cases that reward a justified refusal to draw a conclusion. An agent that always produces a requirement may be less useful than one that accurately identifies what the team still needs to learn.

Evaluate source retrieval, claim support, contradiction handling, numerical reproducibility, access boundaries and draft state separately. For subjective synthesis, use a written rubric and independent product or engineering review. Anthropic’s agent-evaluation guidance recommends combining grading methods and distinguishing the agent’s transcript from the outcome actually produced.

Split evaluation examples by account, underlying incident and time where appropriate. Near-duplicate tickets in development and evaluation sets can make retrieval and synthesis look stronger than they are. Version the corpus, prompts, tool schemas and model deployment; repeat ambiguous tasks to expose inconsistent behavior.

Measure time to a reviewable decision package, reviewer corrections, unsupported consequential claims and the cost of a reviewed package. Report abstentions with their reasons. Acceptance by a reviewer does not prove commercial success, and none of these measures should be marketed as realized ROI without deployment evidence.

Implementation Blueprint: Evidence Before Requirements

Recommended MCP surface

Enforce access in the retrieval and tool services. Source material is untrusted data, not a way to change permissions. MCP’s security guidance addresses authorization hazards such as token passthrough; a shared interface does not eliminate downstream authorization responsibilities.

RAG record

{
  "source_type": "prd|interview|support|decision",
  "source_uri": "...",
  "source_version": "...",
  "effective_from": "2026-08-01",
  "product_version": "2026.08",
  "segment": "enterprise",
  "account_hash": "...",
  "classification": "confidential",
  "acl_principals": ["group:product"],
  "text": "..."
}

Redact or tokenize customer identifiers before embedding. Keep raw transcripts in their source systems. The handbook’s record is a minimal example; the ledger, lineage and metric contracts above are proposed production extensions.

Runtime instruction

ROLE: evidence-oriented discovery analyst.
For every material conclusion return:
  evidence_ids, contradictions, uncertainty,
  freshness and coverage limitations.
Do not infer prevalence from anecdotes.
Query the approved analytics tools.
Label every unsupported assumption.
Present competing hypotheses when evidence permits.
Create requirements only through the approved
versioned draft workflow.

Hard evaluation cases from the handbook

• Five duplicated tickets from one customer must not become five independent customers.
• A deprecated PRD must lose to a current versioned decision.
• If analytics access is unavailable, prevalence must be reported as unknown.
• Instructions embedded in interviews or tickets must not alter permissions or task purpose.

Source and shared prerequisites

Adapted from Article 2 and Blueprint 2 of the September 2026 Enterprise AI Agent Mesh handbook. The Enterprise Agent Platform Foundation guide provides the shared identity, MCP, retrieval, sandbox, audit and evaluation design. The engineering extensions on this page are proposed implementation choices, not claims of completed client work. Validate tool and model versions against the chosen deployment.

Explore the series

Previous: Enterprise Agent Platform Foundation

Next: Planning & Architecture Agent