FDE 1: Discovery

Discovery converts “we want agents to help with X” into a buildable, governable scope. Its output, the scope doc, gates everything downstream. A weak scope doc means a weak environment, noisy approvals, and a painful pilot. Slow down here to go fast later.

The discovery interviews

Talk to three groups separately. They give different answers, and all three are load-bearing:

Group	You learn	Ask
Work owners (service leads, queue owners)	What good looks like, what “done” means per case	Walk me through the last three cases end to end. Where does it stall? What must never happen?
Operators-to-be	Who decides, what is risky, current escalation paths	Which actions need a second pair of eyes today? Who owns that call at 2am?
System owners	What is reachable, credential holders, constraints	Which systems hold the truth? Who holds the credentials? What is read-only in practice?

The five discovery questions

1. Workload: what recurring multi-step work should agents do? (Name 2 to 3 concrete case types, not “everything in the queue.”)
2. Systems: which applications hold the context and where do actions land? (Name them. “The usual tools” is not an answer.)
3. Risk: which actions are irreversible, customer-visible, or cross-system? (This pre-designs the approval matrix.)
4. People: who approves, who operates, who administers? (Names and roles. See Roles.)
5. Connectors: which systems need connections that are not live for this tenant? (Requests, not promises. Code is not connected. Ground reality: registered adapters are HubSpot and ConnectWise PSA; Salesforce scaffolds are not implementations; outbound HubSpot writes are disabled.)

The scope doc

One page per workload. Template:

Workload: <name>
Org scope: <org_id context, whose work>
In scope, systems: <explicit list>
In scope, data: <queues, groups, windows>
Out of scope: <explicit exclusions>
Read needs: <what agents must see>
Change needs: <what agents must do, draft vs execute>
Risky actions: <irreversible, visible, cross-system list>
Approver roles: <who decides, by role>
Connector gaps: <system and request status>
Success: <observable outcome for the pilot>

• Every system named, no “etc.”
• Exclusions written. The out-of-scope list is as important as the in-scope one.
• org_id context pinned, showing whose work the sessions act on
• Connector gaps filed as requests with the ops intake (R4)
• Work owners signed off: “yes, this is the work”

Red flags (stop and resolve)

• No one can name the approver, so approvals cannot be designed. Resolve before environment work.
• “Just connect everything, we will sort permissions later” is ungovernable by construction. Hold the line: scoped or nothing.
• Success unmeasurable, so the pilot cannot prove value. Define the observable outcome now.
• Connector gaps treated as done. Reset expectations immediately (code is not connected).

Next: Environment turns this doc into a scoped, verified workspace.