Microsoft announced business skills in Dataverse on May 1, and this is the announcement I have been waiting for. Dataverse business skills for agents let you encode org processes, policies, and the tribal knowledge that lives in people’s heads as natural-language instructions. Agents discover them and follow them at runtime. No more cramming everything into a 4000-token system prompt and hoping the model remembers how your finance team handles approvals.
I have been reading the docs since Friday. Here is my honest take.
What business skills actually do
A business skill is a Dataverse record. It contains a natural-language description of when the skill applies, what the agent should do, and what data or actions it can use. Agents query Dataverse at runtime, find the skills that match the user’s intent, and follow the instructions inside.
The shape matters. You are not writing code. You are writing the kind of paragraph you would send to a new hire on day one. Things like: When someone asks about expense approvals over 5000 EUR, route to the regional finance lead, never to the team manager. The lookup table is in the Finance Approvers table. Always confirm the amount and the cost center before submitting.
That description is stored, versioned, and indexed. Multiple agents can use the same skill. You update the skill once and every agent that discovers it picks up the new behavior. There is also a permission layer, so a skill can be scoped to a security role, a team, or an environment.
Underneath, this is grounding. The agent does not memorize your org. It retrieves the relevant skill at runtime and follows it.
Why this changes how you build internal agents
The hardest part of deploying internal agents has never been the model. It has been getting the agent to behave like someone who actually works at your company. The model can reason. It cannot know that your procurement policy changed in March, or that the Madrid office handles APAC tickets on Wednesdays because of a coverage gap.
Until now, that context lived in three bad places. System prompts that grew until they hit the context window and started degrading. Power Automate flows with hardcoded business logic that nobody could find six months later. Or worse, it lived nowhere and the agent guessed.
I have written before that a focused 400-token instruction set produces more reliable behavior than a 4000-token one. Business skills make that practical. You stop stuffing the prompt and start composing skills. The agent picks the right ones for the job.
The other thing this fixes is ownership. A business skill in Dataverse has an owner, an audit trail, and a lifecycle. When the policy changes, the policy owner updates the skill. They do not need to find the agent maker, file a ticket, or wait for a release. That is a real architectural shift, not a feature flag. If your org is still working out who owns what when policies change, Power Platform governance that does not kill adoption covers how to structure that before it becomes a cleanup problem.
The risk I am watching: skill sprawl. If every team writes their own skills with overlapping scopes, the agent will face the same routing problem multi-agent setups face. Skill descriptions will start competing with each other and you will get silent misrouting. Governance has to come early, not as a cleanup project in month six.
What I would do with it this week
Pick one painful, well-bounded process. The kind where the answer is always it depends on who you ask. Approval routing is a good candidate. Onboarding checklists work too.
Write three to five business skills that capture the rules. Keep each one short and specific. Connect them to a Copilot Studio agent that already has the right Dataverse and Power Automate connectors. Test with the messy questions, not the clean ones. Watch which skills get picked and which do not.
The thing to measure is not whether the agent answers correctly. It is whether the right skill was selected for the right phrasing. If selection is unreliable, your skill descriptions are too similar or too vague. Rewrite them and try again. If you are also wiring up custom connectors to extend what the agent can reach, How to Build a Custom Connector for Copilot Studio Step by Step is worth keeping open in a tab.
I will be writing more about this once I have run a real internal pilot. Early signals are good. In my experience, the patterns that survive contact with production are the ones where context is stored where it belongs, not where it was convenient at build time.
This one belongs in Dataverse. Finally.
This post was inspired by Introducing business skills: Teach agents how your organization works via Microsoft Power Platform Blog.