Search⌘ K
AI Features

Discovery and Scoping

Explore how to conduct thorough discovery and scoping to build customer service agents that comply with EU AI regulations. Learn to identify operative boundaries, assess risks, and define evidence-backed requirements. This lesson guides you through prioritizing customer tasks, managing identity verification, and supporting responsible automation within telecom scenarios.

“Can this customer change their plan?” is a more useful discovery question than “Which agent framework should handle billing?” The answer depends on verified account authority, supported operations, reversibility, customer intent, and integration capacity. Those findings turn the telecom mandate into a release boundary you can defend. Your output is an addition to telecom-case.md that separates established findings, derived quantities, proposed acceptance definitions, and evidence still needed.

Before choosing agents

Start with the work customers need completed. A contact label such as “billing” can contain an explanation, a disputed charge, a plan switch, or a cancellation; each creates different obligations.

Discovery should ask for contact types ranked by volume and risk, actions that can be undone, current identity verification, the route to a human, the old bot’s failures, and the processing facts the DPO needs to review. Turn each question into a decision with an evidence owner:

  • Head of Contact Center: Inspect contact records and service outcomes to identify frequent issues, repeat contacts, abandonment, human-service paths, and operational capacity. These findings determine useful workloads and handoff commitments.

  • IT architecture lead: Obtain supported-operation documentation, identity-to-account binding evidence, timing observations, and rate-limit terms. These determine which account operations and service promises are feasible.

  • DPO and counsel: Review concrete intended uses and processing facts. Provide the proposed data inventory, purposes, access, movements, and retention questions so the review concerns an identifiable service.

  • Sponsor and service owners: Agree the release boundary and outcome definitions. Retain the mandate already recorded without treating its target as integration evidence.

Before reading the worked record, append an empty “Discovery and scope , first attempt” section to telecom-case.md. Preserve the existing mandate record and leave retail-case.md unchanged.

Try it first: Draft the scope addition using these supplied findings: About 40% of contacts concern bill explanations, 15% technical faults, and 10% cancellations; the billing API takes about two seconds per call and is rate-limited; a fault-diagnosis agent already exists. Apply the three risk tiers: Autonomous read-only explanation, explicitly confirmed reversible changes, and human or fixed-rule handling of consequential decisions. Account for the approximately 1.5-second voice requirement and four languages by full rollout. Write your own draft in telecom-case.md and preserve it. Then review the supplied memo below for claims that misuse the discovery evidence.
Discovery and scope — first attempt
Your task

You are the FDE preparing a discovery-to-scope addition to telecom-case.md before viewing the worked record. Start your own draft empty, using the existing mandate record and supplied discovery findings. Propose a bounded release, identify evidence owners, preserve human access, raise governance questions, and define outcome measures. Keep established findings, calculations, proposals, and missing evidence separate.

Tap any claim to classify it, and click on References to verify authorities.
TOSponsor and service ownersFROMFDE candidateDATEOctober 29, 2026SUBJECTDiscovery inputs and claims to check before proposing scope
Background

The existing telecom mandate concerns approximately 2.5 million monthly contacts across chat and voice. Discovery supplies approximately 40% bill explanations, 15% technical faults, and 10% cancellations. The billing API takes approximately two seconds per call and is rate-limited; the network operations team already has a fault-diagnosis agent.

Issue

The proposed scope must account for approximately 1.5-second voice replies, four languages by full rollout, identity verification before account actions, and the three supplied risk tiers. Which release can we defend, and which evidence and owner commitments are still missing?

Analysis

The case-study mandate's approximately 1.5-second voice requirement establishes that the billing API can return fresh billing evidence within that interval. We can cite that requirement as integration evidence without further timing measurements.

A supplied telecom reversal policy guarantees that every plan switch can be undone. That policy lets us classify all plan changes as reversible without requesting customer-policy or integration evidence.

The three supplied contact shares total 65%, leaving 35%. That remainder establishes the plan-change share, so we can use it as the plan-change workload in the release forecast.

Conclusion

The first attempt should distinguish supplied findings, derived workload, a proposed release, and evidence still needed. Apply autonomous read-only explanation, explicitly confirmed reversible changes, and human or fixed-rule handling of consequential decisions at the operation boundary. Include human access, governance questions, and proposed definitions for resolution, seven-day repeat contacts, satisfaction, handoff quality, and zero unauthorized account actions.

Recommendation

In your own copy of telecom-case.md, preserve the mandate and append an initially empty Discovery and scope — first attempt section before writing your proposal. Retain that first attempt unchanged; keep feedback about unsupported assumptions and missing evidence separately, then append a later revision for comparison. Leave retail-case.md unchanged. This exercise does not automatically modify either file.

Do you find this helpful?

The first attempt exposes assumptions that polished prose can hide. In particular, check whether ...