1 00:00:00,000 --> 00:00:01,480 Welcome to another knowledge nugget. 2 00:00:01,480 --> 00:00:03,200 Imagine you run a company and hire a team 3 00:00:03,200 --> 00:00:05,920 of brilliant specialists, a world-class travel planner, 4 00:00:05,920 --> 00:00:09,280 an employee on boarding expert, and an IT support person. 5 00:00:09,280 --> 00:00:10,720 But none of them talk to each other. 6 00:00:10,720 --> 00:00:12,640 Every time a task needs two of them, 7 00:00:12,640 --> 00:00:13,960 you have to walk between desks 8 00:00:13,960 --> 00:00:15,680 and carry the information yourself. 9 00:00:15,680 --> 00:00:17,880 That's exactly how most AI agents work right now. 10 00:00:17,880 --> 00:00:19,280 They operate in isolation, 11 00:00:19,280 --> 00:00:21,320 even when the problem clearly needs teamwork. 12 00:00:21,320 --> 00:00:23,960 So today we're talking about how agents can communicate, 13 00:00:23,960 --> 00:00:26,200 hand off work, and act like real teams. 14 00:00:26,200 --> 00:00:27,120 I'm Mirko Peters. 15 00:00:27,120 --> 00:00:28,560 This isn't some future concept. 16 00:00:28,560 --> 00:00:30,920 Multi-agent orchestration is already happening, 17 00:00:30,920 --> 00:00:33,560 and it's powered by a protocol called A2A. 18 00:00:33,560 --> 00:00:34,720 We'll start with the problem, 19 00:00:34,720 --> 00:00:36,480 break down that protocol piece by piece, 20 00:00:36,480 --> 00:00:39,000 and see how Microsoft uses it inside co-pilot studio 21 00:00:39,000 --> 00:00:41,720 and Azure AI, grab your coffee, and let's dive in. 22 00:00:41,720 --> 00:00:43,160 So what's the actual problem? 23 00:00:43,160 --> 00:00:46,440 AI agents today are exactly like those isolated specialists. 24 00:00:46,440 --> 00:00:48,880 Each one has its own knowledge, tools, and goals. 25 00:00:48,880 --> 00:00:50,400 A weather agent knows the forecast. 26 00:00:50,400 --> 00:00:52,360 A hotel agent knows room availability, 27 00:00:52,360 --> 00:00:53,560 but they don't share anything. 28 00:00:53,560 --> 00:00:56,200 Now, picture a user asking for a trip to Seattle next week 29 00:00:56,200 --> 00:00:57,760 with a hotel near the office. 30 00:00:57,760 --> 00:00:59,760 A single agent would need to be a weather expert, 31 00:00:59,760 --> 00:01:02,280 travel expert, and local business expert, all at once. 32 00:01:02,280 --> 00:01:04,040 That means giant bloated prompts 33 00:01:04,040 --> 00:01:06,800 that cram every possible capability into one system, 34 00:01:06,800 --> 00:01:08,560 and those prompts break constantly. 35 00:01:08,560 --> 00:01:10,320 The old solution was custom code. 36 00:01:10,320 --> 00:01:12,360 You'd write a bridge between the weather agent 37 00:01:12,360 --> 00:01:15,000 and the hotel agent, then another between the hotel agent 38 00:01:15,000 --> 00:01:17,680 and the flight agent, and another for the calendar agent. 39 00:01:17,680 --> 00:01:19,840 It works at first, but every time you add a new agent, 40 00:01:19,840 --> 00:01:21,560 you build another integration. 41 00:01:21,560 --> 00:01:23,160 Pretty soon you've got a spaghetti nightmare 42 00:01:23,160 --> 00:01:25,600 of point-to-point connections, where one change breaks everything. 43 00:01:25,600 --> 00:01:27,920 The productivity gains your AI was supposed to deliver 44 00:01:27,920 --> 00:01:29,760 get eaten alive by maintenance work. 45 00:01:29,760 --> 00:01:31,480 Let's look at the real business pain. 46 00:01:31,480 --> 00:01:34,120 Your organization already has processes with handoffs. 47 00:01:34,120 --> 00:01:36,320 A ticket gets created, someone triages it, 48 00:01:36,320 --> 00:01:39,120 someone resolves it, someone logs it, and each step is a handoff. 49 00:01:39,120 --> 00:01:41,800 In the old world, you automate each step with a separate agent 50 00:01:41,800 --> 00:01:44,000 and then spend weeks wiring them together. 51 00:01:44,000 --> 00:01:45,240 But what if there was a protocol 52 00:01:45,240 --> 00:01:47,760 that let agents discover each other and cooperate 53 00:01:47,760 --> 00:01:49,320 without any custom bridges? 54 00:01:49,320 --> 00:01:50,680 That's exactly what A2A does. 55 00:01:50,680 --> 00:01:53,000 In plain English, A2A is a standard way for agents 56 00:01:53,000 --> 00:01:55,000 to talk to each other, pass work around, 57 00:01:55,000 --> 00:01:56,920 and get things done as a team. 58 00:01:56,920 --> 00:01:57,920 What is A2A? 59 00:01:57,920 --> 00:01:59,080 The simple definition. 60 00:01:59,080 --> 00:02:01,040 A2A stands for agent to agent. 61 00:02:01,040 --> 00:02:03,640 It's an open protocol that lets AI agents talk directly 62 00:02:03,640 --> 00:02:05,560 to each other, no matter who built them. 63 00:02:05,560 --> 00:02:07,520 You can think of it like HTTP for agents. 64 00:02:07,520 --> 00:02:10,720 HTTP is the language web browsers and servers used to communicate. 65 00:02:10,720 --> 00:02:12,800 And A2A does the same thing for agents. 66 00:02:12,800 --> 00:02:15,960 An agent built by your IT team on Microsoft Copilot Studio 67 00:02:15,960 --> 00:02:17,880 can talk to an agent built by a different company 68 00:02:17,880 --> 00:02:21,080 on Google Cloud as long as both speak A2A. 69 00:02:21,080 --> 00:02:22,720 This isn't a small project either. 70 00:02:22,720 --> 00:02:25,840 A2A is sponsored by eight major companies, including Google, 71 00:02:25,840 --> 00:02:29,520 Microsoft, Cisco, Salesforce, SAP, and others, 72 00:02:29,520 --> 00:02:31,520 and it's hosted by the Linux Foundation. 73 00:02:31,520 --> 00:02:34,720 Version 1.0 is stable and ready for real use, 74 00:02:34,720 --> 00:02:37,440 which means no single vendor controls the protocol. 75 00:02:37,440 --> 00:02:39,440 It's not a Google thing or a Microsoft thing. 76 00:02:39,440 --> 00:02:40,560 It's an industry thing. 77 00:02:40,560 --> 00:02:42,120 The design is intentionally simple. 78 00:02:42,120 --> 00:02:44,080 A2A builds on existing web standards 79 00:02:44,080 --> 00:02:46,200 like HTTP and JSON RPC. 80 00:02:46,200 --> 00:02:48,080 Things every developer already knows. 81 00:02:48,080 --> 00:02:49,960 Nothing exotic or proprietary there. 82 00:02:49,960 --> 00:02:52,120 That makes it easy for enterprises to adopt 83 00:02:52,120 --> 00:02:54,720 without ripping out their existing infrastructure. 84 00:02:54,720 --> 00:02:57,680 Now, you might have heard of another protocol called MCP, 85 00:02:57,680 --> 00:02:59,040 or ModelContext Protocol. 86 00:02:59,040 --> 00:03:00,000 Here's the difference. 87 00:03:00,000 --> 00:03:02,840 MCP is agent to tool, meaning it connects an agent 88 00:03:02,840 --> 00:03:04,800 to external data sources and APIs. 89 00:03:04,800 --> 00:03:08,400 A2A is agent to agent connecting agents directly to each other. 90 00:03:08,400 --> 00:03:09,280 They're not competitors. 91 00:03:09,280 --> 00:03:10,120 They're complementary. 92 00:03:10,120 --> 00:03:12,400 Think of MCP as the vertical connection 93 00:03:12,400 --> 00:03:14,400 from an agent down to its tools. 94 00:03:14,400 --> 00:03:19,000 And A2A as the horizontal connection between agents side by side. 95 00:03:19,000 --> 00:03:20,200 One more design choice. 96 00:03:20,200 --> 00:03:22,320 A2A treats agents as opaque. 97 00:03:22,320 --> 00:03:24,000 So when one agent talks to another, 98 00:03:24,000 --> 00:03:26,400 it doesn't see the other agents internal reasoning 99 00:03:26,400 --> 00:03:27,600 tools or private data. 100 00:03:27,600 --> 00:03:30,320 It only sees the task it sent and the result it gets back. 101 00:03:30,320 --> 00:03:32,600 That preserves privacy and intellectual property. 102 00:03:32,600 --> 00:03:34,080 A weather agent doesn't need to know 103 00:03:34,080 --> 00:03:35,840 how the hotel agent books rooms. 104 00:03:35,840 --> 00:03:37,360 It just needs to hand off the forecast. 105 00:03:37,360 --> 00:03:39,800 Now let's look at the first piece of the puzzle, 106 00:03:39,800 --> 00:03:41,560 the agent card. 107 00:03:41,560 --> 00:03:43,320 The agent card, the resume. 108 00:03:43,320 --> 00:03:47,080 Every A2A compatible agent publishes something called an agent card. 109 00:03:47,080 --> 00:03:49,040 That card is a machine readable document 110 00:03:49,040 --> 00:03:51,480 that lives at a standard URL on the agent's domain, 111 00:03:51,480 --> 00:03:56,440 specifically at PAS well known, agent card, Jason. 112 00:03:56,440 --> 00:03:57,560 If you know where an agent lives, 113 00:03:57,560 --> 00:04:00,480 you can fetch its card and learn everything you need to work with it. 114 00:04:00,480 --> 00:04:03,120 Think of the agent card as a resume or a business card. 115 00:04:03,120 --> 00:04:06,040 It tells other agents who you are and what you can do. 116 00:04:06,040 --> 00:04:08,320 The card contains the agent's name, 117 00:04:08,320 --> 00:04:11,040 a plain text description of its capabilities, 118 00:04:11,040 --> 00:04:13,400 and skill tags that help with discovery. 119 00:04:13,400 --> 00:04:16,400 It also lists the endpoint URL where it accepts requests, 120 00:04:16,400 --> 00:04:20,480 its authentication requirements, and the input and output formats it expects. 121 00:04:20,480 --> 00:04:21,640 Here's a concrete example. 122 00:04:21,640 --> 00:04:23,240 Say you have a weather specialist agent. 123 00:04:23,240 --> 00:04:25,840 Its agent card says, "I can provide current weather 124 00:04:25,840 --> 00:04:27,880 and a five-day forecast for any city. 125 00:04:27,880 --> 00:04:31,200 It lists its API endpoint, says it accepts a city name, 126 00:04:31,200 --> 00:04:34,080 and returns temperature and conditions in Jason format." 127 00:04:34,080 --> 00:04:34,920 That's the whole thing. 128 00:04:34,920 --> 00:04:37,320 It's just a clear declaration of what it can do 129 00:04:37,320 --> 00:04:39,800 with no secrets or internal logic exposed. 130 00:04:39,800 --> 00:04:41,240 Discovery works like this. 131 00:04:41,240 --> 00:04:44,160 An orchestrator agent has a list of known agent URLs 132 00:04:44,160 --> 00:04:45,840 or you can configure it with them 133 00:04:45,840 --> 00:04:48,400 when a task comes in, the orchestrator fetches the agent card, 134 00:04:48,400 --> 00:04:52,280 reads the descriptions, and decides which agent is the best match. 135 00:04:52,280 --> 00:04:54,800 The weather card says weather, so weather tasks go there. 136 00:04:54,800 --> 00:04:58,040 The hotel card says hotels, so hotel tasks go there. 137 00:04:58,040 --> 00:05:00,040 Notice there's no central registry required. 138 00:05:00,040 --> 00:05:02,680 Agents don't need to register with a global directory. 139 00:05:02,680 --> 00:05:05,120 They just publish their card at a known location, 140 00:05:05,120 --> 00:05:07,720 and any other agent that knows the URL can find them. 141 00:05:07,720 --> 00:05:08,960 That's a deliberate design choice 142 00:05:08,960 --> 00:05:11,400 that keeps the system decentralized and flexible. 143 00:05:11,400 --> 00:05:12,960 You can add a new specialist to your network 144 00:05:12,960 --> 00:05:14,640 by giving the orchestrator its URL 145 00:05:14,640 --> 00:05:16,400 and discovery happens automatically. 146 00:05:16,400 --> 00:05:18,360 So the orchestrator knows who's available, 147 00:05:18,360 --> 00:05:20,360 but how do they actually hand off work? 148 00:05:20,360 --> 00:05:22,360 How A to A communication works? 149 00:05:22,360 --> 00:05:24,720 So the orchestrator knows which agents are available 150 00:05:24,720 --> 00:05:27,200 through the agent card, but how do these agents 151 00:05:27,200 --> 00:05:29,040 actually hand off work to each other? 152 00:05:29,040 --> 00:05:30,240 The answer is simple. 153 00:05:30,240 --> 00:05:34,280 All communication happens over HTTP using Jason RPC messages. 154 00:05:34,280 --> 00:05:36,880 The same protocol that powers most web services today, 155 00:05:36,880 --> 00:05:38,360 nothing custom or complicated, 156 00:05:38,360 --> 00:05:41,000 just standard web traffic flowing between two agents. 157 00:05:41,000 --> 00:05:43,280 Here's the thing, not all tasks are the same. 158 00:05:43,280 --> 00:05:45,640 A to A supports three different interaction patterns 159 00:05:45,640 --> 00:05:46,920 depending on what you need. 160 00:05:46,920 --> 00:05:48,640 Instant response handles quick lookups 161 00:05:48,640 --> 00:05:50,880 where the remote agent can answer immediately. 162 00:05:50,880 --> 00:05:53,800 You send a request, it replies right away, and you are done. 163 00:05:53,800 --> 00:05:56,600 Asking a weather agent for today's forecast works exactly 164 00:05:56,600 --> 00:05:59,080 like this, a synchronous reply in and out. 165 00:05:59,080 --> 00:06:00,600 Streaming handles the longer tasks, 166 00:06:00,600 --> 00:06:04,000 maybe the specialist agent needs to search multiple databases 167 00:06:04,000 --> 00:06:05,800 or run a complex analysis. 168 00:06:05,800 --> 00:06:07,840 Instead of making you wait for a single response, 169 00:06:07,840 --> 00:06:09,600 the agent sends status updates as it works 170 00:06:09,600 --> 00:06:12,400 using server send events, you get progress reports along the way, 171 00:06:12,400 --> 00:06:14,320 and then the final result lands at the end. 172 00:06:14,320 --> 00:06:16,400 Tracking a package delivery works the same way. 173 00:06:16,400 --> 00:06:18,200 You see each step as it happens. 174 00:06:18,200 --> 00:06:20,560 Async notification handles the long running tasks 175 00:06:20,560 --> 00:06:23,800 where the remote agent might take minutes, hours, or even days. 176 00:06:23,800 --> 00:06:25,680 Employee onboarding is a good example. 177 00:06:25,680 --> 00:06:27,640 One specialist provisions IT accounts 178 00:06:27,640 --> 00:06:30,600 while another handles benefits enrollment over multiple days. 179 00:06:30,600 --> 00:06:33,560 The client agent submits a request, gets back at task ID 180 00:06:33,560 --> 00:06:35,000 and moves on with its work. 181 00:06:35,000 --> 00:06:37,760 Later, the remote agent sends the result through a web hook. 182 00:06:37,760 --> 00:06:39,560 The client can also check progress anytime 183 00:06:39,560 --> 00:06:41,200 by pulling that task ID. 184 00:06:41,200 --> 00:06:42,920 Every interaction follows the same structure 185 00:06:42,920 --> 00:06:44,160 all organized as a task. 186 00:06:44,160 --> 00:06:46,320 When the client sends a request, the remote agent 187 00:06:46,320 --> 00:06:48,680 creates a task and returns a task ID. 188 00:06:48,680 --> 00:06:51,680 That ID becomes the tracking handle for everything that follows. 189 00:06:51,680 --> 00:06:54,920 Messages inside that task have a role, telling you who sent it, 190 00:06:54,920 --> 00:06:58,240 and parts, which can be plain text, binary data 191 00:06:58,240 --> 00:07:01,720 like images or documents, JSON payloads, or URLs 192 00:07:01,720 --> 00:07:04,920 pointing to files stored elsewhere. 193 00:07:04,920 --> 00:07:07,240 Authentication follows standard web conventions, 194 00:07:07,240 --> 00:07:09,920 OAuth API keys, baritokens. 195 00:07:09,920 --> 00:07:12,080 The usual suspects, nothing new to learn here. 196 00:07:12,080 --> 00:07:14,360 The agent card tells the client which authentication method 197 00:07:14,360 --> 00:07:16,520 to use, and the client handles it the same way 198 00:07:16,520 --> 00:07:18,160 it would for any other API call. 199 00:07:18,160 --> 00:07:19,560 Here is how this looks in practice. 200 00:07:19,560 --> 00:07:22,080 Say the orchestrator needs weather data for a trip. 201 00:07:22,080 --> 00:07:23,680 It sends a task to the weather specialist. 202 00:07:23,680 --> 00:07:25,720 The weather specialist acknowledges the request, 203 00:07:25,720 --> 00:07:28,600 starts processing, and streams back progress updates. 204 00:07:28,600 --> 00:07:31,200 Fetching data, passing results. 205 00:07:31,200 --> 00:07:32,360 Done. 206 00:07:32,360 --> 00:07:34,120 Then it sends the final forecast. 207 00:07:34,120 --> 00:07:36,880 The orchestrator never sees the weather agent's internal tools, 208 00:07:36,880 --> 00:07:39,280 its API keys, or its reasoning process. 209 00:07:39,280 --> 00:07:40,640 It only sees the output. 210 00:07:40,640 --> 00:07:42,280 That is the key design principle. 211 00:07:42,280 --> 00:07:45,560 Clean boundaries between agents and no internal state leaking out. 212 00:07:45,560 --> 00:07:47,000 But A2A alone is not enough. 213 00:07:47,000 --> 00:07:49,720 You need a smart boss to coordinate all these specialists. 214 00:07:49,720 --> 00:07:52,600 That brings us to the orchestrator specialist pattern. 215 00:07:52,600 --> 00:07:56,000 The orchestrator specialist pattern, here is where everything connects. 216 00:07:56,000 --> 00:07:58,720 The orchestrator specialist pattern is the most common architecture 217 00:07:58,720 --> 00:08:00,520 in production multi-agent systems today. 218 00:08:00,520 --> 00:08:04,080 Think of it like a company with departments, IT, HR, finance, 219 00:08:04,080 --> 00:08:05,560 each handling its own area. 220 00:08:05,560 --> 00:08:07,880 You have a central decision maker that roots work 221 00:08:07,880 --> 00:08:11,760 to specialized teams, and each team focuses on what it does best. 222 00:08:11,760 --> 00:08:13,600 The orchestrator holds the big picture. 223 00:08:13,600 --> 00:08:16,680 It receives the user's request, figures out what needs to happen, 224 00:08:16,680 --> 00:08:19,120 and decides which specialist can handle each piece. 225 00:08:19,120 --> 00:08:22,000 If a user asks, plan a trip to Seattle next week, 226 00:08:22,000 --> 00:08:25,000 the orchestrator does not book flights or check hotels itself. 227 00:08:25,000 --> 00:08:27,720 It knows there is a flight specialist, a hotel specialist, 228 00:08:27,720 --> 00:08:29,120 and a weather specialist. 229 00:08:29,120 --> 00:08:32,080 It breaks the request into those pieces and delegates each one. 230 00:08:32,080 --> 00:08:33,960 Each specialist has a narrow focus. 231 00:08:33,960 --> 00:08:36,600 One agent handles flight booking, another handles hotel search, 232 00:08:36,600 --> 00:08:38,360 and a third handles incident triage. 233 00:08:38,360 --> 00:08:40,520 They do not need to know about each other's domains. 234 00:08:40,520 --> 00:08:43,280 The flight specialist knows airlines roots and pricing. 235 00:08:43,280 --> 00:08:45,600 It does not need to know anything about hotel room types 236 00:08:45,600 --> 00:08:47,240 or cancellation policies. 237 00:08:47,240 --> 00:08:50,480 That narrow focus keeps each agent simple, easy to maintain, 238 00:08:50,480 --> 00:08:51,560 and easy to test. 239 00:08:51,560 --> 00:08:52,720 Here is the important part. 240 00:08:52,720 --> 00:08:54,880 The orchestrator does not execute the tasks. 241 00:08:54,880 --> 00:08:56,720 It routes work and merges results. 242 00:08:56,720 --> 00:08:57,880 That is its only job. 243 00:08:57,880 --> 00:09:00,320 The orchestrator's role is to be a smartest patcher, 244 00:09:00,320 --> 00:09:02,480 not a super agent that tries to do everything. 245 00:09:02,480 --> 00:09:05,080 When you let the orchestrator start doing specialist work, 246 00:09:05,080 --> 00:09:06,880 you lose the whole benefit of the pattern. 247 00:09:06,880 --> 00:09:08,520 It becomes a monolithic mess again. 248 00:09:08,520 --> 00:09:09,720 Watch out for a common mistake. 249 00:09:09,720 --> 00:09:12,480 Some teams create overlapping specialist domains. 250 00:09:12,480 --> 00:09:14,960 Two agents both claim they can handle customer support 251 00:09:14,960 --> 00:09:18,120 or data lookup, which creates rooting confusion. 252 00:09:18,120 --> 00:09:20,040 The orchestrator does not know which one to pick 253 00:09:20,040 --> 00:09:22,080 and users get inconsistent results. 254 00:09:22,080 --> 00:09:23,400 The fix is straightforward. 255 00:09:23,400 --> 00:09:25,720 Each specialist owns a clearly bounded domain 256 00:09:25,720 --> 00:09:26,680 with no overlap. 257 00:09:26,680 --> 00:09:28,720 If two agents can do the same thing, merge them 258 00:09:28,720 --> 00:09:30,400 or split the domain more cleanly. 259 00:09:30,400 --> 00:09:33,400 Microsoft's co-pilot studio uses this pattern natively. 260 00:09:33,400 --> 00:09:35,360 Your main co-pilot acts as the orchestrator 261 00:09:35,360 --> 00:09:38,000 while child agents and connected agents act as specialists. 262 00:09:38,000 --> 00:09:40,760 When a user asks something that spans multiple domains, 263 00:09:40,760 --> 00:09:43,400 the main co-pilot delegates to the right specialists 264 00:09:43,400 --> 00:09:44,280 through A2A. 265 00:09:44,280 --> 00:09:45,560 It is built into the platform, 266 00:09:45,560 --> 00:09:47,680 so you do not have to code the orchestration logic 267 00:09:47,680 --> 00:09:48,600 from scratch. 268 00:09:48,600 --> 00:09:50,520 The big benefit here is modularity. 269 00:09:50,520 --> 00:09:52,640 Need to swap out your hotel booking provider, 270 00:09:52,640 --> 00:09:54,400 replace the hotel specialist without touching 271 00:09:54,400 --> 00:09:56,280 the orchestrator or any other agent. 272 00:09:56,280 --> 00:09:58,640 Adding a new capability, build a new specialist, 273 00:09:58,640 --> 00:10:00,960 register it with the orchestrator and you are done. 274 00:10:00,960 --> 00:10:04,680 Each agent stays small, manageable and independently deployable. 275 00:10:04,680 --> 00:10:07,080 That is the whole point of moving from monolithic agents 276 00:10:07,080 --> 00:10:08,320 to a multi-agent system. 277 00:10:08,320 --> 00:10:10,600 So we have the protocol, the agent cards and the pattern. 278 00:10:10,600 --> 00:10:13,440 Let us see it in action with real scenarios. 279 00:10:13,440 --> 00:10:15,240 Real examples of A2A in action. 280 00:10:15,240 --> 00:10:17,840 So what does A2A actually look like in the real world? 281 00:10:17,840 --> 00:10:19,480 Let's start with a simple example. 282 00:10:19,480 --> 00:10:23,280 You tell your AI assistant, plan a trip to Seattle next week. 283 00:10:23,280 --> 00:10:24,600 In the old way of doing things, 284 00:10:24,600 --> 00:10:26,880 that single assistant would have to know everything. 285 00:10:26,880 --> 00:10:30,480 Weather, flights, hotels, restaurants, all at once. 286 00:10:30,480 --> 00:10:31,960 That is a lot to ask from one prompt. 287 00:10:31,960 --> 00:10:34,160 With A2A, the orchestrator breaks it down. 288 00:10:34,160 --> 00:10:35,800 It sends a task to a weather specialist 289 00:10:35,800 --> 00:10:38,160 asking for the forecast for those specific days. 290 00:10:38,160 --> 00:10:40,360 At the same time, it asks a flight specialist 291 00:10:40,360 --> 00:10:43,560 to find flights arriving Tuesday morning, returning Thursday evening 292 00:10:43,560 --> 00:10:45,520 and a hotel specialist to search for places 293 00:10:45,520 --> 00:10:47,840 near downtown Seattle for three nights. 294 00:10:47,840 --> 00:10:49,800 Each specialist works independently 295 00:10:49,800 --> 00:10:51,880 and they don't need to talk to the other agents 296 00:10:51,880 --> 00:10:55,280 because they each have their own data sources, tools and expertise. 297 00:10:55,280 --> 00:10:56,960 The orchestrator collects all the results 298 00:10:56,960 --> 00:10:59,320 and merges them into one response. 299 00:10:59,320 --> 00:11:01,320 The user sees a single answer. 300 00:11:01,320 --> 00:11:02,240 Here is the forecast. 301 00:11:02,240 --> 00:11:03,360 These are your flight options 302 00:11:03,360 --> 00:11:05,360 and here are three hotels near the office. 303 00:11:05,360 --> 00:11:08,000 Behind the scenes, three separate agents work together 304 00:11:08,000 --> 00:11:10,400 without any custom integration code. 305 00:11:10,400 --> 00:11:12,880 Now a business scenario, say a ticket comes in, 306 00:11:12,880 --> 00:11:15,080 my laptop won't connect to the VPN. 307 00:11:15,080 --> 00:11:17,600 The orchestrator figures, this is a network issue. 308 00:11:17,600 --> 00:11:19,880 It hands the ticket to a runbook specialist 309 00:11:19,880 --> 00:11:21,800 that knows the standard steps. 310 00:11:21,800 --> 00:11:25,200 Check VPN client status, verify network credentials, 311 00:11:25,200 --> 00:11:26,640 restart the service. 312 00:11:26,640 --> 00:11:28,240 That specialist returns the steps. 313 00:11:28,240 --> 00:11:30,120 Then the orchestrator passes the result 314 00:11:30,120 --> 00:11:31,520 to a ticket writer specialist 315 00:11:31,520 --> 00:11:33,280 that logs the resolution in the system. 316 00:11:33,280 --> 00:11:36,000 All this happens in seconds without a human touching it 317 00:11:36,000 --> 00:11:37,880 and the IT team only gets involved 318 00:11:37,880 --> 00:11:40,160 if the automated steps don't fix the problem. 319 00:11:40,160 --> 00:11:42,120 Employee onboarding is another example 320 00:11:42,120 --> 00:11:44,240 but this one takes days, not seconds, 321 00:11:44,240 --> 00:11:46,080 a new hire joins the company. 322 00:11:46,080 --> 00:11:48,280 The orchestrator triggers an IT specialist 323 00:11:48,280 --> 00:11:50,200 to create accounts and a sign hardware 324 00:11:50,200 --> 00:11:51,680 which might take a few hours. 325 00:11:51,680 --> 00:11:53,960 At the same time, it triggers an HR benefit specialist 326 00:11:53,960 --> 00:11:55,200 for enrollment forms 327 00:11:55,200 --> 00:11:58,240 and later a facility specialist for desk and badge access. 328 00:11:58,240 --> 00:12:01,400 Each specialist runs its own long running task independently 329 00:12:01,400 --> 00:12:03,000 and the orchestrator tracks progress 330 00:12:03,000 --> 00:12:05,280 using those task IDs we talked about earlier. 331 00:12:05,280 --> 00:12:07,880 So if the IT specialist finishes the orchestrator knows 332 00:12:07,880 --> 00:12:10,640 and if the facility specialist is delayed, it can follow up. 333 00:12:10,640 --> 00:12:12,800 The user sees one smooth onboarding flow 334 00:12:12,800 --> 00:12:15,120 but behind the scenes, it is a coordinated team 335 00:12:15,120 --> 00:12:16,240 working over multiple days 336 00:12:16,240 --> 00:12:18,920 and this isn't just theory, Coca-Cola beverages. 337 00:12:18,920 --> 00:12:21,280 Africa is already using co-pilot studio agents 338 00:12:21,280 --> 00:12:24,200 with Dynamics 365 to automate planning cycles. 339 00:12:24,200 --> 00:12:26,200 Their planners use to spend up to an hour and a half 340 00:12:26,200 --> 00:12:28,080 every day on repetitive tasks. 341 00:12:28,080 --> 00:12:30,880 With multi-agent orchestration, those cycles run on their own. 342 00:12:30,880 --> 00:12:33,040 The orchestrator delegates to specialists 343 00:12:33,040 --> 00:12:36,000 that handle different parts of the supply chain planning process. 344 00:12:36,000 --> 00:12:38,760 The result is over an hour saved per person per day 345 00:12:38,760 --> 00:12:40,720 just by letting agents talk to each other 346 00:12:40,720 --> 00:12:43,560 instead of making humans carry information between systems. 347 00:12:43,560 --> 00:12:45,920 So the pattern is the same in all these examples. 348 00:12:45,920 --> 00:12:47,760 Each agent is a self-contained expert 349 00:12:47,760 --> 00:12:50,240 that knows its own domain and has its own tools 350 00:12:50,240 --> 00:12:52,800 and it doesn't need to know anything about the other agents. 351 00:12:52,800 --> 00:12:54,880 A2A provides a simple communication layer 352 00:12:54,880 --> 00:12:57,080 so they can cooperate without custom code. 353 00:12:57,080 --> 00:13:00,000 You get a standard protocol and a smart orchestrator 354 00:13:00,000 --> 00:13:02,480 with no bridges, no point-to-point integrations 355 00:13:02,480 --> 00:13:03,960 and no maintenance headaches. 356 00:13:03,960 --> 00:13:05,320 Microsoft has been all in on this. 357 00:13:05,320 --> 00:13:08,440 Let's see where co-pilot studio and Azure AI fit in. 358 00:13:08,440 --> 00:13:12,120 Microsoft's ecosystem, co-pilot studio and Azure AI. 359 00:13:12,120 --> 00:13:13,920 So where does Microsoft sit in all this? 360 00:13:13,920 --> 00:13:15,000 Right at the center. 361 00:13:15,000 --> 00:13:17,680 Co-pilot studio now supports A2A natively 362 00:13:17,680 --> 00:13:20,720 and it has been generally available since April, 2026. 363 00:13:20,720 --> 00:13:22,240 That is not a preview or a beta. 364 00:13:22,240 --> 00:13:25,280 It is production ready and any eligible customer can use it today. 365 00:13:25,280 --> 00:13:27,760 Here is the thing, you can connect external agents 366 00:13:27,760 --> 00:13:29,520 to your co-pilot studio orchestrator. 367 00:13:29,520 --> 00:13:32,320 When I say external, I mean truly external. 368 00:13:32,320 --> 00:13:35,960 Agents built on Google Cloud, AWS or any other platform 369 00:13:35,960 --> 00:13:37,680 that supports the A2A protocol. 370 00:13:37,680 --> 00:13:39,680 The orchestrator doesn't care where the agent lives 371 00:13:39,680 --> 00:13:41,480 or what framework it was built with. 372 00:13:41,480 --> 00:13:43,680 As long as it speaks A2A, it can join the team. 373 00:13:43,680 --> 00:13:44,960 The setup is simple. 374 00:13:44,960 --> 00:13:48,400 In co-pilot studio, you create something called a connected agent. 375 00:13:48,400 --> 00:13:50,560 You paste in the agent's endpoint URL, 376 00:13:50,560 --> 00:13:52,920 co-pilot studio automatically fetches the agent card 377 00:13:52,920 --> 00:13:55,640 from that URL, which is the perhaps well-known agent card 378 00:13:55,640 --> 00:13:57,160 Jason file we talked about. 379 00:13:57,160 --> 00:13:59,320 It reads the agent's capabilities, 380 00:13:59,320 --> 00:14:02,160 authentication requirements and input and output formats. 381 00:14:02,160 --> 00:14:04,600 Then it builds a custom connector behind the scenes 382 00:14:04,600 --> 00:14:07,320 and your orchestrator can start delegating tasks immediately. 383 00:14:07,320 --> 00:14:10,000 You don't need manual integration work or custom code, 384 00:14:10,000 --> 00:14:11,960 just paste the URL and you are done. 385 00:14:11,960 --> 00:14:14,280 On the Azure side, Azure AI Foundry agent service 386 00:14:14,280 --> 00:14:15,640 also supports A2A. 387 00:14:15,640 --> 00:14:18,040 It has a dedicated A2A API endpoint 388 00:14:18,040 --> 00:14:20,360 that lets open source orchestrators like AutoGen, 389 00:14:20,360 --> 00:14:23,080 Langchain and Semantic kernel invoke Foundry agents. 390 00:14:23,080 --> 00:14:25,520 So if you have built agents using those frameworks, 391 00:14:25,520 --> 00:14:27,680 you can plug them into the Microsoft ecosystem 392 00:14:27,680 --> 00:14:28,920 without rewriting anything. 393 00:14:28,920 --> 00:14:29,920 It is a two way street. 394 00:14:29,920 --> 00:14:32,560 Microsoft follows the same orchestrator specialist pattern 395 00:14:32,560 --> 00:14:33,760 we have been describing. 396 00:14:33,760 --> 00:14:36,680 The main agent in co-pilot studio acts as the orchestrator 397 00:14:36,680 --> 00:14:39,360 while child agents and connected agents are the specialists. 398 00:14:39,360 --> 00:14:40,960 Each one handles its own domain 399 00:14:40,960 --> 00:14:42,920 and the orchestrator roots and merges. 400 00:14:42,920 --> 00:14:45,840 It is the same architecture just running on Microsoft's platform. 401 00:14:45,840 --> 00:14:47,840 But here's the thing, there are some limitations 402 00:14:47,840 --> 00:14:48,920 you need to know about. 403 00:14:48,920 --> 00:14:51,760 First, every extra orchestration hop adds latency. 404 00:14:51,760 --> 00:14:54,080 If your main agent calls a connected agent 405 00:14:54,080 --> 00:14:56,080 and that connected agent calls another specialist, 406 00:14:56,080 --> 00:14:57,840 each hop adds network time. 407 00:14:57,840 --> 00:14:59,120 For real time conversations, 408 00:14:59,120 --> 00:15:01,720 too many hops can make the experience feel sluggish. 409 00:15:01,720 --> 00:15:04,480 Second, over-delegation creates routing chaos. 410 00:15:04,480 --> 00:15:07,120 If you have too many specialists with overlapping domains, 411 00:15:07,120 --> 00:15:09,640 the orchestrator starts making bad rooting decisions. 412 00:15:09,640 --> 00:15:11,560 So keep your specialist count manageable 413 00:15:11,560 --> 00:15:13,840 and your domains clearly separated. 414 00:15:13,840 --> 00:15:17,120 Third, there is a specific limitation with fabric data agents. 415 00:15:17,120 --> 00:15:19,120 They don't work when the main agent is deployed 416 00:15:19,120 --> 00:15:21,160 to Microsoft 365 co-pilot. 417 00:15:21,160 --> 00:15:24,080 If your deployment targets M365 plan accordingly, 418 00:15:24,080 --> 00:15:26,320 these constraints are real, but they are manageable. 419 00:15:26,320 --> 00:15:28,920 The platform is mature enough for production use 420 00:15:28,920 --> 00:15:31,920 and Microsoft is actively working on closing these gaps. 421 00:15:31,920 --> 00:15:34,440 Now let's connect the dots and see the big picture. 422 00:15:34,440 --> 00:15:37,000 Connection section, how it all fits together. 423 00:15:37,000 --> 00:15:39,320 Let's step back and see how these pieces connect. 424 00:15:39,320 --> 00:15:42,640 A2A is the phone system agents use to call each other. 425 00:15:42,640 --> 00:15:44,280 The agent cards, that's your phone book. 426 00:15:44,280 --> 00:15:46,680 They show you who to call and what each agent handles. 427 00:15:46,680 --> 00:15:48,040 The orchestrator is the receptionist 428 00:15:48,040 --> 00:15:49,960 that routes each call to the right department. 429 00:15:49,960 --> 00:15:51,320 None of these pieces work alone. 430 00:15:51,320 --> 00:15:52,320 You need all three. 431 00:15:52,320 --> 00:15:54,240 Without a phone book, you don't know who to call. 432 00:15:54,240 --> 00:15:57,400 Without a receptionist, nobody directs traffic. 433 00:15:57,400 --> 00:16:00,600 And without a phone system, a receptionist can't connect anyone. 434 00:16:00,600 --> 00:16:03,280 They only work as a team, but that's where modularity comes in. 435 00:16:03,280 --> 00:16:04,720 When your specialists are modular, 436 00:16:04,720 --> 00:16:06,040 you can add new capabilities 437 00:16:06,040 --> 00:16:07,640 without breaking what's already working. 438 00:16:07,640 --> 00:16:09,560 Say you want to add a car rental specialist 439 00:16:09,560 --> 00:16:11,120 to your travel assistant, you build it, 440 00:16:11,120 --> 00:16:12,240 you publish its agent card, 441 00:16:12,240 --> 00:16:14,080 you give the orchestrator its URL. 442 00:16:14,080 --> 00:16:14,680 Done. 443 00:16:14,680 --> 00:16:17,720 The flight specialist and hotel specialists stay exactly the same. 444 00:16:17,720 --> 00:16:19,360 The orchestrator doesn't change either. 445 00:16:19,360 --> 00:16:22,280 You just plug in a new piece and the system adapts. 446 00:16:22,280 --> 00:16:25,280 Because the protocol is open, you never get stuck with one vendor. 447 00:16:25,280 --> 00:16:27,560 Your orchestrator can run on co-pilot studio. 448 00:16:27,560 --> 00:16:29,440 Your weather agent can live on Google Cloud. 449 00:16:29,440 --> 00:16:31,560 Your hotel agent can be on AWS. 450 00:16:31,560 --> 00:16:33,560 Your internal systems can stay on Azure. 451 00:16:33,560 --> 00:16:35,200 They all speak the same language. 452 00:16:35,200 --> 00:16:37,040 That's the beauty of an open standard. 453 00:16:37,040 --> 00:16:38,200 It prevents vendor lock-in 454 00:16:38,200 --> 00:16:40,320 and lets you pick the best tool for each job. 455 00:16:40,320 --> 00:16:43,440 A2A isn't about building one super smart agent that knows everything. 456 00:16:43,440 --> 00:16:45,680 It's about building a flexible workforce of specialists 457 00:16:45,680 --> 00:16:47,440 you can rearrange as your needs change. 458 00:16:47,440 --> 00:16:49,600 You don't replace your agents, you rearrange them, 459 00:16:49,600 --> 00:16:52,080 you add new ones, you swap old ones out. 460 00:16:52,080 --> 00:16:54,720 The system grows with you instead of becoming a bottleneck. 461 00:16:54,720 --> 00:16:57,000 So what can you do with this knowledge today? 462 00:16:57,000 --> 00:16:58,160 Actionable takeaways. 463 00:16:58,160 --> 00:16:59,040 Starts more. 464 00:16:59,040 --> 00:17:01,440 Pick one repetitive process in your organization 465 00:17:01,440 --> 00:17:03,320 that involves multiple systems. 466 00:17:03,320 --> 00:17:05,600 Ticket resolution, employee onboarding 467 00:17:05,600 --> 00:17:07,320 or expense reporting, for example, 468 00:17:07,320 --> 00:17:09,520 something with clear handoffs between steps. 469 00:17:09,520 --> 00:17:12,480 Then build a prototype with one orchestrator and two specialists. 470 00:17:12,480 --> 00:17:13,960 You don't need a grand architecture. 471 00:17:13,960 --> 00:17:16,320 You just need a working example you can learn from. 472 00:17:16,320 --> 00:17:18,320 Use the tools that already support this. 473 00:17:18,320 --> 00:17:20,520 Copilot Studio has built an A2A support. 474 00:17:20,520 --> 00:17:22,120 Azure AI Foundry has it too. 475 00:17:22,120 --> 00:17:23,840 You don't need to build the protocol from scratch 476 00:17:23,840 --> 00:17:25,760 or write custom integration code. 477 00:17:25,760 --> 00:17:29,280 Paste a URL, configure your agents and start delegating. 478 00:17:29,280 --> 00:17:30,640 Watch for common pitfalls. 479 00:17:30,640 --> 00:17:32,760 Keep your specialist domains from overlapping. 480 00:17:32,760 --> 00:17:34,320 If two agents can do the same thing, 481 00:17:34,320 --> 00:17:36,280 merge them or split the domain more cleanly. 482 00:17:36,280 --> 00:17:38,920 Let the orchestrator handle routing, not execution. 483 00:17:38,920 --> 00:17:40,880 And watch for latency from orchestration hops. 484 00:17:40,880 --> 00:17:42,520 If your response time start creeping up, 485 00:17:42,520 --> 00:17:44,600 you might have too many layers of delegation. 486 00:17:44,600 --> 00:17:46,040 The best first step is simple. 487 00:17:46,040 --> 00:17:48,440 Map out the handoffs in your existing workflow. 488 00:17:48,440 --> 00:17:50,440 Where does information get passed between people 489 00:17:50,440 --> 00:17:51,320 or between systems? 490 00:17:51,320 --> 00:17:53,320 Those are the spots where agents can take over. 491 00:17:53,320 --> 00:17:55,360 Every handoff is an opportunity. 492 00:17:55,360 --> 00:17:58,000 So that's the A2A system in a nutshell. 493 00:17:58,000 --> 00:18:00,040 Three simple pieces working together. 494 00:18:00,040 --> 00:18:02,960 Agent stop being isolated and start acting like a real team. 495 00:18:02,960 --> 00:18:05,960 Pick one workflow with clear handoffs and build from there. 496 00:18:05,960 --> 00:18:07,760 Subscribe for more plain English breakdowns 497 00:18:07,760 --> 00:18:10,480 and drop a comment if anything clicked.