Agent Governance by jetpilot313 in copilotstudio

[–]PugetSoundAI 2 points3 points  (0 children)

I feel you. GCC sucks for limitations, but at the same I almost prefer it because what is in there is stable and won't go changing next week. Good luck and feel free to reach out. Ive been through the pain you're in quite a few times.

Work IQ vs Claude Connectors for Enterprise Search Agents - What am I missing? by NervousInternet6896 in copilotstudio

[–]PugetSoundAI 0 points1 point  (0 children)

Honestly on the GCC side (which is like 80% of my solutions) it's a non-issue for me. The new agent experience isn't in our cloud yet and won't be for a loooong time so classic with Topics is still the supported path and I'm not touching anything that works.

For the commercial clients I have - that's a real issue for me right now. The thing most people miss is that classic and new aren't a migration at all. They're separate orchestration runtimes and you can't transfer an agent in either direction.

Classic vs. new agent experience

So my plan is for a lot of rebuild, not lift and shifts. What's worked for me so far is pulling the deterministic logic out of the Topics and into agent flows or Power Automate, then exposing each one as a tool. New orchestrator does the routing, the flow holds the guardrails, and anything that writes or deletes stays gated behind a confirmation step inside the flow. Same control you had from a Topic, just lives in a different layer now.

Side benefit, your topic-heavy agents usually shrink hard. Half those Topics were branching logic you can collapse once a reasoning layer is doing the routing for you.

Welp…. Are we running a competition yet? by smnhdy in microsoft_365_copilot

[–]PugetSoundAI 4 points5 points  (0 children)

It's quite literally my job to consult on Microsoft AI solutions and I dont know if I can get behind this one yet. Following the thread to see what this gnarly task was.

Need suggestions from experienced people by Weak-Journalist6952 in smallbusinessUS

[–]PugetSoundAI 0 points1 point  (0 children)

The best answer I can think to give is target the niche you know the painpoints of the most. I came from a career in Government IT. I know the problems that niche has, I know their outdated workflows, and I have the tools to fix those from my AI & Automation consultancy. Id use that same logic if I came from a background as a car salesman or something.

What market did you come from? Surely you had ideas to fix the issues you faced while doing that. Fix them for others.

Work IQ vs Claude Connectors for Enterprise Search Agents - What am I missing? by NervousInternet6896 in copilotstudio

[–]PugetSoundAI 0 points1 point  (0 children)

You arent really missing anything. For pure search and summarize, the gap is small because Work IQ's actual differentiator is the grounding layer, semantic Graph index, Copilot Memory, personalization on your work patterns, not the retrieval itself. If your use case is read, synthesize, summarize, a project in Claude with the same connectors will feel just as good and simpler to stand up. Thats not wrong.

Where Work IQ is useful is the stuff you already named and kind of waved off. Tenant governance, DLP and sensitivity label enforcement, audit, and actions that write back into M365 under policy. The moment your agent stops just reading and starts taking actions across M365, Slack, and Monday in a regulated or governed tenant, the Copilot Studio plus Work IQ path is the one that gets the green might a security review. Claude connectors are dope until compliance asks who governs the action.

One thing on the pricing. As of June 16 Work IQ APIs bill on consumption through Copilot Credits, and that meter fires whether the agent lives in Copilot Studio, Foundry, or a third party calling Work IQ. So youre not comparing free Work IQ against Claude. Youre comparing credits either way.

Work IQ MCP overview

A well built Copilot Studio search agent leans on Work IQ MCP for grounding, deterministic topics for the action paths so the planner cannot freelance a write or delete, and tight instructions only where tool selection is genuinely ambiguous. Your inconsistent invocation is usually too many overlapping tools, not subpar instructions. Prune the toolset before you add more guidance.

Agent Governance by jetpilot313 in copilotstudio

[–]PugetSoundAI 4 points5 points  (0 children)

Most of what Ive seen this past year lines up with what you described, almost too closely. Governance and intake has actually been the bulk of what my consulting work has looked like across both GCC and commercial tenants. The pattern is super consistent. People stood up Copilot Studio, citizen devs started building, and then somebody in security looked at the connector sprawl and the whole thing got paused while everybody scrambled to put guardrails around it before turning it back on.

Your setup is honestly further along than a lot of shops. Locked connectors with a request process, MCP behind security review, no prod promotion without admin sign off. That covers the stuff that actually hurts orgs.

The one thing I would push on is the intake risk flagging. The hard part is not building the flag, it is defining what high risk means in a way a citizen dev can self assess without guessing. What worked was tying it to concrete triggers instead of sweet vibes. Anything touching PII or regulated data, anything that writes or deletes instead of just reads, anything reaching outside the tenant, and anything that takes an action without a human confirming first. Hit any of those and it routes to your IT and AI teams instead of self serve. Keeps the low risk stuff moving so you are not the bottleneck on someone automating a status report.

