From Rigid Flows to Adaptive Agent Design

A common pattern I see when people start building in Copilot Studio is the urge to carve the agent up into very narrow, task-specific topics. You’ll often see separate topics for things like “Summarise this document”, “Look up a policy”, and “Compare two options”. On paper, this feels sensible: each topic has a clear purpose, a defined input, and a predictable output.

That instinct isn’t wrong. In fact, clear delineation of roles and responsibilities is good agent design. It makes behaviour easier to reason about, simplifies governance, and reduces the risk of an agent going off-piste. Where this approach starts to fall apart is when role clarity becomes execution rigidity.

What you often end up with is an agent that behaves like a collection of one-shot utilities. You ask a question, it runs a single predefined action, and it returns an answer regardless of whether that answer is actually useful. The agent technically did what it was told, but it didn’t really work the problem.

The issue is that real work, especially knowledge work, rarely fits into a single clean step. Research, analysis, and even basic problem-solving are inherently iterative. Humans don’t just “search once and respond”; they plan, probe, sanity-check, adjust scope, and ask clarifying questions when something doesn’t line up. If your agent can’t do those things, it will always feel shallow, no matter how many topics you add.

This is where it’s useful to separate two concepts that often get conflated: an agent’s role and the process it follows.

An agent’s role should be clear and stable. A research agent researches. A triage agent assesses and routes. A drafting agent produces structured outputs. That clarity is valuable and worth preserving. What should be far more flexible is how the agent executes that role. Over-prescribing process, especially via rigid topic flows, locks the agent into a narrow interpretation of the task and removes its ability to adapt when the situation is messy, incomplete, or unexpected.

This tension shows up very clearly in prompting styles. You can be extremely prescriptive, spelling out every step the agent must follow in order. That works well for deterministic processes where deviation is risky or undesirable. But for most exploratory or judgment-heavy tasks, I’ve found it more effective to anchor the agent around a goal and scope, describe the skills and tools it has available, and only introduce explicit process steps where additional guardrails are genuinely needed.

In practice, that means telling the agent what success looks like, what constraints it must respect, and what capabilities it can draw on - then letting it decide how best to get there. If the scenario is odd, ambiguous, or doesn’t quite match expectations, the agent still has room to manoeuvre. It may not always reach the perfect answer, but it can usually get closer rather than failing outright.

# Goal
You will be tasked to research a topic from the user. 
Your thinking should be thorough and so it's fine if it's very long. You can think step by step before and after each action you decide to take.
You MUST iterate and keep going until the research question has been answered.
Go through the question step by step, and make sure to verify that your research is correct. 
When you say you are going to make a tool call, make sure you ACTUALLY make the tool call, instead of ending your turn.

Take your time and think through every step - remember to check your research rigorously and watch out for incorrect information. Your research must be perfect. If not, continue working on it. At the end, you must test your response to the question rigorously using the tools provided, and do it many times, to catch all edge cases. If it is not robust, iterate more and make it perfect. Failing to test your answer sufficiently rigorously is the NUMBER ONE failure mode on these types of tasks; make sure you handle all edge cases, and run existing tests if they are provided.

You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully.

# Process
High-Level Research Strategy
- Use 'Ask User Question' to ask questions to the user to fully understand the question you have been asked. Carefully think critically about what is required.
- Parse the research into a brief with topics, constraints, deliverables, and non-goals. Understand what 'done' looks like. 
- Develop a clear, step-by-step plan for the series of questions you need to answer for each area: definitional, comparative, evaluative, factual, numeric.
- Use 'Search the Web' to carry out your research. Complete a fan-out series of queries, ensuring multiple appropriate channels are used: general web, academic, standards bodies, government, company docs, code repos.
- Reason over the knowledge you have gathered, understanding if the evidence actually supports the claim, and if it helps answer the original question.
- Extract and save any relevant knowledge and information you need to complete your research for context later. 
- Reason over the knowledge you have gathered, understanding if the evidence actually supports the claim, and if it helps answer the original question.
- Write and verify a draft response with an adversarial pass, this should aim to break the draft: missing counter-evidence, outdated sources, cherry-picking.
- Use 'Search the Web' to re-search targeted queries for the weak spots (loop back to 3–7 as needed).
- Gather a comprehensive list of all the sources you have used to add to citations.
- Iterate with the user: Show the brief, plan, and current gaps; ask one or two high-leverage clarifying questions with 'Ask User Question'.
- Deliverables: final narrative/research, current gaps, and evidence table. 


# Skills
- Use 'Ask User Question' to ask the user a specific question given an intent. For example if the user asks a very broad research topic to be explored, use 'Ask User Question' to understasnd it more. If you complete some of your research and you want to ask the user for more context around where to go next, use 'Ask User Question' to get this info. 
- Use 'Search the Web' to search the internet for research and knowledge. 

This philosophy is what sits behind what I tend to think of as a generalist agent pattern. Not a vague or unfocused agent, but one with a clearly defined role and deliberately broad tools. Instead of dozens of narrowly scoped topics, you give the agent a small number of versatile capabilities - things like searching, retrieving internal knowledge, or asking the user for clarification - and rely on instructions to shape how those capabilities are used.

The behaviour you’re aiming for is not a straight line from input to output, but a loop: understand the question, form a plan, gather information, check whether the answer holds up, and pause to ask for clarification if the brief is too thin. That loop is much closer to how a competent human colleague would approach the same task, and it’s what allows the agent to handle vague prompts without immediately producing nonsense.

Crucially, this approach scales far better over time. Today, a search tool might point at the public web. Tomorrow, it might include SharePoint, Dataverse, internal documentation, or ticketing systems. The agent’s role doesn’t need to change, and neither does its reasoning model. You’re simply giving it better hands. Because the intelligence lives in the instructions and the goal definition rather than the topic flow, you can extend its reach without constantly re-engineering its behaviour.

The end result is an agent that feels less like a scripted interface and more like a collaborator. Clear in what it’s responsible for, but adaptable in how it achieves that responsibility. In my experience, that balance - strong role boundaries paired with flexible execution - is what separates agents that look good in demos from agents that actually hold up in real use.