Review: Build Simple Copilot Agents That Actually Help You Enjoy Your Job with Griffin Lickfeldt at the M365 Show

The most honest cold open: “Wait… we’re live”

The episode starts with a moment that feels like every real project kickoff: no grand intro, no polished “AI transformation” speech—just “Wait a second. We’re live.” That accidental authenticity becomes the through-line for the entire conversation: keep it real, keep it useful, keep it simple. Griffin Lickfeldt joins hosts Bülent Altinsoy, Isabelle, and Marcel to talk about building Copilot agents that genuinely reduce friction in a workday—rather than adding yet another tool nobody trusts.

That framing matters because agents are currently experiencing the same hype cycle chatbots did a few years ago. Everyone wants an “agent strategy,” and plenty of teams try to jump straight to the biggest, most impressive-sounding build. This episode pushes against that instinct. The promise isn’t “replace your job.” It’s “remove the parts of your job you wish didn’t exist.”

Griffin’s intro is also telling: he describes himself as a Microsoft MVP and a citizen developer who spends most of his time learning Copilot Studio by building—then sharing what works on YouTube and LinkedIn. The show leans into his reputation for being unusually prepared: structured questions, concrete demos, and a bias toward practical patterns rather than buzzwords.

There’s also a subtle but important tone-setting detail: when Griffin is asked whether the MVP award changed his life, he basically says “not really”—except now more people reach out for help, speaking, and guidance. In other words, as the agent era accelerates, being useful becomes its own kind of gravity.

The show’s title—Build Simple Copilot Agents That Actually Help You Enjoy Your Job—isn’t just marketing. It’s a clear design constraint. If your agent doesn’t make a real task easier, faster, less annoying, or less error-prone, then it’s not a win… it’s clutter.

“Agents have existed for decades” (and that’s the point)

One of the strongest parts of the conversation is Griffin’s attempt to de-mystify what an agent even is. His core claim is almost disarmingly plain: at a structural level, agents behave like automation systems. Inputs come in, some processing happens, outputs come out. If you’ve ever built Power Automate flows—trigger, conditions, actions, result—you already understand the “shape” of an agent.

What’s different is the kind of processing in the middle. Traditional automation is deterministic: the system follows exact steps. If something’s missing, it errors. Agents are probabilistic: they interpret, reason, and generate—often with natural language. That’s why they’re better at tasks where the output isn’t identical every time (drafting a summary, pulling insights from data, creating a tailored response).

To make that intuitive, Griffin uses a “calculator” analogy. A calculator is great at one job, but it has no memory or context. Agents, in contrast, can maintain conversational context, draw from knowledge, and operate inside the tools where people already work—Teams, Outlook, Word, Excel. The point isn’t that agents are magical. The point is that they’re a context-aware tool embedded in your workflow.

This perspective quietly prevents one of the most common failure modes: trying to build a “one agent to rule them all.” When you treat an agent like an all-knowing coworker, you start feeding it too many sources, too many permissions, too many responsibilities. That often reduces answer quality (more ambiguity), increases cost (more retrieval, more tokens, more tool calls), and makes governance harder (what exactly is this agent allowed to do?).

The practical takeaway: you don’t “add AI” to chaos and expect order. You take one messy, repetitive process and design an agent that improves it—with boundaries.

The Microsoft agent landscape: where each tool actually fits

A recurring theme on the show is confusion: Copilot Chat, Copilot (paid), Copilot Studio, Foundry… it can feel like a maze. Griffin gives a clean mental model: think of these as tiers based on customization, connectivity, and deployment.

Microsoft 365 Copilot Chat is positioned as a secure, enterprise-ready chat experience available with eligible Microsoft 365 plans, and Microsoft explicitly contrasts it with the “Copilot license” experience (which unlocks more work-focused capabilities). This tier is often where people start: quick experimentation, low barrier, and relatively tight guardrails.

Copilot Studio is where you go when you need to build agents that do more than chat—agents that can be published to channels and connected to knowledge sources and tools. Microsoft’s documentation is clear that publishing from Copilot Studio pushes updates across the channels associated with your agent, which is crucial for real lifecycle management.

Then there’s Agent 365, which answers a question the audience asked bluntly: “How do we avoid agent sprawl?” Microsoft describes Agent 365 as a control plane that helps IT monitor activity, enforce policies, resolve issues, and manage threats. In the Microsoft 365 admin center, the Agent 365 overview emphasizes adoption tracking, governance gaps, and centralized visibility. Related to that, Microsoft also documents an Agent Registry providing a centralized view of agents available in the organization—exactly the kind of inventory you need when teams build lots of agents across departments.

Finally, the pro-dev side of the spectrum (referenced in the episode) is where you want deeper orchestration, tighter controls, and production-grade engineering around agents and tools. Even if you’re not building there today, the key idea is: choose the platform based on the job, not based on hype.

This platform map aligns perfectly with the episode’s philosophy: don’t start at the most complex tier “because we’re serious.” Start where you can learn quickly and prove value safely.

The live build: HR Buddy and the real secret to “good” agents

The demo is intentionally simple: Griffin builds an “HR Buddy” agent in Copilot Studio that answers questions using three documents (onboarding checklist, employee handbook, employee FAQ). Why HR? Because HR is a perfect example of repetitive knowledge work: the same questions come up constantly, and employees waste time searching or asking. A well-grounded agent can offload that burden without becoming risky.

The steps he walks through are straightforward: create an agent, give it a name and description, choose a model, add instructions, then connect knowledge sources. The crucial part isn’t the UI clicks; it’s the design discipline behind them—especially the focus on instructions (how the agent should behave) and knowledge (what it’s allowed to ground answers in).

