I’ve been spending a lot of time lately talking to people about what’s actually happening at the intersection of APIs, agents, and enterprise software. Not the hype cycle version. The version where real developers are building real things for real business users. My recent conversation with Sebastien Levert, a product manager on the Microsoft Office 365 Copilot team, was one of those conversations that sharpened my thinking considerably.
Two Types of Developers, One Platform
What struck me first about Seb’s perspective is the clarity with which he sees who’s building on the Copilot API. There are two distinct groups. The first is line of business developers — people working inside large financial institutions, retail companies, and other enterprises who are building specialized experiences for their internal users. The second is ISV developers at medium to large software companies who want to meet their customers where they already work.
That distinction matters because it tells you something about what the platform is actually for. It’s not a playground for experimentation. It’s infrastructure for getting work done. And the people building on it are thinking about business outcomes, not technology for its own sake.
Capabilities as Native Extensions
One of the things Seb said that resonated with me — and you’ll understand why if you follow Naftiko’s work — is how he frames capabilities. Inside Copilot, developers build agents that function as scoped, specialized extensions of the product. These aren’t standalone apps that happen to connect to Microsoft 365. They’re native capabilities. You don’t leave the product to use them. They’re just there, in the flow of work.
That’s the right way to think about it. When millions of people are using Copilot daily, the last thing you want is to send them to yet another portal. You want to bring the capability to where they already are. That’s how you build integrations that people actually use rather than integrations that sit on a shelf.
The Context Engineering Problem
Here’s where the conversation got really interesting for me. Context engineering is something I think about constantly — how do you set the table so that when someone sits down to work, everything they need is already there? And how do you make sure it’s still there when they come back the next day?
Seb described something Microsoft calls Work IQ, and it’s a meaningful answer to that question. The idea is that your Microsoft 365 data estate isn’t a collection of siloed documents and emails. It’s a connected graph. A document is linked to the people who created it. Those people are connected to emails. Those emails reference tasks. Those tasks have Teams conversations. When you search for something or ask Copilot a question, all of those connections are taken into consideration.
If you had to build that yourself — the semantic indexing, the vector databases, the relationship mapping — you’d be rebuilding a significant amount of infrastructure. Work IQ gives you that as a single endpoint. It’s pre-summarized, pre-indexed context that you can plug into your applications. That’s a substantial head start on context engineering.
MCP Servers and the Terminal
What I didn’t expect to hear from a Microsoft product manager is that Work IQ is exposed as an MCP server. That means you can plug it into any AI experience — not just Copilot, not just VS Code, but your terminal, your CLI tools, whatever environment you’re working in. Seb told me he uses it most in the Copilot CLI, right in his terminal, bridging the gap between his productivity data and his development workflow.
That’s exactly the kind of interoperability that matters. When context is locked inside one product, it’s useful but limited. When it’s available as an MCP server that any AI-connected experience can consume, you’re starting to build something that works the way people actually work — across tools, across contexts, across the boundaries we’ve historically accepted as fixed.
Agent Swarms for Productivity
The part of our conversation that really got me thinking was Seb’s description of agent swarms for productivity. Developers are already familiar with the concept of a fleet of coding agents — ten terminals open, each one working on a different part of the problem. Seb is applying that same pattern to business productivity.
Imagine asking the same question to five different agents — your ServiceNow agent, your project management agent, your email agent, your calendar agent, your document agent — and getting a synthesized summary back. You’re not just getting an answer from one system. You’re getting context from across your entire work landscape. That’s the productivity equivalent of what developers are already doing with code.
I’ll be honest, I’m still skeptical about some of the promises being made about agents across the industry. But this particular pattern — using swarms of specialized agents to assemble context for humans — feels genuinely useful. It’s not replacing anyone. It’s doing the tedious work of context switching that eats up hours of everyone’s day.
The Business Side Matters
What I keep coming back to after this conversation is the business side of all of this. Office 365 Copilot matters not because of the technology underneath it, but because that’s where business stakeholders live. That’s the product they open every morning. That’s where their documents, emails, meetings, and tasks already exist.
When we talk about building integrations at Naftiko, this is what we mean. It’s not enough to have a great API. You have to understand the context your users are working in, engineer that context into your integrations, and deliver capabilities that feel native to their workflow. The companies that figure this out — whether they’re building LOB applications or ISV products — are the ones whose integrations will actually get used.
I’ve got more material from my conversation with Seb that I’ll be weaving into future episodes and posts. The intersection of context engineering, MCP, and business productivity is one of the most interesting spaces right now, and I think we’re just getting started.
