Harnessing the Power of AI Collaboration | Simon Lacasse , Microsoft GBB

Samuel
Hello, Simon, and welcome to Mastering AI with the Experts. Thank you so much for joining us today on the podcast.

Simon Lacasse
I’m happy to be here. Thank you for inviting me.

Samuel
Simon, you just released a white paper called Scaling Agents for Enterprise. You’ve been working at Microsoft for some time now. You’re a Global Black Belt for Azure. Can you tell us a bit about your journey at Microsoft and what you’re doing as part of a GBB?

Simon Lacasse
Yeah. My role is Global Black Belt for AI. I don’t do karate or wear a black belt, but essentially I work with a SWAT team of AI experts to help customers harness the power of AI—using it properly and responsibly, but also using it to create really cool things. It’s a really fun role. I get visibility globally with customers developing different AI technologies and implementing them to create really interesting solutions.

Samuel
As I mentioned, you just released a white paper called Scaling Agents for Enterprise. Agent is a word we’re hearing every day on social media and in the news. For people that keep hearing about multi-agent systems, which are very interesting and very powerful, how would you describe what they are in a simple and practical way so people who are not used to those terms understand it clearly?

Simon Lacasse
I think you almost need to start with the definition of an agent, because everybody seems to have a different definition and sees it differently. The reality is that agents aren’t something new. It’s essentially a clever way to use models that we already have.

Simply put, it’s connecting a whole network of AI models that can work together to solve bigger and more complex problems. That’s how I see it. The idea is that each model, or agent if you want to call it that, is specialized but limited on its own. When you connect models or agents together, they can solve challenges that no single model can handle by itself.

That’s really the core idea: modularity and abstraction in an agentic design. You break the problem down, give each agent a clear responsibility, and let the system assemble the pieces into something far more powerful.

To give you an example, imagine we’re planning a big trip together. One agent is specialized in finding the best flights. Another is specialized in comparing hotel prices and availability. A third helps you build the itinerary around your preferences. Maybe a fourth checks weather, events, and local considerations.

The idea is that you have an orchestrator that sits on top of all of this and coordinates everything so we can get to a final plan that makes sense for my budget, my time, and my constraints.

Samuel
How would you explain the orchestrator? That’s something I get asked almost every week.

Simon Lacasse
That’s a topic we can go really deep into. You can look at it that way. You could use a model to create plans, break down a problem, and do the orchestration, because multi-agent systems need to collaborate. That’s the whole power of them. They need to be able to assign tasks to each other and respond to one another.

That orchestration piece is important because, without it, agents would just be siloed and wouldn’t really collaborate with each other. That’s one way of doing orchestration.

Orchestration can also be very deterministic. You could use things like robotic process automation to say, “I need you to do this step, then this step, then this step.” It really depends on what you’re trying to do.

Sometimes orchestration can be very dynamic, where you don’t know what the next step will be because it depends on what an agent did, what data it gathered, or what actions it took. Large language models do very well in dynamic planning because they’re able to recreate the plan on the fly depending on what’s happening across the entire workflow.

In enterprises, we often see more deterministic workflows, where we use more static planners and sequential plans instead of AI-driven planning.

Samuel
So there’s more than one type of orchestration, right?

Simon Lacasse
Yes, and it gets complex. You can have agents working in parallel, where they’re all working at the same time and then coming back with their responses. You can have agents that work sequentially, where you need to wait for one agent to produce an output before you can use another agent.

You can also combine the two, where some agents run in parallel and others run sequentially, and then you mix all of that together with long-running workflows. It can get pretty complex.

Samuel
So the orchestration is pretty much a project manager for all your agents, right?

Simon Lacasse
Yeah. You can think about it like that. Exactly.

Samuel
I’ve been hearing about multi-agent systems for some time now. I won’t say years, but it’s been mentioned since GPT-3 and GPT-3.5 were released. I heard echoes of multi-agent systems, but it was mostly a concept in research labs. What changed recently in AI and cloud that now makes multi-agent systems realistic to deploy at scale for enterprises?

Simon Lacasse
I love that question because I’ve been trying to develop agents since before the GPT models. Even when GPT-2 came out, I was trying to build agents with that. The terminology itself is old. It was coined by Stuart Russell—I forget the exact year—but the terminology is not new.

What really excites me is that the technology has advanced quite a lot. That’s why I feel like I can finally build the things I dreamed about building. I think they’re doable today.

