Starting a Copilot Agent Project with the Agents Toolkit for Visual Studio

If your shop runs on .NET, there's a good chance your developers live in full Visual Studio, not VS Code. That matters more than it sounds when you start building Microsoft 365 Copilot agents, because most of the tutorials and demos out there assume VS Code, and the people writing your line-of-business systems are sitting in a different editor entirely. The good news is the Agents Toolkit ships for Visual Studio too, and it slots into the workflow a .NET team already knows.

We do a fair bit of Microsoft work, and a pattern keeps showing up. The team that owns the ERP integration, the internal APIs, the Azure services, those are the people who should be building the Copilot agents that talk to all of it. They already understand the data, the auth, the systems. Asking them to drop into an unfamiliar editor to do agent work adds friction for no good reason. So when those developers can scaffold, build, and debug an agent inside the Visual Studio they use every day, the whole thing moves faster.

Let me walk through what starting a project actually looks like, what the toolkit handles for you, and the bits that will catch you out.

Why Visual Studio and not the browser builder

You can build a Copilot agent in the browser. The agent builder is fine for a first pass. You describe what you want, point it at some knowledge, poke at it in a test panel. For a single agent that one person owns and nobody else has to maintain, that's a reasonable starting point.

It falls apart the moment the agent gets real. Once you've got proper instructions, several knowledge sources, an API plugin or two reaching into your own systems, and more than one developer involved, the browser becomes the bottleneck. You can't diff a change. You can't roll back to last week's version when an instruction tweak quietly broke something. You can't review a colleague's work before it goes live. The agent definition is locked behind a UI instead of living in files you control.

The Agents Toolkit for Visual Studio turns the agent into a normal project. A solution you open, files you edit, source you commit to Git. For a .NET team this is just how work gets done, and an agent that behaves like every other project in the repo is an agent the team can actually maintain. We push hard for this on our Copilot Studio and extensibility projects, because the agents that survive contact with a real organisation are the ones built like software rather than assembled by clicking around a web form.

What the toolkit gives you when you start a project

The Agents Toolkit installs into Visual Studio through the installer, the same way you'd add any other workload or extension. Once it's in, creating a new agent project is a File, New Project away. You pick the Copilot agent template, name it, and you get a working structure rather than a blank manifest and a browser tab open to the schema docs.

That scaffolding is worth more than it looks. A hand-written Copilot manifest is fiddly, and getting the file layout right the first time eats an hour you'll never get back. The template gives you the manifest, the instruction files, and the plugin definitions in the right places with sensible defaults already filled in. You start from something that runs.

The toolkit also handles the provisioning and registration plumbing. To actually run an agent you need it registered against your Microsoft 365 tenant, and that involves app registration, permissions, and a chain of setup steps that are tedious to do by hand. You sign in with your tenant account, the toolkit sorts out the registration side, and you're pointed at your real environment rather than a sandbox that behaves slightly differently from production.

And the part that earns its keep day to day: you can launch the agent straight into Microsoft 365 Copilot from inside Visual Studio. Hit start, it provisions what it needs, and it opens your agent in the real Copilot interface against your real tenant with your real knowledge connections. You're not testing a simulation. The orchestrator is the production orchestrator and the grounding is the production grounding, so what you see while debugging is what your users will get.

How a build loop actually goes

Here's roughly how a session looks when one of our developers starts a new agent in Visual Studio.

Create the project from the template. Open the instruction file and write what the agent is for, in plain language, right there in the editor where you can see the whole thing instead of squinting at a cramped web panel. Set the build configuration the way you would for any project. Hit start. The toolkit provisions and launches the agent into Copilot. Ask it the questions it's meant to handle, plus a few it shouldn't, and watch what comes back. Go back to the instruction file, change a line, run again.

Because everything is in files, you can be precise. You change the exact instruction you mean to change, see the effect, and move on. When something works you commit it, so there's a record of what changed and why. When something breaks you diff against the last good version and see exactly what you touched. This is the bread and butter of how we build custom AI agents in general. The model is only one part of the job. The rest is treating the agent like software you'll be living with for the next two years.

