Skip to main content

2. Creating Microsoft Copilot Agents

Note: The video covers material not in the guide below — please watch in full.

Resources

Reference material from this engagement.

Action Step

Complete this before moving on.

Watch the two Loom walkthroughs in the Resources box above — the first shows the access test (does the agent actually reach the CRM data) and the second shows the output QA (is what lands in the CRM actually good). Then make sure you can explain the full build path: build in Copilot Studio, publish, wire the flow in Power Automate, and decide whether it runs behind the scenes or in collab mode. If you have any questions, drop them in your onboarding channel.

Comment in Slack

Post your answer in your onboarding channel.

What was your biggest takeaway(s) from this training?


Training Guide

Now that you know the surfaces, here's how an agent actually gets built end to end — from the prompt in Copilot Studio to the flow running behind the scenes in Power Automate.


Start in Copilot Studio

Every new agent starts the same way: in Studio, go to Agents and create a blank agent. Starting from a template just gives you something to build off of.

This is also where you pick the model. You're not stuck on Microsoft's defaults — you'll see GPT-5 and 4.1, Opus 4.7 and 4.8 (marked experimental), plus Groq's and Mistral's models. Some may be disabled by the admin, but the option is there.


Write the Prompt with Claude

The agent's instructions are just a prompt, and the easiest way to build one is with Claude. You don't need to be a prompt-engineering expert — tell Claude "I want to build a prompt that does this," let it draft, and most of the QA happens in the back-and-forth as you test what the output looks like.

This is standard stuff if you've worked with agents, but it's exactly where you create value for a client who hasn't.


Connections Are the Hard Part

The genuinely tough part isn't the prompt — it's the connections. On this engagement (recorded June 2026), the real work was figuring out the Gong connection and the Salesforce connection in a way the customer's security team was comfortable with.

One rule that bites people: whenever you make a change, you have to publish it. Publishing is what pushes the change live so the flow behind the scenes actually picks it up.


Power Automate: Solutions and Flows

Once the agent is published in Copilot Studio, Power Automate gets the connection to execute it. The Copilot Studio side is the easy part — description, instructions, tools. Power Automate is where the automation lives.

A couple of pieces matter here. First, you create what Microsoft calls a solution — a container that houses your agents, flows, and related pieces (ours was just called "LeanScale Test"). Then you go to My flows, create the flow, and drop it into that solution.

Open question: It's not yet confirmed whether you can build flows without a solution. Claude said the solution was required, but someone with real Power Automate experience may know whether you can skip it and fall back to a default solution.

From there it works a lot like n8n or Zapier. You open the flow in Edit, set the trigger and the object it watches, add filter criteria, and attach it to the agent. Make a change, hit Publish, then have it update whatever record you need. Drop it into manual test mode to fire it. In our case, the trigger fired when a lead record moved to the working stage with a BDR or AE as the owner.


What You Can Build in the Flows

The flows are surprisingly flexible. You can have the agent send a message into a Microsoft Teams channel, output cards inside Teams DMs, program buttons, or open straight into Salesforce. We QA'd the Teams card route — the client ultimately chose not to use it — but the customizability is real.


QA: Access Tests and Output Tests

QA splits into two distinct tests, and both matter.

Output testing is about what actually lands in the CRM. The client set up an "agent confirmations" tab with fields the agent writes into (discovery call one, discovery call two). Everything written there is driven by the prompt, so QA is a loop: read the output, judge whether it's clear and the right length, feed that back into the prompt, and refine.

Access testing is sneakier. LLMs are smart enough to go find information publicly on the internet — so the CRM looks enriched, but a fine-tooth comb reveals the agent never actually read anything from inside the CRM, because it never had access. That's why the access test exists, and it's what took a week-plus of back-and-forth with the client's head of IT to nail down.

One nice detail: we added a pre-discovery research complete checkbox. When the flow updates a record, it flips that field to yes — so if the lead changes stages later, the agent knows it already ran and doesn't re-enrich. Belt-and-suspenders, but it keeps the automation from firing twice.


Behind the Scenes vs Collab Mode

That's really the whole decision. Build the agent in Copilot Studio, then choose how it runs:

  • Behind the scenes — use a Power Automate flow. The agent lives inside the flow and pushes its output to the CRM, Teams, or wherever you point it.
  • Collab mode — disperse it via Channels into Microsoft Teams, where the team chats with it directly. You manage sharing and permissions from there.

What We Haven't Touched Yet

This gets you over the hump, but there's a lot more in the ecosystem we haven't done the R&D on — connections, how sub-agents work, and how Microsoft Copilot as a harness compares to something like Claude Code or Codex. Next up for this client: building out the BDR messaging, qualify-and-develop, and proof-stage agents for pipeline hygiene across their sales stages.