The 20-minute overview slots at Nordic Summit 2026 are a good format for one idea told well, and Sebastian Sieber used his for skills. Sebastian is Global Technology Director at proMX and a Microsoft MVP, and the session was called “Learn A New Skill You Already Know: Business Skills in Agents”. This is my recap. The framing and the demo are his, the summary and any mistakes are mine.
What languages do you speak?
He opened with a show of hands. Who speaks German, Swedish, Danish, Italian? Who is proficient in C#, in Python? Who speaks English? Everyone. Then the punchline: you already have everything you need to build skills for agents, because English is all you need.
The setup was a process slide from his own company: leads, opportunities, strategic findings, the quality gates in between, running on Dynamics and a project operations tool. He asked whether the room does the same, answered no on their behalf, and made the point that this is exactly the problem: a business process, with its quality gates and rules, is specific to one organisation, and that is what has to be translated into the agent. A skill is the thing that carries that business logic.
What a skill is, and why it is not an instruction
His definition: a focused package of instructions and resources that helps an agent perform one job reliably. A folder, a structure, references it can use, tools it can call. The agent should be as dumb as possible and just execute; the skill knows how a device is ordered, which approvals a purchase needs, how a new employee is onboarded.
The argument for skills over instructions was mechanical. A three-page instruction is sent to the model every time the agent is triggered: every approval, every request, every data update. A skill is loaded only when the agent decides it needs it, based on the name and description. When someone requests a new laptop, the agent does not need the onboarding skill in context. So skills save tokens, they are only used when relevant, and they do not become one big block on the left and the right of every conversation.
The demo: Copilot Studio, Power Apps, Cowork
He showed the same idea in three places. In Copilot Studio an HR agent had instructions plus skills for scheduling an interview, writing a job description and screening a candidate. Each skill is plain text: an aim, a description the agent reads at conversation start, inputs, choices, outputs and guidelines. No witchcraft, as he put it. In the Power Apps maker portal the same thing appears as business skills, currently in preview, where you can either write them yourself or let the system learn them by scanning what changed in your data over a week.
The Cowork demo was the one that landed. A project scheduler skill: move the end date of all tasks in a set of projects by a number of days, and produce an impact file that says whether the baseline finish is affected. It was not, so he let it update Dataverse. Then a second skill built an interactive Gantt chart of the plan, reusing the skill Microsoft itself uses to generate managed apps. His summary: with skills and Cowork together he had a headless Dynamics environment with his own business logic, built by writing down what he wants and how he understands his process.
The caveats were there too. In Copilot Studio you need the Dataverse MCP to use business skills against Dataverse, and performance is not great yet. The same skills work across GitHub Copilot, Microsoft 365 Copilot and the agent builder, which for him is the real win: develop a skill once and every user in every tool has it. He even wants a PowerPoint skill that carries the company fonts and colours.
Not for everything
Should every task be a skill? No. Skills are for the more specific parts, and they do not replace instructions, tools or scripts. He drew a scale from heuristic, where the agent has the most freedom and the output varies most, to deterministic, where a script runs the same way every time, and said the skill definition is where you decide where on that scale a given job sits.
His rules for starting, from the slide he called consistency first, tokens second:
| # | Rule |
|---|---|
| 1 | Near identical approach for everyone |
| 2 | No remembering “house rules” by heart |
| 3 | Clear trigger and description |
| 4 | Boundaries and escalation path |
| 5 | Open format: the same skill across AI tools |
| 6 | Get the task right the first time and save tokens |
The one he stressed was the third: the trigger and description are how the model decides which skill to use, and a fifty percent match means it will try something else. Boundaries matter as much: always tell the agent what it should not do, because the agent is good at reading exactly that.
Three roles, and permission to delete
Scaling it needs three personas. The business owner owns the outcome, because the skill describes their process and their rules. The maker or developer designs the skill and finds the tools it needs. The platform team owns the data boundaries, where it lives and how it is distributed. And do not be shy about killing a skill nobody uses, because otherwise you carry technical debt into 2027 for an agent with two users.
He finished on time, which he was pleased about, with the same line he started on. Everyone in the room can write skills today. You speak English, you can use a keyboard, and you explain the rules the way you would to a junior colleague. Hopefully they follow.