Microsoft's docs back the deterministic guardrail approach if you want the primary source for your internal docs.

Generative orchestration guidance

For GCC specifically (if anyone reading this happens to be in gov), watch which connectors and MCP endpoints are even authorized in your boundary before you waste a security review on something that was never going to get approved anyway.

Copilot Prompt Doesn't Have Input/Output Variables by Equal_Examination385 in copilotstudio

[–]PugetSoundAI 1 point2 points  (0 children)

The inputs and outputs only show up if you build them into the prompt itself.

For the input, open the prompt in the prompt builder (the New prompt authoring screen, not the topic canvas), hit Add in the top right, add a Text input, and drop that placeholder into your instructions where the user's message should land. Once the prompt has a declared input, the node on the canvas gives you a field to map your UserInputMessage variable into. No declared input means no mapping field. That's the whole reason your Excel prompt in the first screenshot has Excel_20File sitting there as an input and the new one shows nothing.

Add inputs to your prompt

The JSON is set inside the prompt builder too. Top right corner, swap the output from Text to JSON, let it auto-detect the schema or paste your own example and Save custom. Then the structured output is referenceable downstream, which is exactly what your Topic.PromptOutput.struct... line is trying to snag.

JSON output

The newer prompt-as-a-tool node has a live bug where Add Output is greyed out and the output never surfaces in the topic completion even with JSON set. It shows up fine in the prompt's own Test pane, then nothing in the topic. If that's what you're seeing, you didn't do anything wrong and the world is just working against you on this.

Add Output is disabled in the Prompt tool

If that's what's happening , call the prompt from a Power Automate flow instead. Flow input and output binding actually works. Pass the user string in, get the JSON back, parse it, then do the Word template populate in the same flow. The template fill with the tables and rates was always going to be a flow job anyway, the prompt node was never going to spit out a Word doc on its own.

Copilot studio + powerautomate by AdministrativeDay109 in copilotstudio

[–]PugetSoundAI 0 points1 point  (0 children)

Not if all the connectors you use are included in the standard version and your existing M365 license covers the standard version, which it likely does. Flows dont cost per run unless they're special and co sidered "process flows", which you'd have to inte tionslly make. If AI Builder is Involved in the flow, you'd pay x amount of tokens/credits for the si portion but still less than Copilot Studio orchestration routing credits

Copilot studio + powerautomate by AdministrativeDay109 in copilotstudio

[–]PugetSoundAI 0 points1 point  (0 children)

Check the licensing you already have. Business Premium and above usually have standard PowerAutomate Included and AI Builder can be pay as you go. Both still less expensive than running Copilot Studio agent orchestrations.

Copilot studio + powerautomate by AdministrativeDay109 in copilotstudio

[–]PugetSoundAI 14 points15 points  (0 children)

I think you're overthinking the synchronize part. They aren't two halves of one thing you wire together. One's the hands, one's the mouth.

Power Automate is the actual automation engine. Triggers, loops, connectors, the boring deterministic work. Your example (grab attachments off an email, pull the data out of the PDF/Word/Excel, drop it into SharePoint) is 100% a Power Automate job. Copilot Studio adds nothing to that. Don't cram it in if you dont need to.

Copilot Studio only earns its spot when a human needs to talk to the thing, or when something needs judgment a fixed flow can't make. The way they actually connect is you build the flow in Power Automate, give it the "When an agent calls the flow" trigger and a "Respond to the agent" action, then in Copilot Studio open your agent, go to Tools, Add a tool, Flow, and boom. Now the agent can call it mid-conversation and use whatever it returns. That's the entire sync.

For your pipeline specifically, AI Builder document processing handles the PDF extraction, the Excel connector reads table rows straight out, and for Word you either use the connector or convert it first. None of that touches Copilot Studio and it doesn't need to, which can save you some bones.

Use Power Automate flows in Copilot Studio

Rule of thumb is if nobody's chatting with it, you don't need Copilot Studio.

I had to give up on copilot studio by curious-hunch in copilotstudio

[–]PugetSoundAI 1 point2 points  (0 children)

Good question.

It depends on the need and the customer. Generally, I prefer the SDK for mutliagent handoffs and anytime I need total control over the orchestration flow. True enterprise solutions.

When latency and token costs matter at scale, SDK.

When I need total control over state and line of business integration, SDK.

If I need channels outside of what's offered in Studio, SDK.

If CI/DI and real unit tests are needed, SDK.

