The Microsoft 365 Copilot JavaScript SDK - Building Agents in the Language Your Team Already Knows

Most Australian businesses that have rolled out Microsoft 365 Copilot hit the same wall within a few months. The out-of-the-box experience is fine for summarising meetings and drafting emails, but the moment someone asks "can Copilot check our job management system?" or "can it look up a client's status in our internal database?", the answer is no. Not because Copilot can't be extended to do those things - it absolutely can - but because nobody in the building knows how, and the extensibility story has historically looked like a wall of manifests, connectors and Microsoft-specific tooling that scares off the very developers who'd otherwise pick it up.

That's the gap the JavaScript SDK for Microsoft 365 Copilot extensibility is aimed at. It puts agent building into the hands of ordinary TypeScript and JavaScript developers, which is most web developers in the country. Having built Copilot agents for clients through the earlier, clunkier paths, I have opinions about what this changes and what it doesn't.

What the SDK actually is

The JavaScript SDK (the agents SDK, in Microsoft's naming) is a set of npm packages for building agents that plug into Microsoft 365 Copilot. It covers the two flavours of agent that matter in the Copilot world, and the difference between them is the single most important thing to understand before you write a line of code.

Declarative agents are the lighter option. You're not building an AI system; you're configuring Copilot's existing one. You give it instructions, knowledge sources and actions it's allowed to call, and Copilot's own model and orchestration do the work. Think of it as writing a very good brief for an employee who already exists. The SDK gives you a programmatic, typed way to define and manage these instead of hand-editing JSON manifests, which sounds minor until you've hand-edited enough JSON manifests.

Custom engine agents are the heavier option. Here you own the brain. Your code decides which model to call, how to orchestrate tools, how to manage state and memory, and Copilot becomes the front door - the chat surface in Teams and Microsoft 365 where users meet your agent. This is what you reach for when the declarative model is too constraining: you need a specific model, complex multi-step logic, or orchestration that Copilot's built-in engine won't do.

The SDK wraps both in JavaScript idioms - async/await, npm, TypeScript types - rather than making you learn a Microsoft-shaped way of doing things. For the actual API surface, Microsoft's SDK reference documentation is the place to look, and given how fast this space moves, check it against whatever version you're installing.

Why the language choice matters more than it looks

This might seem like a small thing. It isn't.

The practical constraint on Copilot extensibility at most organisations has never been the platform. It's been that the platform demanded either C# and the Bot Framework lineage, or a tolerance for low-code tools like Copilot Studio that professional developers tend to bounce off. Meanwhile the largest pool of developers at most companies, and at most agencies they hire, write TypeScript. Every React shop, every Node backend team, every full-stack developer.

A first-class JavaScript SDK means the team that built your customer portal can build your Copilot agent. Same language, same package manager, same testing habits, same CI pipeline. In our AI agent development work, the projects that ship fastest are consistently the ones where agent building slots into an existing engineering culture instead of arriving as a foreign object that one enthusiast owns and nobody else can maintain. Meeting developers where they already are is most of the battle, and Microsoft finally seems to have accepted that.

Where each flavour earns its place

After a couple of years of building these, my rule of thumb is blunt: start declarative, and make the case for custom engine rather than defaulting to it.

Declarative agents cover more ground than developers expect. An agent that knows your HR policies and answers staff questions. An agent scoped to a project's SharePoint site that briefs new team members. An agent that calls your existing REST APIs through API plugins to look up orders or log tickets. None of that needs a custom engine, and the declarative version ships in days, runs on Microsoft's infrastructure, and inherits the tenant's security and compliance posture without you doing anything. For a business already paying for Copilot licences, it's the cheapest useful AI they will ever deploy.

Custom engine agents are for when you've genuinely outgrown that. The tell-tale signs: you need a model other than what Copilot provides, you need orchestration logic with real branching and state, you're integrating systems in ways the plugin model can't express, or the agent needs to also live outside Microsoft 365. At that point you're doing real software engineering - hosting, scaling, model costs, evaluation, monitoring - and you should budget for it accordingly. It's the same class of work we do on enterprise AI agent projects, and it's an order of magnitude more effort than the declarative path. Worth it when it's warranted. Wasteful when a well-written declarative agent would have done the job.

The failure mode I keep seeing is teams jumping straight to custom engine because it feels like proper engineering, then spending three months building infrastructure to deliver something a declarative agent would have handled in a fortnight. Resist the urge.

The rough edges

I like where this is heading, but let's be honest about the current state.

The documentation and the SDK versions move at different speeds. This corner of Microsoft's platform is iterating fast, which is good, but it means samples go stale, package versions matter a great deal, and the answer you find in a six-month-old blog post may describe an API that no longer exists. Pin your versions and read the release notes.

The local development loop is better than it was and still not what a web developer expects. Testing an agent properly means testing it inside Microsoft 365, which means dev tenants, app registrations and permissions. The tooling smooths this over increasingly well, but the first-day setup experience is still nothing like npm create and off you go. Budget a day for environment setup on your first agent and be pleasantly surprised if it's less.

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 answers about the wrong thing that look plausibly like the right thing. Anchor yourself to the official docs for the specific package you've installed.

None of these are reasons to wait. They're reasons to start with something small and low-stakes so you absorb the platform quirks on a project where quirks are cheap.

Where to start

If your organisation has Copilot licences and a web development team, 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 API - and build it as a declarative agent with the SDK. 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 inside a few weeks. That earns you the credibility and the platform knowledge to take on the bigger custom engine work later, if you ever actually need it.

If you don't have the development capacity in-house, or you want someone who has already stepped on the rakes, 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 on Azure. Have a look at our Microsoft AI consulting work, or get in touch and tell us what you wish Copilot could do. The gap between "Copilot summarises my meetings" and "Copilot runs our internal processes" is smaller than most people think, and the JavaScript SDK just made it smaller again.