If Ignite last November was the year everything became an agent, Build in May was the year the agents started talking to each other. The headline theme was multi-agent orchestration — the idea that instead of one assistant, you'll have a whole team of specialised agents delegating tasks, sharing results, and collaborating to complete work no single one could. It's an ambitious, genuinely interesting vision, and Microsoft demoed it well. But the announcement I keep thinking about got a fraction of the airtime, sounds deeply boring, and might end up mattering more than any of the agents. I'll build to it.
Multi-agent orchestration: impressive, and I have questions
The flagship was Copilot Studio multi-agent orchestration: agents built with Microsoft 365, Azure AI, and Microsoft Fabric can now collaborate, delegating tasks and passing results between them to handle complex, multi-step workflows. Alongside it, makers got access to more than 11,000 models in Azure AI Foundry, with the ability to fine-tune on enterprise data. The pitch is a workforce of AI specialists coordinating like a well-run team.
Here's my measured reaction, and it's the one the more experienced people in the community share. The vision is real and the direction is probably right — but we are announcing the orchestration of agents while most organisations haven't got a single agent working reliably in production yet. There's a distinct running-before-walking quality to it. Multi-agent systems multiply not just capability but failure modes: now you have agents that can be wrong, acting on each other's wrong outputs, in chains that are genuinely hard to debug or audit. The complexity is real, and the governance question — who's accountable when a chain of five agents produces a bad outcome, and can you even trace which link failed — is one nobody's answering with the confidence the demos project. Impressive, yes. Ready for your critical workflow, mostly not. Watch it, experiment with it, don't bet the business on it yet.
The boring announcement that might matter most: MCP
Now the one I actually got excited about, which tells you something about me. Model Context Protocol — MCP — went generally available, with growing connector support. Strip the acronym and here's what it is: an open standard for connecting AI systems to your enterprise data and tools. A common language, so any compliant agent can talk to any compliant data source or system without a bespoke integration for every pair.
Why does a dull-sounding protocol beat the flashy multi-agent demos for me? Because I've watched this movie in every other part of technology. The thing that actually unlocks an ecosystem is rarely the most impressive capability — it's the standard that lets everything interoperate. Open, common protocols are how you escape the trap of every vendor's agents only working with that vendor's stuff. If MCP genuinely takes hold as a shared standard, it matters far more for the long-term shape of this field than any single clever agent, because it's the difference between an ecosystem and a set of walled gardens. The unglamorous plumbing wins again — it usually does.
For the data crowd specifically
Build wasn't only agents. Cosmos DB (NoSQL) arrived in Fabric, extending the "your databases live in the analytics platform too" story that started with SQL-in-Fabric — another operational database converging into OneLake. And there was a digital twin builder in the Real-Time Intelligence workload, which made the old smart-buildings engineer in me smile: modelling real-world entities and their relationships for real-time scenarios is exactly the kind of thing I used to hand-build the hard way. Niche, but a genuine capability for the IoT and operations crowd.
There was also a notable nod to the multi-vendor reality most enterprises actually live in: a public-preview connection between Azure AI Foundry and Azure Databricks, letting Foundry agents reach into Databricks — its Genie natural-language layer and its jobs. I read that as a quiet, sensible admission that a lot of organisations run Databricks alongside the Microsoft stack, and that agents which can only see the Fabric half of an estate are agents that can only ever be half-useful. Interoperability over territorialism; more of that, please.
What the forums said
The community split about how you'd expect. The multi-agent orchestration got the "cool demo, but who's running one agent reliably yet?" treatment — the healthy skepticism of people who'll have to operate this, not just watch it. MCP going GA got real, quiet developer enthusiasm — an open standard is the kind of thing practitioners actually cheer, because they've been burned by proprietary lock-in before. Cosmos-in-Fabric drew the now-ritual "another database?" alongside genuine interest. And threaded through all of it, as ever, the cost anxiety: more agents, more models, more workloads, all consuming capacity nobody's quite able to forecast.
The take
Build 2025 was a confident bet on an agentic, multi-agent future, and I don't think the bet is wrong — I think it's early. My advice is to separate the timeline from the direction. The direction (agents, interoperating over your governed enterprise data via open standards) is probably where we're heading. The timeline the keynote implies — multi-agent systems running your critical workflows soon — is optimistic to the point of needing a pinch of salt. So do the sensible thing: get genuinely interested in MCP, because standards compound; experiment with single agents on real data to learn where they help and where they lie; and keep building the governed foundation that every one of these announcements quietly assumes you already have. The agents will get their moment. The organisations ready for it will be the ones who did the boring work first — again.