A lot of that has to do with how much AI models have improved. Models like GPT-4, Claude, or Gemini are far more capable than before. We now have reasoning models that can reason over huge amounts of data, adapt to their environment, and even take actions on their own.

We can give them tools and functions so they can tap into external systems. They can search the web, and they can even control parts of your computer with computer-use agents—computer user agents that understand what’s on your screen and interact with it. They’re much more powerful.

Those two things—reasoning and action—are really the foundation of real agentic systems. At a high level, it’s about whether an agent can have agency, meaning it can adapt to its environment and take actions as that environment changes.

That’s a big shift in how we deploy agents at scale. With open standards and agent protocols, we can reuse the same infrastructure and architectural patterns we already know from traditional software development.

Protocols like A2A, for example, allow us to use the same internet fabric that already exists today. Agents can talk the same language. You can have an agent, I can have an agent, we can have agents in the cloud, we can share them, and we can all work together. That’s how I see a lot of this happening.

The industry is essentially building a framework that enables connectivity between agents. It’s like a fabric. Almost like a new internet, where instead of us clicking on websites, agents do that for us. We interact with them, and they help us with repetitive tasks we don’t like to do, so we can focus on higher-value work.

Samuel
You’ve highlighted that moving from a single agent—which I think is where most organizations are today—to deploying an ecosystem of agents unlocks a different class of capabilities. What becomes possible when you make that shift?

Simon Lacasse
I definitely believe we’re moving from individual intelligence to collective intelligence. Whether that’s AI agents, humans, or all of us working together, a single agent can only get you so far.

A single agent has to understand the problem, plan the solution, and execute every step on its own. That’s fine for simple tasks, but it starts to fall apart as soon as things become multi-step, cross-domain, or require different types of expertise, or even humans in the loop.

That’s where multi-agent systems really shine. Instead of a single do-everything model, you have a network of focused agents, each one really good at a specific thing. When they work together, they can solve much more complex problems using different kinds of expertise.

On top of that, humans can jump into the loop at the right moment. They can review, override, approve, or steer the system in the direction they want.

In reality, it becomes a collaboration between humans and agents. You can keep domains isolated where needed, apply governance and policies per agent, and create reusable catalogs of agents that teams can use together.

For enterprises, that’s what makes agents scalable and safe. The shift isn’t just smarter models—it’s smarter ecosystems of models working together.

Samuel
That makes sense. It’s a collaboration between agents and humans, not just multi-agent systems. It’s like a team of humans powered by agents.

Simon Lacasse
Exactly. That’s exactly how I see it.

Samuel
I was reading a book about agent architectures, and the authors were suggesting that every subprocess handled by agents should be a sub-agent. What’s your take on this? Meaning, every subprocess that needs specialization should be addressed by a sub-agent instead of having one big agent with complicated instructions.

For example, if I need my agent to go into my Salesforce environment to gather information about an account, and it also needs to go into my ERP system to find information about transactions, instead of having one agent accessing both Salesforce and ERP, I should have one master agent and two sub-agents—one gathering information from Salesforce and one from the ERP—because they’re more specialized. What do you think about that?

Simon Lacasse
I actually have a white paper that talks about that. It’s around modularity and abstraction—how modular you get with your agents versus having a very abstract agent that tries to do everything.

I think today the trend is definitely toward specialized agents. For example, you can use general-purpose models like GPT-4 to power agents, but sometimes you also want very specific models, like anomaly detection models. That’s when you start to see more specialized agents.

I don’t think models today are good enough to be great at everything. So right now, it’s better to harness their power by specializing agents so they’re really good at one thing.

That’s how a lot of people start. They create one agent that’s really good at something, then another agent that’s really good at something else. Then they realize they can stitch them together and suddenly do a lot more. That’s where things start to get interesting.

I’m not hiding the fact that maybe in the future we’ll have one model to rule them all that can do everything. We’re just not there yet. In fact, multi-agent systems exist precisely because of that limitation.

By adding more specialized models, you exponentially increase what your system can do. There’s also a maintenance benefit. If I need to change something, I can update a specific agent without impacting the entire system.

With modularity, development becomes easier. You isolate components, which makes them easier to manage. If you change one agent, it shouldn’t affect another agent. But if you have one centralized model that does everything and you change something there, it can impact the entire system.

Another advantage is that sub-agents can also run standalone. That makes the system easier to maintain and scale.

