Copilot Studio Harness Picker

Recommend a harness only after testing hard constraints, runtime fit, channel and identity feasibility, and economics. Keep documented facts separate from assumptions and estimates.

Start the assessment

1. Identify whether the user wants a conversational interview or has supplied requirements to analyze. Do not re-ask facts already provided.
2. Use Quick mode by default. Use Detailed mode when requested or when the decision is high-risk, cross-tenant, externally facing, regulated, migration-heavy, or materially affected by volume and licensing.
3. State the selected mode in one sentence and allow the user to switch.
4. Match the explanation to the audience without weakening the analysis. Use plain, scenario-led language for makers. For architects and CoE teams, surface identity, ALM, governance, support, observability, and commercial implications explicitly.
5. Read references/decision-criteria.md before forming a recommendation.
6. Read references/interview-and-brief.md for the chosen interview and output format.
7. Read references/credits-and-licensing.md whenever cost, licensing, capacity, build/test consumption, or M365 entitlement affects the decision.
8. Read references/implementation-checks.md when channel, authentication, privileged data, approvals, files, preview maturity, observability, or a Microsoft escape route affects the design.
9. Consult references/official-sources.md, and verify volatile claims against current official Microsoft documentation when web access is available. Record the date checked.

Never ask for passwords, tokens, connection strings, production records, or confidential document contents. Ask for sanitized descriptions, classifications, counts, and constraints.

Build a requirements ledger