The Universal Document Converter is the skill everyone will screenshot this month. It is also the wrong headline.
Yes, there is now a skill in the CAT Agent Skills gallery that converts Markdown, HTML, PDF, Word, PowerPoint, Excel, CSV, and plain text fully offline, using only libraries already sitting in the Copilot Studio agent runtime. Useful. Table stakes, honestly, for any platform that wants to handle enterprise documents.
The actual news is how it came to exist. The capability was discovered, not built to a spec. Someone inventoried what the sandboxed runtime already contains, found the pieces, assembled them, and contributed the result back to a public Copilot Studio skills gallery. That loop changes the Microsoft agent vs flow calculus for a whole class of workloads, and if your default answer to "we need document conversion" is still "build a flow for it," that default needs re-examining.
What the Copilot Studio agent harness actually is
The Copilot Studio agent harness is the community's name for the sandboxed runtime the orchestrator gives skills at execution time: a pre-provisioned environment with a set of already-installed libraries, capable of doing real computational work without reaching outside the tenant boundary.
One caveat before you cite this in an architecture review: "agent harness" is not official Microsoft nomenclature. The documented vocabulary on Microsoft Learn is agents, topics, actions, knowledge, and orchestration. The harness framing comes from the community tooling, specifically a gallery skill known as Agent Harness Explorer, which inventories what libraries and capabilities are actually available in the runtime. It is a repeatable playbook, not a one-off hack: run it, get a list, know what you can build without a single external dependency.
Second caveat, and this one matters more. The library inventory is not a documented contract. What the explorer surfaced in the skill author's environment is what shipped with that platform version in that tenant. It changes between platform updates, and Microsoft owes you nothing about its stability. Re-run the inventory before you depend on a library, and again after every wave.
Treat the harness as a versioned dependency you pin and verify, not a stable API you build against blind.
Why offline-only is the enterprise hook
The converter skill's public page makes one claim that should get every architect's attention: the conversions run without external network calls. No third-party API. No new vendor in the security review. No API keys to provision, rotate, or leak.
Compare that to the typical connector-based flow. Every connector is a data path someone in compliance has to trace and sign off on. Every premium connector is a licensing line item. Every external service is a vendor assessment. "It only uses what's already sandboxed" beats "it's fast" as a pitch to a CISO, and I mean that literally: lead your governance conversation with the egress story, not the performance story.
But be precise about what offline buys you, because "zero external calls" and "tenant-safe" are not the same sentence.
Zero egress is not zero risk
Offline execution removes the data egress and third-party vendor risks. It does not remove identity risk (what the agent runs as), storage and retention questions (where converted output lands), or malicious-file risk (a PDF parser running in your tenant is still a PDF parser). And there is an observability trade: work done inside the sandbox bypasses connector-level DLP inspection, which can create a shadow-processing blind spot for your Purview team. Governable is not the same as invisible-by-default being fine.
For regulated document handling, harness-native skills start with a governance advantage flows have to earn. They do not start with a governance exemption.
Microsoft agent vs flow vs custom Azure build: the actual decision
Here is the position: self-contained document transforms and similar sandbox-complete work now belong in agent skills. Flows keep the win for cross-system orchestration, connectors, approvals, and scheduled triggers. Custom Azure keeps the win for scale, SLAs, and anything needing your own models. This is re-segmentation, not replacement. I laid out the broader "when not to build an agent at all" argument in the agent vs flow decision guide; what follows is the three-way version now that the sandbox is a real contender. The third column is the classic AI copilots vs custom Azure build trade, and it has not gone away. It just got a cheaper neighbor.
| Factor | Copilot Studio agent skill | Power Automate flow | Custom Azure build |
|---|---|---|---|
| Data egress | None for sandbox-complete work; strongest default posture | Every connector is a data path to review | You design the boundary; you also own proving it |
| Licensing surface | Rides existing Copilot Studio capacity | Premium connectors add per-user or per-flow cost | Azure consumption plus whatever models you host |
| Maintainability | Small surface, but pinned to an undocumented library inventory | Mature ALM, solutions, well-trodden ops | Full CI/CD control, full CI/CD obligation |
| Extensibility | Bounded by what the harness ships | Bounded by the connector catalog | Effectively unbounded |
| Who builds it | Makers with light code skills | Makers, citizen developers | Engineering teams |
| Failure modes | Silent breakage after platform updates; weak runtime observability | Throttling, connection auth expiry, run limits | Everything, but you get real telemetry to see it |
The lazy decision rule is "does the work need to leave the sandbox? If no, skill first." That rule is directionally right and operationally incomplete. Use this checklist instead:
- Trigger model. Skills run when the orchestrator invokes them in a conversation or agent run. Scheduled jobs, event triggers, and inbound webhooks still say flow or Azure.
- Approvals and human-in-the-loop. Flows own this pattern. Do not rebuild approvals inside an agent.
- Auditability. If an auditor needs a run history with inputs and outputs, flows and Azure give you that today. Sandbox execution logging is thinner.
- Determinism. A conversion invoked by an orchestrator inherits the orchestrator's routing behavior. If the business process requires the same path every time, that is a flow property.
- Volume and runtime. Long-running or high-volume conversion jobs belong outside the agent. Skills inherit the harness's execution limits, whatever they are this quarter.
- Cross-system reach. The moment the work touches Dataverse, SAP, or an external API, the offline advantage evaporates and the connector calculus returns.
If the work is a self-contained transform, invoked conversationally, at interactive volume, with no approval gate: skill first. Everything else, keep your existing playbook.
The Copilot Studio skills gallery is the strategy, not a sidebar
A public, GitHub-hosted Copilot Studio skills gallery covering Copilot Studio, Cowork, and Scout skills signals something specific: Microsoft's CAT team wants an open contribution stream, not a partner-gated catalog. The converter went from a community discovery to a listed gallery skill, which means the loop from "found a capability in the sandbox" to "packaged it for everyone" is already working in public.
That also tells you the trust model. A community gallery has a community review bar. Audit any skill's source before it touches a production tenant, exactly the discipline you apply to an npm package. Read what it imports, what it writes, and where output lands. The gallery being hosted under a Microsoft GitHub org is provenance for the repo, not a security review of every contribution.
Treat the gallery as upstream open source: valuable, moving fast, and yours to verify.
What to do this week
The gap between "libraries sitting in the harness" and "skills listed in the gallery" is where the near-term contribution and consulting value sits. Close it in your own tenant first.
- Pull Agent Harness Explorer from the gallery Get the explorer skill from the CAT Agent Skills gallery and review its source before running it, same as any community package.
- Run the inventory in a dev tenant Do not trust the skill author's library list as your list. What surfaced in their run is a starting hypothesis; your tenant and platform wave are the facts.
- Diff against your current workloads Line the library inventory up against your flow and Azure Functions estate. Flag anything that is a self-contained transform with no connector reach.
- Shortlist skill candidates Document conversion is the proven category. Look next at image handling, data reshaping, and parsing libraries nobody has packaged yet.
- Register the pattern with governance Sandbox-native skills bypass connector-level inspection, so get them into your discovery and control process before they multiply informally.
That last step is not optional. Capabilities that do real work without touching a connector are exactly the kind of thing that grows quietly, and your shadow AI governance process needs to see them before your auditors do.
What to watch next
Two things decide whether this becomes a platform moment or a footnote.
First, whether the gallery gets a formal submission and review process, with versioning and security attestation, or stays a loose contribution stream. Second, whether Microsoft documents the harness library inventory officially. The day that list appears on Microsoft Learn with a support statement, the reverse-engineering era the explorer opened ends, and skills become a first-class build target instead of an archaeology project.
My read, clearly labeled as opinion: if Microsoft formalizes both, this is Copilot Studio's app store moment. If they don't, it stays a clever curiosity for people who read community repos. Either way, the Microsoft agent vs flow decision now has a third input that costs you one explorer run to check: what's already installed. Run it before your next automation build. The cheapest, most governable option is often the one that never had to leave the tenant.
This article was originally published at az365.ai. I'm Alex Pechenizkiy, an Azure and Power Platform solutions architect writing honest, vendor-neutral analysis of the Microsoft AI stack. More at az365.ai.
Top comments (0)