Discovery before build: how to decide whether a Copilot Studio agent deserves investment
Most organisations do not struggle to build an agent. They struggle to decide whether the idea is worth pursuing, what the agent should do, and how it will fit into the way people work.
Those are difficult decisions because AI introduces uncertainty earlier than traditional software projects. Getting them wrong can lead to months of effort spent solving the wrong problem.
This article describes how we approach discovery in a way that reduces that uncertainty via our AI Design Sprint framework. You'll see how to identify the right stakeholders, test ideas before making large commitments, and gather the evidence needed to make a confident decision about what to do next. We've also documented this approach in our AI Design Sprint explorer, an interactive guide that walks through the discovery activities, workshops, outputs and decision points in more detail. If you're interested in the practical framework behind the ideas discussed in this article, it's a useful place to explore further.
Dani Kahil and I recently joined Rafsan Huseynov and David Lorenzo Lopez to discuss the AI Design Sprint and how we run discovery for Copilot Studio projects. See the video on YouTube or read on for a quick summary.
Discovery should help you make a clear decision
Traditional discovery for business solutions can become focused on documenting requirements for a project that everyone assumes will proceed. And that has worked for us in the past was we know how to define an app or automation up front and what the outcomes will be.
However, AI comes with a lot of uncertainty and it needs an earlier decision point. Is this agent use case something that will help our people? Is Copilot Studio the right platform? Does the expected value justify the cost and operating effort? What would cause us to proceed, change direction or stop?
For a sponsor, that changes the purpose of discovery. The work should provide enough evidence to make the next commitment with more confidence. A stop decision can be a good outcome if it prevents months of investment in the wrong solution.
Microsoft's Copilot Studio implementation guidance starts with planning. It asks teams to define the vision, scope, success measures, risks, roles and technical readiness before building.
Include everyone in the conversation
Agent projects cross organisational boundaries quickly. The business owns the outcome. Users understand the work. IT and security understand the platform and risk. Data owners understand the knowledge. Someone also needs to own the agent after it goes live.
Those people need to work together during discovery.
In our conversation, Dani described clients realising part-way through a workshop that their own teams were not aligned. I have seen projects reach production before an overlooked stakeholder group was invited to review the output. By then, the cost of correcting the direction is much higher.
A stakeholder map is a practical starting point. Identify the sponsor, subject matter experts, end users, customers, IT, security, compliance, data owners and the people who will build and operate the agent. Then check who is missing.
Show what is possible before asking for ideas
Many stakeholders can describe what an application or workflow might do. Agents are less familiar. Asking a group to brainstorm AI use cases without first building some shared understanding often produces vague ideas or a long automation wish list.
We normally show relevant examples early. The examples should use the client's language, process and context wherever possible. This helps people understand what AI can do, where it is unreliable, and where a simpler appl or flow may be the better option.
This helps frame a wider, and potentially more impactful question rather than asking what can be automated.:
How might we create more value for the people we serve?
It can still identify efficiency opportunities, but it also helps teams consider quality, consistency, access to information, personalisation and services that were previously impractical.
Scope the agent around the flow of work
An agent needs to fit where people already work.
I share an example in the video where users worked mainly in Dynamics 365. An earlier chat-based agent required them to copy and paste its output back into Dynamics. Adoption failed.
We redesigned the same underlying idea so the agent worked behind the scenes. It responded to a change in Dynamics, drafted an email and placed that draft on the record timeline for a person to review. The agent supported the existing work instead of creating another place to work.
The scope discussion should cover:
the human outcome and the agent's role in achieving it
the knowledge the agent needs and who owns it
the tools, actions and systems it can use
the decisions that remain with people
security, privacy, compliance and cost controls
how performance will be measured
who will monitor, maintain and improve the agent
Microsoft's structured agent design framework covers the same practical ground: user outcomes, system context, human responsibilities, data dependencies, governance needs and evaluation criteria.
Build early to learn
A document cannot show how an agent will behave in a real conversation or process.
We build a prototype during discovery so stakeholders can interact with the idea, challenge assumptions and see where the boundaries need to be clearer. The prototype can be narrow. Its job is to test the parts that carry the most uncertainty.
Early prototypes can also help teams better understand operational costs before a wider rollout. Questions about Copilot credit consumption and agent costs are becoming more common as organisations move from experimentation to production and as the pay-per-use pricing models are emerging. A narrow prototype provides an opportunity to observe real usage patterns, estimate likely consumption and decide whether the expected value justifies the ongoing investment.
This is where a short AI design sprint is useful. The process moves from business context and challenge definition through ideation, design, build and test, then finishes with a decision and a practical road to production.
The scope is deliberately bounded. A small working outcome gives the team something concrete to assess without pretending it is already production-ready.
Define success and operating ownership before build
An agent can work technically and still fail to create value.
Define expected business value and agent performance measures during discovery. For example, a customer enquiry agent might aim to reduce response effort, but in order to do that it also needs to produce an agreed level of response accuracy.
Governance also needs to enter the conversation early. Microsoft's Copilot Studio security and governance guidance covers controls for data policies, authentication, agent actions, monitoring, audit, usage visibility and credit management. These are design inputs, not tasks to leave until deployment.
The same applies to ownership. An agent is a bit like a new staff member. Someone needs to supervise it, review performance, update its knowledge and respond when its behaviour changes.
Effective agent design is grounded in principles that keep users safe, respected, and in control. Responsible AI needs to be part of the conversation early so that the agent design is transparent, fair, and worthy of user trust.
Carry discovery knowledge into delivery
Discovery activities can produce a lot of useful information in transcripts, workshop boards, documents, decisions, requirements, risks and open questions. Much of that context can disappear during the handover to a separate build team.
Our preferred approach is to involve the build team in discovery.
When that is not practical, we maintain a structured project knowledge base, through an AI system called Grounded Delivery, that both people and AI can read. Each workshop adds to the same current view of the business context, personas, processes, requirements, risks and decisions.
AI can help turn messy source material into that structure. People still review and approve the updates. The benefit is a clearer record of what is currently understood, what changed and what remains unanswered.
After discovery, the build team receives more than a document pack. They receive the working context behind the decisions and, where possible, a prototype they can start with and evolve.
Start with the decision you need to make
Before booking discovery workshops, write down the decision the organisation needs to make.
Then design the discovery around the evidence needed for that decision:
Define the business problem and the people affected.
Bring the required business, technology, data and operational stakeholders together.
Show relevant AI capabilities and limitations.
Choose a narrow use case based on value, effort and fit.
Build enough to test the assumptions that matter.
Agree success measures, guardrails and operating ownership.
Decide whether to proceed, refine the idea, run a further proof of concept or stop.
If you are planning a Copilot Studio project, the AI Design Sprint explorer shows the approach Dani and I are developing. The recorded session goes into the examples, demos and lessons behind.
FAQ
Q: What is Copilot Studio discovery?
A: Copilot Studio discovery is a structured process for defining the business problem, users, agent role, knowledge, actions, guardrails and success measures before a larger build. It should give the organisation enough evidence to decide whether to proceed.
Q: How do you scope a Copilot Studio agent?
A: Start with the human outcome and where the agent fits into the flow of work. Then define its knowledge, tools, actions, boundaries, evaluation criteria, security controls, cost controls and operating owner.
Q: When is Copilot Studio a good fit?
A: Copilot Studio can be a good fit when work requires finding and interpreting information, handling ambiguity, using several knowledge sources or helping a person make a judgement. A deterministic application or flow may be more suitable when the process is governed entirely by fixed rules.
Q: What should an AI discovery produce?
A: A useful AI discovery should produce a shared understanding of the opportunity, a narrow working prototype, agreed success measures, identified risks and a decision about the next step.
Q: Why build a prototype during discovery?
A: A prototype lets stakeholders test behaviour that a written specification cannot show. It helps the team find weak assumptions, clarify boundaries and gather evidence before committing to production delivery.
Note of the use of AI
The thinking in this post is mine.
I used Microsoft Copilot Cowork and a blog-writing skill to turn my notes and working documents into a first draft. From there, I edited, rewrote, and refined it into the version you're reading.
Everything here comes from my own work and experience. If I've made a mistake, that's on me, not AI.
Comments