Microsoft’s Copilot Studio documentation explains that knowledge sources work with generative answers so agents can use enterprise data, websites, and external systems. This is the backbone of the HR Buddy pattern: let the agent retrieve, then summarize into an answer.

A small but powerful tactic Griffin calls out: describe your knowledge sources so the agent knows when to use them. This is a major quality lever. If you upload multiple files and don’t clarify their purpose, retrieval becomes noisier and the agent may pull from the wrong source. Think of it as labeling your shelves before you ask someone else to find the right book.

The show also touches on SharePoint as a knowledge source—including common frustrations. Microsoft explicitly notes that adding SharePoint sites or lists can create a real-time connection so the most current data is used, and users are authenticated using SharePoint credentials to ensure they have permission to access the data. That directly addresses two common concerns: “Will it stay updated?” and “Will it leak what users shouldn’t see?”

The larger message: reliability isn’t “AI luck.” Reliability is scope + grounding + clear behavior rules.

Prompts, instructions, and why “more words” can be a feature

There’s a funny moment when the hosts tease Griffin for “forgetting the question” (after a quick plug), but the conversation that follows is one of the most practically useful segments: why many prompts fail and how to fix them.

Griffin pushes back on the overly fancy term “prompt engineering,” but he still gives a workable structure. The best prompts provide:

• Context (who you are, what you’re doing, constraints)
• Goal (the specific task you want done)
• Sources (where it should look—documents, SharePoint, data)
• Expectations (format, tone, length, structure, output type)

This is exactly the difference between “make me a policy summary” and “write a 7-bullet summary of the PTO policy from the Employee Handbook, using plain language, and include any exceptions.” One is vague. The other is testable.

He also mentions “few-shot prompting” (providing examples of the output you want). Even without deep AI theory, this is a practical trick: if you show the agent the structure you like—headings, bullet style, tone—it will often mirror it more consistently.

One line in this segment is worth repeating as a mindset, not literal advice: if your quality is poor, add clarity, and clarity often means adding words. Not rambling—adding the missing constraints that turn “guessing” into “following directions.”

For agent builders, this matters even more than end-user prompting, because instructions are your agent’s behavioral contract. Weak instructions produce unpredictable agents. Strong instructions produce boring-but-useful agents—and boring is often exactly what enterprises need.

Governance, sprawl, and the multi-agent pattern that keeps things sane

Audience questions pull the conversation into the real enterprise concerns: sprawl, lifecycle, trust, and whether agents “evolve” on their own.

On sprawl, the strongest answer is: you need visibility and guardrails. Microsoft’s Agent 365 pages position it as a control plane with monitoring, policy enforcement, issue resolution, and threat management. Meanwhile, the Agent Registry gives admins centralized discovery of agents in the tenant. Together, they point to the direction Microsoft is taking: agents are becoming manageable entities like apps and users.

On lifecycle, the episode reinforces a practical point: connecting knowledge to SharePoint can help keep information current (because the agent retrieves from the source), while uploading static files may require republishing when content changes. Microsoft’s SharePoint knowledge guidance explicitly emphasizes real-time connection and permission-aware access for SharePoint lists/sites.

On “parent vs child agents,” the show arrives at a pattern that’s quietly the core of scalable agent design: specialize. If you have multiple HR agents (onboarding, PTO, expense policies, benefits), a parent orchestration agent can route queries to the best specialist rather than one mega-agent trying to do everything. This aligns with broader agent architecture thinking: smaller scopes reduce ambiguity, improve retrieval precision, lower cost, and make testing easier.

Then the MCP question lands: should MCP replace connectors and flows? The episode treats this with appropriate caution. Microsoft’s Dataverse MCP documentation explains MCP as an open protocol enabling integration between LLM applications and external data sources/tools, and that Dataverse can act as an MCP server for clients like Copilot Studio agents. But the key trade-off discussed is still valid: deterministic actions (create/update/delete mission-critical records) often belong in workflows/flows, while MCP shines in natural-language exploration and reasoning over data.

If you want a modern, maker-friendly comparison, Microsoft’s own community guidance recently published a practical guide on choosing between MCP servers and Power Platform connectors in Copilot Studio.

Finally, the “Do agents build new capabilities by themselves?” question gets a clear answer: no. Agents can only use the tools, knowledge, and permissions you give them. They don’t spontaneously expand their access. That reassurance is central to enterprise trust—and consistent with the permission-aware framing in Microsoft’s knowledge-source guidance.

The outro song is the whole strategy (disguised as a vibe)

The episode ends with a music segment that’s essentially an implementation guide in lyrics: coffee rings, cluttered desk, manual updates, and endless “status” cycles. Then the refrain: build simple agents, start with one small workflow, fix the thing that drains you every week, and let small improvements stack until work feels lighter.

That’s the real blueprint:

• Don’t pitch a massive transformation.
• Don’t start with the hardest system.
• Don’t make the agent smarter than it needs to be.
• Start where the pain is consistent and measurable.

The song’s best hidden line is basically a product requirement: “No big transformation pitch. No endless roadmap stitched. Just one solution tight and clear.” The show makes the same point in technical terms: focused scope improves reliability, governance, cost, and adoption.

And it’s worth emphasizing: adoption follows trust. Trust follows consistency. Consistency follows good boundaries and good grounding.

Source: Review: Build Simple Copilot Agents That Actually Help You Enjoy Your Job with Griffin Lickfeldt at the M365 Show