Aurimas Griciūnas's Linkedin Analytics

𝗠𝗖𝗣 𝘃𝘀. 𝗔𝟮𝗔 Two days ago Google announced an open A2A (Agent2Agent) protocol in an attempt to normalise how we implement multi-Agent system communication. As always, social media is going crazy about it, but why? Let’s review the differences and how both protocols complement each other (read till the end). 𝘔𝘰𝘷𝘪𝘯𝘨 𝘱𝘪𝘦𝘤𝘦𝘴 𝘪𝘯 𝘔𝘊𝘗: 𝟭. MCP Host - Programs using LLMs at the core that want to access data through MCP. ❗️ When combined with A2A, an Agent becomes MCP Host. 𝟮. MCP Client - Clients that maintain 1:1 connections with servers. 𝟯. MCP Server - Lightweight programs that each expose specific capabilities through the standardized Model Context Protocol. 𝟰. Local Data Sources - Your computer’s files, databases, and services that MCP servers can securely access. 𝟱. Remote Data Sources - External systems available over the internet (e.g., through APIs) that MCP servers can connect to. 𝘌𝘯𝘵𝘦𝘳 𝘈2𝘈: Where MCP falls short, A2A tries to help. In multi-Agent applications where state is not necessarily shared 𝟲. Agents (MCP Hosts) would implement and communicate via A2A protocol, that enables: ➡️ Secure Collaboration - MCP lacks authentication. ➡️ Task and State Management. ➡️ User Experience Negotiation. ➡️ Capability discovery - similar to MCP tools. 𝗛𝗼𝗻𝗲𝘀𝘁 𝘁𝗵𝗼𝘂𝗴𝗵𝘁𝘀: ❗️ I believe creators of MCP were planning to implement similar capabilities to A2A and expose agents via tools in long term. ❗️ We might just see a fight around who will win and become the standard protocol long term as both protocols might be expanding. Let me know your thoughts in the comments. 👇 #LLM #AI #MachineLearning

Sometimes 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁𝘀 might seem simple from the outside. They are not 👇 There are many moving pieces that production ready Agentic Systems rely on. I like to split the 𝗛𝗶𝗲𝗿𝗮𝗿𝗰𝗵𝘆 𝗼𝗳 𝗡𝗲𝗲𝗱𝘀 of an AI Agent according to the maturity of the product: 𝙋𝙊𝘾. We usually start building and experimenting with Raw Model APIs. These already rely on complex underlying infrastructure. ➡️ 𝘎𝘗𝘜/𝘊𝘗𝘜 Resources. ➡️ 𝘉𝘢𝘴𝘦 𝘐𝘯𝘧𝘳𝘢𝘴𝘵𝘳𝘶𝘤𝘵𝘶𝘳𝘦 that orchestrates Model deployment. Think Kubernetes, Slurm, vLLM. ➡️ 𝘍𝘰𝘶𝘯𝘥𝘢𝘵𝘪𝘰𝘯 𝘔𝘰𝘥𝘦𝘭𝘴 themselves that required tens of millions of dollars to be trained. 𝙈𝙑𝙋. To produce a reliable MVP you will need some internal data and stability to your system. This will require you to make choices in how you: ➡️ 𝘚𝘵𝘰𝘳𝘦 the data: Vector DBs, Graph DBs etc. ➡️ 𝘖𝘳𝘤𝘩𝘦𝘴𝘵𝘳𝘢𝘵𝘦 the system: LLM Orchestration frameworks help with solving issues like retries, chaining your prompts, tool calling etc. 𝘽𝙚𝙩𝙖. Scaling up for Beta requires more stability and insights into what is happening inside of the system. ➡️ 𝘔𝘰𝘥𝘦𝘭 𝘙𝘰𝘶𝘵𝘪𝘯𝘨 helps in choosing best LLMs for your prompts, prompt management, fallback mechanisms in case of unresponsive LLM APIs or hitting API limits. Etc. ➡️ 𝘓𝘓𝘔 𝘖𝘣𝘴𝘦𝘳𝘷𝘢𝘣𝘪𝘭𝘪𝘵𝘺 allows you to see into the actions your system is performing. You will need this for debugging and evolving your Agents. 𝙂𝘼. To expose your application to the general public you would need additional automations and guardrails to prevent disasters that could shut your business in seconds. ➡️ 𝘌𝘷𝘢𝘭𝘶𝘢𝘵𝘪𝘰𝘯 helps you to go beyond passively observing the system to proactively monitoring it by bringing automation via evaluation rules that are applied against steps performed by your Agents. ➡️ 𝘚𝘦𝘤𝘶𝘳𝘪𝘵𝘺 is critical to avoid disasters related to data leakage. Think Guardrails, Red Teaming etc. ❗️And these are just basic requirements, there is more 🙂 Come in the emerging requirements: ➡️ Memory. ➡️ Computer Use. ➡️ Complex integrations. (MCP!) ➡️ ... Would you order the moving pieces differently? Let me know in the comments 👇 #LLM #AI #MachineLearning