The Microsoft 365 Copilot Python SDK - Building Agents Where Your Data Scientists Already Live

There's a particular kind of Australian organisation that has quietly built serious capability in Python without ever calling itself a software company. The insurer with a team of actuaries who've moved from Excel to pandas. The mining outfit with data scientists running predictive maintenance models. The bank's risk team living in Jupyter notebooks. These people can build sophisticated things, but for years the Microsoft 365 Copilot extensibility story spoke a language they didn't: C# first, then JavaScript, with Python nowhere to be found. If you wanted to plug your models and your logic into Copilot, you either learned a new stack or handed the work to a different team.

The Python SDK for Microsoft 365 Copilot extensibility changes that. It lets Python developers build agents that plug into Copilot using the tools and idioms they already know. Having built Copilot agents across the other SDKs, I think this one matters more than its release notes suggest, precisely because of who it reaches. Microsoft's Python SDK reference is the authoritative source for the API surface, and given how fast this area moves, read it against whatever version you actually install.

What the SDK is, in plain terms

The Python SDK is a set of packages for building agents that run inside Microsoft 365 Copilot. Like its siblings in .NET and JavaScript, it covers the two agent types that define the Copilot world, and knowing which one you're building is the most important decision you'll make before writing any code.

Declarative agents are the lighter path. You're not building an AI system, you're configuring Copilot's. You supply instructions, knowledge sources, and a set of actions the agent is allowed to take, and Copilot's own model and orchestration do the reasoning. It's like writing an excellent brief for a capable employee who already works there. Most of the value most organisations get from Copilot extensibility lives here, and it ships fast.

Custom engine agents are the heavier path, and this is where Python gets genuinely interesting. Here you own the brain. Your code chooses the model, orchestrates the tools, manages state and memory, and Copilot becomes the front door, the chat surface in Teams and across Microsoft 365 where users meet what you built. For a Python shop, this is the compelling bit, because your agent's logic can sit right next to the model code, the data pipelines, and the scientific libraries your team already maintains.

Why Python specifically changes the calculus

This isn't just "another language, tick the box". Python is the native tongue of AI and data work, and that changes what's practical to build.

When your Copilot agent is written in Python, it lives in the same ecosystem as everything else your data team does. It can call a scikit-learn model directly instead of over a network hop to some service another team owns. It can use pandas to shape data mid-conversation. It sits alongside your LangChain or orchestration code, your vector stores, your existing ML pipelines, without a translation layer between the AI logic and the Copilot surface. For organisations whose real intellectual property is in Python, that proximity removes a whole class of integration friction and, frankly, a whole class of inter-team politics.

We see this constantly in our AI agent development work: the projects that move fastest are the ones where building the agent slots into an existing engineering culture rather than arriving as a foreign object one enthusiast owns and nobody else can maintain. For a lot of Australian enterprises, that culture is Python. Meeting those teams where they already work is most of the battle, and until now Copilot extensibility didn't.

Where each agent type earns its keep

My advice here is the same regardless of language: start declarative, and make the case for custom engine rather than defaulting to it.

Declarative agents cover far more ground than people expect. An agent scoped to your policies that answers staff questions. An agent over a project's SharePoint that briefs new team members. An agent that calls your existing REST APIs to look up a claim, a shipment, an account. None of that needs a custom engine, and the declarative version ships in days, runs on Microsoft's infrastructure, and inherits your tenant's security and compliance posture for free. For a business already paying for Copilot licences, it's the cheapest useful AI it will ever deploy.

Custom engine agents are for when you've genuinely outgrown that. The signs are specific: you need a model Copilot doesn't provide, you need real branching orchestration with state, you're calling Python models or libraries the plugin model can't express, or the agent has to live outside Microsoft 365 too. At that point you're doing real software and ML engineering, hosting, scaling, model costs, evaluation, monitoring, and you should budget accordingly. It's the same class of work we take on for enterprise AI agent projects, and it's an order of magnitude more effort than the declarative path. Worth it when warranted. Wasteful when a well-written declarative agent would have done the job.

The failure mode I see most is a capable Python team jumping straight to custom engine because it feels like proper engineering, then spending months building orchestration infrastructure to deliver something a declarative agent handled in a fortnight. The temptation is real. Resist it.

The honest state of the tooling

I'm optimistic about this, but let's be straight about where it sits today.

The Python SDK is newer than its .NET and JavaScript counterparts, and it shows. Expect fewer samples, thinner community answers when you hit a wall, and documentation that's catching up to the code. This is the normal shape of a young SDK, not a reason to avoid it, but it does mean the first Python agent you build should be small and low-stakes so you absorb the platform's quirks somewhere cheap.

Versions move fast and matter a great deal. This corner of Microsoft's platform iterates quickly, which is good, but it means a sample from six months ago may reference an API that's since changed. Pin your versions and read the release notes rather than trusting the first Stack Overflow answer you find.

The naming is a genuine hazard. Microsoft has an Agents SDK, an agent framework, Copilot Studio agents, declarative agents, custom engine agents, and Teams AI lineage all in flight, and the names have shifted over time. When you search for help you'll find confident answers about the wrong thing that look plausibly like the right thing. Anchor yourself to the official docs for the exact package you installed and check the version string.

And the local development loop still isn't what a Python developer expects from pip install and go. Testing an agent properly means testing it inside Microsoft 365, which pulls in dev tenants, app registrations, and permissions. The tooling smooths this more every release, but budget a day for environment setup on your first agent and be pleasantly surprised if it's less.

None of these are reasons to wait. They're reasons to start small.

Where to start

If your organisation has Copilot licences and real Python capability, the move is straightforward. Pick one internal, well-bounded problem, a policy Q&A agent, a "what's the status of X" lookup against one system, maybe something that calls a model your team already trained, and build it as a declarative agent, reaching for the custom engine path only where you truly need your Python logic in the loop. You'll learn the deployment model, the permissions story, and the testing loop on something forgiving, and you'll have a working agent your staff actually use within a few weeks.

That earns you the platform knowledge, and the internal credibility, to take on the heavier custom engine work later, if you ever actually need it. The gap between "Copilot summarises my meetings" and "Copilot runs a model my data science team built" is smaller than most people assume, and a Python SDK closes it for a group of developers who were previously locked out.

If you'd rather not step on the rakes yourself, this is squarely what we do. Team 400 builds Copilot agents and the strategy around them for Australian organisations, from quick declarative wins through to full custom engine builds that wire real models into the Copilot surface. Take a look at our Microsoft AI consulting work, or get in touch and tell us what you wish Copilot could do with the models you've already built.