Samuel
Totally. That’s interesting. In my own multi-agent architectures, all my agents are standalone agents. Then I put an orchestrator on top to connect them all together, and I can do some really cool stuff.

Even my single agents have their own UI. Someone can go in and just use that agent, but it’s also part of a collective hive of agents with its own UI that lets me control all of them.

So moving from a single agent to a multi-agent system isn’t that different. It’s really about the collaboration piece—how they talk to each other and how orchestration works.

Simon Lacasse
Exactly. That’s really the key difference.

Samuel
I’m really interested in the white paper you mentioned. Make sure to share it.

Simon Lacasse
It’s an older one. The paper is called Designing Multi-Agent Systems, and it focuses on modularity and abstraction.

I use a drone example. At the bottom, you have drones executing tasks—fighting a fire in a forest. They only see a small part of the fire. Then you have other drones that control those drones, moving them to different sections of the forest where there’s more fire.

At the top, you have another drone coordinating the entire fleet, with a holistic view of the whole fire. It decides where the drones need to go to fight the fire effectively.

We actually built a computer-use agent based on that concept. It lets you control your computer using agents. You have agents that move your mouse, agents that type on your keyboard, and an agent that looks at your screen using a vision model.

Then you have another agent doing the planning. For example, if I’m searching on Amazon, the planner agent figures out the steps: go to the Amazon website, click here, type this, and so on.

When that hierarchy works together, you end up with a universal multi-agent solution that can browse the internet for you. It’s a really cool use case.

Samuel
This is a really cool use case. For a business leader who wants to implement multi-agent systems today, do you have a couple of real enterprise use cases you’ve already seen deployed that have had great business impact?

Simon Lacasse
Yeah, for sure. I see a lot of them. I design a lot of use cases around fraud detection, anomaly detection, and similar scenarios. Retail is a big one as well, especially hyper-personalization use cases.

One of my favorite multi-agent examples, and one that a lot of people can relate to, is GitHub Copilot. With the new wave of coding agents, when you enable agent mode, Copilot isn’t just completing code anymore. It’s planning, breaking problems down, running tests, fixing errors, and iterating across multi-step workflows.

That’s a full multi-agent pattern hiding in plain sight. As a developer, you don’t necessarily see that underneath the hood you have a planner agent, a coding agent, a testing agent, and a debugging agent. But that’s what’s happening.

That shift is already changing how developers operate. From my own experience, I use coding agents every day, and they’ve cut my development time by almost 50%. They free me up to focus on much higher-value work instead of repetitive tasks.

Samuel
I’m not a developer, so I didn’t realize GitHub Copilot was a multi-agent product at all.

Simon Lacasse
Yeah. When you put it in agent mode, it’s doing a lot of things. It’s essentially a reflection loop. Underneath the hood, you have grounded agents that are really good at debugging, grounded agents that are really good at writing code, and they’re combined to create that experience. It’s very powerful.

Samuel
You mentioned earlier that one of the reasons multi-agent systems are now ready to be deployed at scale is that the industry has agreed on some protocols. You mentioned A2A and MCP—agent-to-agent and Model Context Protocol. These come up a lot in your work and in your white paper.

Why are they so important, and what do they enable for organizations building agent ecosystems?

Simon Lacasse
That’s a great question. One of the biggest challenges right now is that most agents are still built in silos. There are many different technologies and ways for agents to communicate with each other, so every team builds their own thing, and everything becomes incompatible.

Each team has its own APIs and its own language, which makes integration—especially in multi-agent systems—very painful. It dramatically limits what you can do.

That’s where standard agent protocols like A2A and MCP come in. They break that pattern by giving agents a common way to communicate, discover each other, exchange work, and coordinate.

It’s like human collaboration. If I spoke to you in French, you’d understand, because you’re French. But in general, if we want to collaborate and do cool things together, we need to speak the same language. We also need a way to discover each other. I need to know what you can do so I can use you properly. I need to know how to give you the right task, and you need to do the same with me.

These protocols provide the core primitives for agents to talk to each other. It’s almost like creating a new HTTP protocol for agents, or a new TCP/IP layer for people of my generation.

They allow agents to exchange tasks in a seamless, standardized way across the industry. What that creates is a universal layer that turns disconnected agents into a unified network of agents that can all talk to each other.

For example, MCP standardizes internal reasoning and tool usage. It defines how agents call tools and take actions. A2A focuses on agent-to-agent communication and collaboration.

