Codifying your procedures as governed business skills for Dynamics 365 agents

A generic Dynamics 365 agent knows how F&O works. It doesn't know how your business works — and those are two very different things.

The gap between them is your procedures: the approval chain that's specific to you, the way you actually run procure-to-pay, the rules a seasoned controller applies without thinking, the exceptions your team handles by instinct because they've done it a thousand times. None of that is in the out-of-the-box agent. Most of it isn't written down anywhere at all.

Microsoft's answer to this is business skills — the ability to define your processes and procedures as reusable context and instructions for ERP agents, with access managed through security roles, and Microsoft providing skills for common processes like procure-to-pay. It's the right idea. The hard part — and the valuable part — is what goes into a skill.

What a business skill actually is

Think of a business skill as the written-down version of what an experienced member of your team knows: the steps of a process, the rules that govern it, the conditions that trigger an exception, and what to do when one fires. Codified as governed context, it lets an agent act the way your business does rather than the way a textbook does — and because it's managed through security roles, the agent only has the skills it's allowed to use.

The difference it makes: without it, the agent handles the generic case and guesses at yours. With it, the agent applies your procedure — your tolerance, your approval threshold, your escalation rule — consistently, every time, and escalates the genuine exceptions to a person.

The real work is capturing procedures that live in people's heads

Here's the part the roadmap doesn't do for you: most of your procedures aren't documented. They live in the heads of the people who run them, in half-finished wikis, in the way things have "always been done." Turning that into a governed skill is the actual project, and it has three steps:

1. Surface the procedure. Sit with the people who run it and get the real process out — including the exceptions, which are where the value and the risk both live. The documented process and the real process are rarely the same.
2. Codify it as governed context. Turn it into the structured instructions and rules a skill is made of — tied to the right security roles, so the skill is available only where it should be.
3. Keep it honest and current. A procedure encoded once and never updated drifts out of true, and a skill that encodes a stale procedure is worse than none. Ownership and review have to be part of the design.

If you've done knowledge-base or playbook work before, this is that work — with a Dynamics-native home and governance built in. It's the same discipline behind reviewing a contract against a firm's own playbook rather than general knowledge (see legal AI that applies your playbook): the value is that the system applies your rules, with the evidence, not a generic approximation.

Why this is where the depth shows

Anyone can write a bullet list of a process. Codifying it as a governed skill that an agent reasons over correctly — with the exceptions handled, the security roles right, and the escalations landing on the right person — needs someone who understands both how the agent uses the skill and how the process actually runs in your Dynamics estate. That pairing is the difference between an agent that follows your procedure and one that confidently does the wrong thing.

It also connects to the rest of the picture: skills define what the agent should do; governed MCP Action tools give it the safe operations to do it on your customized F&O; and sound governance keeps the whole thing inside your controls.

If you want your procedures working for an agent instead of trapped in your team's heads, tell us the process you'd codify first — usually it's the one that breaks when the person who knows it best is on leave.