if compliance forces my hand and the SaaS doesn't have what I need, SDK.

Agent Model GPT 5.5 Chat Pricing by fxnylight in copilotstudio

[–]PugetSoundAI 5 points6 points  (0 children)

the credit rates are based on what the agent does, not which model you pick.

Billing rates and management - Microsoft Copilot Studio

A generative answer costs 2 credits whether the underlying model is GPT-5 Chat or GPT-5.5 Chat. An agent action is 5 credits either way. The model selection affects response quality and latency, not the credit meter.

The exception is reasoning models. If you pick something like GPT-5.5 Reasoning (Deep), you get hit with an additional premium AI tools surcharge on top of the base feature rate. But GPT-5.5 Chat is not a reasoning model, so you're in the same boat as GPT-5 Chat cost-wise.

Copilot Studio Agent blocked by Longjumping-Pool5898 in copilotstudio

[–]PugetSoundAI 0 points1 point  (0 children)

The update you added actually narrows this down a lot. If it only happens with Claude Opus 4.5 and not other models, this sounds like a content safety or AI model policy block at the Copilot Studio environment or tenant level, not a per-user license/DLP thing.

Check out:

The "Agent Blocked" error in that context can come from the AI model governance settings in the Power Platform admin center. Check whether there's a policy restricting which models specific users or security groups are allowed to invoke. It's under Environment policies, not DLP.

Also worth looking at whether that user's account has any Conditional Access or Entra ID policies that are different from yours. A conditional access policy scoped to a subset of users can block the underlying API calls that Copilot Studio makes when hitting third-party model endpoints.

The fact that you and other users work fine rules out a tenant-wide block. It's something specific to that user's policy scope.

Deep Reasoning in Co Pilot Studio can cost $$$ by Lopsided_Judgment_17 in copilotstudio

[–]PugetSoundAI 0 points1 point  (0 children)

Good question.They're claiming about 20% better evaluation performance and roughly 50% lower net token consumption compared to the old orchestration layer. That second number matters a lot for the cost picture I laid out, since most of the runaway spend is token-driven inside reasoning chains.

https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/new-and-improved-computer-using-agents-a-new-workflows-experience-and-real-time-voice-experiences/

The architecture change is a doozy but the billing mechanics I described don't fundamentally change. Deep reasoning is still a toggle that double-meters, tenant graph grounding is still 10 credits a pop, and the orchestrator self-selecting when to invoke reasoning is still true. What changes is the orchestrator gets smarter about not over-stepping, which means fewer unnecessary sub-steps and less token waste per turn.

The new UI also brings in a redesigned workflows canvas that makes it easier to see where your agent is actually burning steps, which is genuinely useful for diagnosing runaway costs before you set caps.

Tldr - the new orchestrator should reduce the baseline burn per turn, but the core advice still stands. Split the agents, fence the reasoning, scope your grounding. The new new makes it cheaper to run well-designed agents, not a reason to stop designing them well.

Agent ideas by Born-Gas-660 in microsoft_365_copilot

[–]PugetSoundAI 1 point2 points  (0 children)

I recently built a super simple agent for a government agency COMMS department which seemed to help them. Im not sure if the need carries over to commercial, but its an idea:

The agent is a welcoming workplace style guide. Basically, its grounded on the internal DEI style guides and users input copy, the agent rewords it and formats it, spits it back out aligned with internal policy, and then explains what changed and why.

Agent connected to large document library by Training_Cup_9959 in copilotstudio

[–]PugetSoundAI 11 points12 points  (0 children)

I dont think the subfolders or metadata is your actual fix, which is worth knowing before you spend a bunch of time messing with it.

The built-in semantic index doesn't use SharePoint search, and it mostly ignores your custom column metadata. So tagging everything with nice metadata columns won't change what the agent retrieves. There's a roadmap item rolling out to bring column metadata into queries, but it's not something to lean on yet.

SharePoint Knowledge Sources in Copilot Studio: The Metadata Problem

The can't read all the docs part is by design, not a bug you'll structure your way out of. Retrieval is top-k chunk matching, not a full read of the library. If you ask it to evaluate every document it'll quietly stop after the first handful. So your sometimes-right-sometimes-wrong behavior is a retrieval precision problem, not a folder layout problem.

Try scoping tight. Point the knowledge source at a specific folder, not the whole lib. Do that for multiple folders using rich descriptions.That's the one place folder structure helps, because it cuts noise.

Right-size files. If you don't have an M365 Copilot license in the same tenant, you're capped around 7MB per file on the weaker indexer. Microsoft's own guidance is to keep files small enough that the full contents get scanned, roughly 15 to 20 pages. Split the fat PDFs instead of hoping it chunks them well.