If you look at the A2A protocol, it includes tasks, messages, and artifacts so agents can exchange files and information. Everything is standardized.

What makes A2A particularly attractive is that it’s not a new proprietary transport layer. It’s built on top of the same standards that already power the internet—HTTP, JSON, RPC, and so on.

If your agent can speak the web and connect to the internet, it can speak A2A and MCP. That’s the beauty of these protocols. They sit on the same fabric we already use.

That’s what makes this wave different. It’s not a brand-new ecosystem. It’s a layer that connects the existing ecosystem with new agent technologies.

Samuel
In your white paper, you talk about discoverability for agents. So, for example, I could have a master agent that has access to multiple other agents or tools through A2A and MCP, and those agents would be discoverable. The orchestrator would be able to see what each agent is used for, what tools it has available, and what tasks it can accomplish, and then intelligently decide which one to call based on the task at hand. Am I understanding that correctly?

Simon Lacasse
That is definitely one pattern, and it’s one I really like and probably use the most. But there are many different topologies.

In some cases, you don’t even have an orchestrator. You let agents run freely and figure out what they need to do to solve the problem. Some systems are goal-oriented, some are not. There are many different ways to design these systems.

That said, the most popular pattern is definitely the orchestrator with agents underneath it. That gives you a layer for planning, reasoning, orchestration, and breaking down problems. That’s a pattern we see quite a lot.

Samuel
There’s a lot of confusion between A2A and MCP. A2A was created by Google, and MCP was created by Anthropic. Both can be used for multi-agent communication, but A2A is really meant for agent-to-agent communication, while MCP is also used for communication between agents and other software.

For example, many software vendors expose MCP servers—Dataverse, Dynamics 365, SAP, and others. Did I get that right?

Simon Lacasse
Yes, I think that’s generally right. It’s interesting because MCP is evolving quickly, and so is A2A.

I’ve seen people build multi-agent systems using only MCP as the protocol. But originally, the way I see it is that A2A is primarily for agent-to-agent communication, collaboration, and orchestration.

MCP, on the other hand, is more agent-to-system. It abstracts enterprise systems so agents can bring in the right context and tools to operate inside an organization.

Then, when you want to connect one agent to another agent, you use A2A for that communication. In practice, they complement each other very well.

Often, you’ll see systems where agents use MCP to connect to enterprise systems and A2A to connect to other agents. Both protocols coexist within the same architecture.

Samuel
Let’s say I’ve figured out which protocol I want to use, and I’ve identified my multi-agent use cases. Where do I start? What’s the first phase in terms of architecture and governance?

Simon Lacasse
There are many ways to start, but what I most often see—especially in large organizations—is a phased approach.

Organizations usually start very simply. They build one agent using a general-purpose model like GPT-4. Other people in the enterprise start using it, similar to how they might use ChatGPT.

The next phase is grounding that agent in company knowledge. How do you connect it to internal data so it understands your business and domain? Often, you see patterns like retrieval-augmented generation to bring that knowledge into the model so it can reason over domain-specific data.

At this point, it’s still a single agent. Then organizations extend it by adding tools and functions so the agent can take actions. For example, it might create tickets in ServiceNow or create leads in Salesforce.

Now the agent isn’t just consuming data—it’s producing data by taking actions in enterprise systems.

Once that works well, teams build a second agent, then a third. Before long, every team has its own agent project running in the enterprise.

That’s what we see today. Almost every time, those agents become silos because there’s no shared communication layer, no discovery, and no coordination or orchestration.

Eventually, leaders realize they don’t need more agents. They need a foundation that allows agents to collaborate and work together as part of a larger ecosystem.

That’s when things like common communication protocols, discoverability, and orchestration become critical.

Samuel
You mentioned agent catalogs. Which technology are you using for agent catalogs?

Simon Lacasse
There are different ways of implementing this. Microsoft has an agent registry on Azure that you can use.

What I’ve been focusing on is making the agent catalog standard. I want another enterprise to be able to connect to my agent catalog and use my agents. That’s why I adopt the A2A agent card.

The agent card is a well-defined JSON structure that describes what an agent can do. It includes the agent name, the HTTP endpoint, the skills the agent provides, security information, and role-based access controls.

That agent card can be used for discovery. Anyone can call the endpoint, retrieve the agent’s capabilities, and understand how to interact with it.