The other thing the project-on-disk approach unlocks is real collaboration. Two developers work through Git, review each other's pull requests, and merge, instead of taking turns in a shared browser session and silently overwriting each other. For any agent more than one person owns, that's not a nice-to-have. We've inherited browser-built agents where nobody could say who changed what or when, and untangling them is genuinely miserable work.

Where it's still rough

I'm not going to pretend it's all smooth. There are sharp edges worth knowing about before you commit a client to a timeline.

The first provisioning run is the slow one. Registering an agent against a tenant the first time takes a while and sometimes fails in ways that aren't obvious from the error. A missing app registration permission, a tenant policy blocking something, a consent prompt that didn't fire. When it works it works, but the initial setup can eat an afternoon if the tenant is locked down, and most enterprise tenants are locked down. Budget for it. Don't promise a working agent by lunchtime on day one in an environment you've never provisioned in.

The Visual Studio tooling for Copilot agents is also a touch behind the VS Code experience in places. Microsoft has put a lot of its early energy into the VS Code flow, so some samples and walkthroughs assume that editor, and you occasionally have to translate steps across. It's not a blocker, but if you're following a tutorial written for VS Code you'll hit the odd point where the menus and project structure don't quite line up. Knowing both editors helps here.

Error messages are another one. When provisioning or launch fails, you sometimes get a message that tells you it failed without telling you why in plain terms. You learn the common causes with repetition, but a newcomer can lose an hour to what turns out to be a single missing permission. This is where having done it a few dozen times genuinely pays off.

And the non-determinism that comes with any model is still there. Running locally doesn't make the model deterministic. The same question can come back differently between runs. A fast loop is great because it lets you ask the same thing many times quickly, which is exactly what you want, but don't mistake one good answer for a passing test. Ask it five times. Look for consistency, not a single lucky response.

One honest limit: the toolkit is a build-loop tool, not a scale-testing tool. It's excellent for tight iteration while you're developing. It is not how you prove an agent handles two hundred different intents reliably across a thousand staff. For that you want structured evaluation against datasets of real test cases, which is a separate discipline with its own tooling. The toolkit gets you to "this works when I try it." Evaluation gets you to "this works for everyone, and still works after the next change."

Visual Studio, VS Code, or the browser

People ask which tool they should use, and the answer depends on where the work is.

If you're sketching an idea or building something small that one person owns, the browser builder is the fastest start. No setup tax, testing in minutes.

If your developers are .NET people working in full Visual Studio and the agent needs to talk to your own systems, the Visual Studio toolkit keeps them in one editor with one debugger and one project model. That's the case for a lot of the organisations we work with, where the agent's whole value is plumbing into existing line-of-business code.

If your team already lives in VS Code, that flow is slightly more mature today and there's no reason to switch them.

The thing that matters across all three is the discipline, not the editor. The moment an agent gets serious, multiple knowledge sources, plugins, more than one person, anything that should live in version control, get it out of the browser and into a real project. We build that rigour into our Microsoft AI consulting work rather than leaving it to whoever happened to assemble the agent first.

The takeaways

If your developers run on .NET and full Visual Studio, the Agents Toolkit lets them build Copilot agents without leaving home. The scaffolding saves you the manifest grunt work, and treating the agent as a committed project is the single best habit you can build around this stuff.

Expect the first provisioning run to be the painful one, especially in a locked-down tenant, and don't schedule anything tight around it. Use the speed of the loop to ask questions many times rather than to skip thinking. And remember the toolkit gets you to working, not to proven. When the agent is past the experiment stage and headed for real users, graduate to structured evaluation.

If you want a hand getting a proper agent development workflow set up for a .NET team, or you've got a browser-built agent that's become a tangle, that's everyday work for us. Get in touch and we can talk through where your Copilot work is and what it'd take to make it maintainable.

Reference: Create a new agent project with the Agents Toolkit for Visual Studio, Microsoft 365 Copilot extensibility documentation.