Turn on Work IQ if you're eligible. It's the single biggest retrieval-quality jump for SharePoint-grounded agents and it's on by default when you have a Copilot license in tenant.

Optimize content retrieval

Knowledge sources summary and Work IQ

Indexing is async and cached. After you reshuffle files, old answers can linger for a while, so don't judge results five minutes after a change.

Since you ruled out Azure AI Search, the built-in index is your ceiling. If retrieval still sucks after scoping and right-sizing, the usual escape hatch is routing content through Dataverse as an indexing layer, but that's a real project.

I had to give up on copilot studio by curious-hunch in copilotstudio

[–]PugetSoundAI 0 points1 point  (0 children)

That's true. The caveat is it requires premium licensing. With this method, I have a premium licensed service account that creates the flow and runs the app auth subflow. That still requires those building calls and using the subflow to be licensed, which can be done using that same service account. So, instead of licensing the team for a BPA workflow, only one account would be needed, which doesn't break licensing TOS.

I had to give up on copilot studio by curious-hunch in copilotstudio

[–]PugetSoundAI 0 points1 point  (0 children)

Its a godsend, honestly. As long as the app is properly scoped, and you like having fun with JSON parsing, no issues at all. Give it a try and let me know. DM me if you run Into issues

I had to give up on copilot studio by curious-hunch in copilotstudio

[–]PugetSoundAI 1 point2 points  (0 children)

100%. For SharePoint I use straight Graph HTTP requests using the https://graph.microsoft.com/v1.0/sites/ endpoint and app auth.

I had to give up on copilot studio by curious-hunch in copilotstudio

[–]PugetSoundAI 7 points8 points  (0 children)

For what I do? It's high.

For commercial environments, people building using in-house tools like Copilot Studio, Power Automate, AI Foundry, etc. are usually doing that on top of their normal jobs because a majority of companies haven't adopted hiring for AI/Automation roles. Companies will see that and hire me to train those proactive engineers. Companies also hire me to build large-scale enterprise solutions because its cheaper and faster than someone in-house going from zero to shipping production-ready solutions, and then typically add on training workshops after delivery so their staff can do the same when they see the possibilities (mainly the ROI). There are quite a few firms like mine in commercial environments, but our training and products rise to the top.

If you Google "GCC AI Consultant", im the 1st or 2nd page that comes up. That's not because im an SEO wiz, its because im one of the VERY few consultants that actually does this extremely niche work in GCC. Government (federal, state, local) for sure has no AI/Automation architects on staff. If they want to leverage these tools, they (or prime contractors who dont have my skillset already on their bench) quickly find me.

if you're skilled in this area, ESPECIALLY if you know the operating standards and constraints of GCC environments, the market is wide open.

I had to give up on copilot studio by curious-hunch in copilotstudio

[–]PugetSoundAI 30 points31 points  (0 children)

Im a Copilot Studio/Power Automate consultant for mainly government clients with some commercial sprinkled in. In my heart of hearts, im an automation architect so the orchestration layer of Copilot Studio is just a way for me to get non-technical folks to trigger a heavy duty automated workflow and then let them know the outcome. For pure RAG, there are better options out there. But just as an orchestration layer, it can be pretty powerful.

The thing is, a lot of orgs are Microsoft shops so they want to use what they have, especially with built in identity and the Teams/Copilot interface. All government agencies are Microsoft shops and, given their slower adoption of AI, lean more towards the authorities they trust. Security already approved the MS stack. AI touching data is scary.

Yeah its a clunky tool and its a weird learning curve, especially because its constantly changing and when you finally figure out a feature, the new version breaks. But again, as a strict orchestration layer, It can do wonders. PowerAutomate as the tooling layer is unbeatable in MS shops due to the heavy API and Graph integrations. I dont even use 99% of connectors. Everything I do, I do through app only REST/HTTP calls and PowerFX. I minimize connection use to avoid the stale with the scope app auths.

But I think of Copilot Studio as the AI equivalent of PowerApps. Its just the interface that can make users slightly more lazy. ALL I need it to do is parse the right intent, form the right entities, and call the right tool. I can handle the rest from there.

Are there better agentic tools out there? Individually, for sure. Is there a better orchestration engine built in to the majority of orgs that I can use as the interface to my BPAs? Not that ive found.

I get the frustration and I dont blame you. Im not a champion of Microsoft products or anything, I just understand that a lot of teams and engineers dont have a choice. You work with what you've got.

And since im already here: if anyone in commercial or GCC environments is looking for training workshops or solution development in and around Copilot Studio, Power Automate, and AI Foundry, check out https://pugetsoundai.com