Often, what we do is persist that agent card in a cloud database, like Cosmos DB. That gives you a centralized cloud registry where other teams or organizations can discover and use agents.

You can have private catalogs—your personal list of agents. You can have department catalogs, for example, a content creation catalog with image generation agents. You can also have enterprise-wide catalogs where anyone can pick agents and build their own agent teams.

You can even have public catalogs, where different organizations share agents with each other. There’s a lot you can do there, and that could probably be the subject of another episode.

Samuel
From your experience working with some of the biggest customers, what are some misconceptions or fears you see from leaders who want to implement multi-agent systems, and how do you help them navigate those concerns?

Simon Lacasse
When we start talking about multi-agent systems, I usually hear the same concerns. People ask whether it’s going to be slower, whether it’s going to be more expensive, how token usage will look, and whether reliability will be predictable.

Those concerns are fair. Multi-agent systems introduce more moving parts, and models are probabilistic, which can make behavior feel unpredictable.

But without the right architecture and standards, systems can definitely feel heavy. What I tell leaders is that well-designed ecosystems don’t create chaos—they eliminate it.

By breaking systems into smaller, specialized agents, you increase reliability and control through tighter scoping. You can also reduce latency by running steps in parallel and using smaller, fine-tuned models, like small language models, instead of forcing one giant model to do everything.

With modularity, you can optimize each part independently instead of brute-forcing everything with a massive model that costs thousands of tokens.

When leaders see that multi-agent systems aren’t a leap of faith but a structured, measurable architecture, fear usually turns into excitement. They start to see what’s really possible and how much value they can get if they implement things properly.

Samuel
So would you recommend starting with a proof of concept, clearly defining the use case, and then going from there?

Simon Lacasse
Yes, usually that’s the case. Sometimes the proof of concept is just a single agent. You get that right first, then you create a couple more and stitch them together so they can work together. That’s the pattern I see most often.

Samuel
I have so many other questions, but we’re almost at the end of our time together, unfortunately. We’ll have to do a part two. My last two questions are my signature questions.

The first one is: if you had to share just one practical tip that helps you be more productive using AI in your day-to-day work, what would it be?

Simon Lacasse
I’d say always break your problems down into smaller problems. Don’t try to boil the ocean and cram everything into a giant prompt. Think about the problem and decompose it into substeps. That will give you much better responses.

Prompt engineering and context engineering are extremely powerful. If you don’t do them properly, you won’t get the output you want. You need to learn how to instruct these models clearly and give them the right context for the task.

You don’t want to be too vague, or it becomes very difficult to get good results. Overall, iterate and experiment. Keep your best prompts because you know they work. If something doesn’t work, try different models.

It’s really a craft. It’s about refining how you work with these systems to get better results.

Even more importantly, when you start designing more complex multi-agent systems, use standards. Use A2A and MCP protocols so you stay compliant and interoperable with everyone else.

If you build your own proprietary approach, you’ll get stuck in your own little world and won’t be able to connect to this broader ecosystem of agents and other people’s work.

Samuel
Last question. Looking ahead, how do you see AI reshaping the way we live and work over the next ten years?

Simon Lacasse
That’s a great question. It’s really hard to predict the future because things are changing so fast.

I think AI is going to fundamentally change the way we live and work—and it already has. It’s not about replacing people, but about surrounding us with intelligent collaborators.

I see a world where everyone has a team of specialized agents working with them. That could be a training agent that helps you go to the gym and monitor your health, or productivity agents that help with everyday tasks.

These teams of agents can handle the nitty-gritty work that we don’t want to do, which frees us up to focus on things we actually enjoy.

Instead of searching, clicking, and manually stitching systems together, we’ll simply state a goal and let our agents take care of the details.

That shifts the boundary between the physical and digital worlds. Planning trips, running a business, creating content—everything becomes easier.

Maybe this is just a stepping stone. Maybe one day we won’t need all of this because we’ll have a new fabric of agents that’s completely invisible to us, or maybe we’ll have one model to rule them all.

But until that day, I believe the future still belongs to humans and agents working together. I see that happening for a very long time. It’s a big human-and-agent collaboration, and while that’s exciting and a little scary, it’s exciting because we’ll be able to do a lot cooler things.

Samuel
I love it. On those words, Simon, thank you so much for joining us today. It’s been super insightful and super interesting. Thank you for joining us.

Simon Lacasse
No problem at all. It was my pleasure. Thank you for having me.