The Microsoft 365 Agents .NET SDK - When to Reach for It and When Not To
Most conversations I have about Copilot agents start in the wrong place. Someone has seen Copilot Studio, liked how quick it looked in the demo, and decided that is the path. Then they hit the first thing the low-code builder cannot do cleanly, and the project stalls while everyone argues about whether to force it or start again. The question they should have asked at the start is the one this post is about. Do we need to write actual code, and if so, what does the .NET SDK give us that the visual tools do not?
For a lot of Australian organisations, and especially the ones with existing .NET investment, the answer is that the SDK is exactly right, and reaching for it early would have saved the false start. But it is not right for everyone, and part of doing this properly is being honest about that. Microsoft's reference for the SDK lives in the .NET API documentation, which is thorough but, like most API references, tells you what every class does without telling you when you would actually want it. That gap is what I want to fill.
The three ways to build a Copilot agent, briefly
To know when the SDK fits, you need the lay of the land. There are broadly three ways to build an agent that plugs into Microsoft 365 Copilot.
The first is declarative agents, which are configuration rather than code. You describe how the agent behaves, point it at knowledge sources, and give it some actions. This is the fastest path and the right starting point for a lot of use cases, especially anything that is mostly "answer questions from these documents in this tone".
The second is Copilot Studio, the low-code environment with a visual designer. More powerful than pure configuration, with flow logic and connectors, and approachable for people who are not full-time developers. A lot of good work gets done here, and our Copilot Studio consulting is often about helping teams get the most out of it before they assume they need to write code.
The third is the pro-code path, where you build the agent as a proper application, and this is where the .NET SDK comes in. You are writing C#, you have the full power of the language and the .NET ecosystem, and you are building something that behaves exactly how you designed it rather than within the guardrails of a visual tool.
The mistake is treating these as a hierarchy where code is "better". They are different tools for different jobs. Code is more capable and more expensive, in build time and in the skills required to maintain it. The trick is knowing which job you have.
What the .NET SDK actually gives you
When you build with the SDK, you are working in the environment your developers already know. That sounds like a small thing. It is not. For an organisation with a .NET team, a Visual Studio habit, existing CI/CD pipelines, source control discipline, and a way of testing and deploying software that already works, building the agent as a .NET application means it slots into all of that. The agent is code in a repository, it goes through code review, it has unit tests, it deploys the way everything else deploys. Compare that to a low-code agent that lives in a portal, where "what changed and who changed it" is a harder question to answer and testing is more manual.
The SDK gives you the building blocks for handling the conversation. Receiving messages, managing the turn-by-turn flow of a dialogue, calling out to your own services and APIs, and shaping what comes back. Because it is code, your agent can do genuinely complex things. Call three internal systems, apply real business logic to reconcile what they return, handle the edge cases the way your business actually handles them, and respond with something considered rather than a templated reply. When the logic gets beyond "if this, then that", code is where you want to be.
It also connects naturally to the rest of your .NET world. If you already have a services layer, domain logic, and integrations built in C#, the agent can call straight into them rather than reimplementing that logic in a visual flow. For businesses that have spent years building solid .NET systems, this is the honest advantage. The agent becomes another consumer of code you already trust, not a parallel universe with its own version of the rules. Our .NET consulting work often ends up here, because the organisations with the most to gain from Copilot agents are frequently the ones already deep in the Microsoft and .NET stack.
When the SDK is the right call
A few patterns where I would reach for the SDK without much hesitation.
When the agent needs to do real work across multiple systems with real logic in between. Not "look this up and show it", but "check this, decide based on the result, take an action, handle the case where the action fails". That decision logic is where visual tools get painful and code gets comfortable.
When you have an existing .NET codebase full of business rules you do not want to duplicate. Reimplementing your pricing logic or your eligibility rules inside a low-code flow is how you end up with two versions that drift apart and eventually contradict each other. Calling the existing code from a .NET agent keeps one source of truth.
When the thing needs proper engineering discipline because it matters. Anything customer-facing, anything touching money or compliance, anything where "it broke and we are not sure why" is not an acceptable answer. Code with tests and version control gives you a level of control and auditability that a portal-based tool struggles to match.
And when you can see the agent growing. If this is version one of something that will get more capable over time, starting in code means you are not going to hit a ceiling and have to rebuild. The low-code start that has to be thrown away and redone in code is a common and avoidable waste.
When to leave it on the shelf
Equally, do not reach for the SDK out of habit or engineering pride. If the agent is genuinely a "answer questions from these documents" job, a declarative agent will get you there in a fraction of the time and anyone can maintain it. If the logic is simple and the connectors you need already exist in Copilot Studio, use Copilot Studio. Writing a full .NET application to do what a visual flow does in an afternoon is not sophistication, it is over-engineering, and you will pay for it every time someone has to change it.
The other honest caution is the skills question. A .NET agent needs .NET developers to build and maintain it. If you do not have that capability in-house and are not planning to buy it in, building something in code that then has nobody to look after it is a genuine risk. I have seen agents go quietly stale because the one contractor who built them moved on and nobody left could safely touch the code. Match the build approach to who will actually own the thing long term.
The state of it in 2026
The SDK is maturing, and the direction is good. Microsoft has been consolidating the tooling so that the agents you build sit in a coherent story rather than the scattered set of overlapping frameworks it felt like a year or two ago. The documentation is thorough if a little dense, and the samples are genuinely useful for getting started. If you have C# developers, the ramp-up is not steep, because the shape of it feels like the .NET they already know.
The rough edges are the ones you would expect from a moving target. Things shift version to version, some of the guidance assumes you are already fluent in the wider Copilot extensibility model, and the surrounding ecosystem of blog posts and Stack Overflow answers is thinner than for mature technologies, so you are more often reading the source material and working it out yourself. None of that is a reason to avoid it. It is a reason to have someone on the project who has done it before and can save you the dead ends.
If you are weighing up whether your Copilot agent should be built in code or in a low-code tool, that decision is worth getting right before you start, because the cost of choosing wrong is a rebuild. Our Microsoft AI consulting work is often exactly that conversation, looking at what the agent actually needs to do and matching it to the right build approach rather than defaulting to whatever is fashionable. If you have a .NET team and a Copilot agent you want built properly, get in touch and we will help you work out whether the SDK is your path.