The infrastructure layer for agentic AI is moving fast. New protocols for agent identity, skill-sharing, and cross-platform communication launched this month. Meanwhile, a research paper from arXiv documented systematic numerical instability in large language models - the kind that breaks agents when precision matters.
The gap between infrastructure ambition and reliability reality is widening. We're building highways before we've figured out whether the cars can drive straight.
MCP Adoption Accelerates
The Model Context Protocol is gaining traction as a standard for how AI agents access external tools and data sources. Think of it as a universal adapter - instead of every model needing custom integrations for calendars, databases, and APIs, MCP provides a common interface.
The DEV.to analysis tracks adoption across major platforms. Companies are implementing MCP support not because it's perfect, but because the alternative - fragmented, one-off integrations - doesn't scale. Better to standardise on something imperfect than maintain dozens of custom connectors.
For builders, MCP means less plumbing work. You write one integration, and your agent can theoretically connect to any MCP-compatible service. The theory is ahead of the practice, but momentum is building.
AAIP: Agent Identity Gets a Protocol
The Agent-to-Agent Interaction Protocol launched this month, proposing a standard way for AI agents to identify themselves and verify permissions when communicating. It's early-stage, but the problem it addresses is real.
Right now, if one agent wants to talk to another agent, there's no standard handshake. No verification. No way to prove you are who you claim to be. AAIP proposes cryptographic identity for agents - a way to establish trust before exchanging data.
This matters most for multi-agent systems where different agents from different providers need to work together. Without identity verification, you can't build secure agent networks. With it, you can start imagining agents that safely delegate tasks to other agents without human oversight at every step.
The risk is premature standardisation. We're still figuring out what agents actually need to do. Locking in identity protocols now might constrain architectures we haven't imagined yet. But the counter-argument is strong: without some standard, we end up with siloed agent ecosystems that can't interoperate.
WebXSkill: Agents Learn From Each Other
WebXSkill proposes a shared repository where agents can publish and discover reusable skills. An agent learns how to extract data from PDFs, publishes that skill, and other agents can use it without retraining from scratch.
It's an appealing idea - accelerate agent development by sharing capabilities. The challenge is verification. How do you know a skill from the repository actually works as advertised? How do you prevent malicious skills from being distributed? How do you handle version conflicts when multiple agents rely on the same underlying skill?
These aren't theoretical concerns. In traditional software, dependency management and supply chain security are hard problems. For agents making autonomous decisions, the stakes are higher. A compromised skill could cause an agent to leak data, make incorrect decisions, or behave unpredictably.
WebXSkill is betting that the benefits of shared learning outweigh the security risks. Time will tell whether the ecosystem develops robust verification mechanisms or whether this becomes another vector for supply chain attacks.
The Numerical Instability Problem
A recent arXiv paper documented systematic numerical instability in large language models - situations where tiny changes in input produce wildly different outputs. Not the usual variability from temperature settings. Actual mathematical instability where the model's internal calculations produce inconsistent results.
For chatbots, this is mostly a nuisance. For agents making decisions based on numerical reasoning - calculating costs, optimising schedules, analysing financial data - it's a reliability problem. You can't build systems that handle money or safety-critical decisions on foundations that occasionally produce incorrect arithmetic.
The paper identifies specific patterns that trigger instability. Certain number ranges. Particular mathematical operations. Combinations of inputs that push the model into unstable regions of its parameter space. The instability isn't random - it's systematic and reproducible. Which means it can be tested for, but it also means it's baked into current architectures.
The Builder's Dilemma
Here's the tension: infrastructure is standardising before reliability is solved. MCP, AAIP, and WebXSkill are all betting that interoperability is more urgent than perfection. Get the pipes in place, improve reliability later.
That works if the problems are fixable without breaking the protocols. If numerical instability requires fundamental architecture changes, early protocol adoption might lock us into systems that can't scale to reliable autonomous operation.
For builders making decisions now, this creates a calculation problem. Do you adopt these protocols and risk building on shifting ground? Or do you wait for stability and risk being left behind when standards solidify?
The practical answer is probably selective adoption. Use MCP for non-critical integrations where reliability matters less than speed. Avoid delegating numerical reasoning to agents until the instability problem is better understood. Treat agent-to-agent communication as experimental, not production-ready.
What's Actually Ready
Despite the gaps, some parts of the agent infrastructure stack are solid enough for production use. Claude and GPT-4 can reliably handle structured tasks with human oversight. Tool-calling APIs work well for bounded operations. RAG systems are mature enough for most knowledge retrieval use cases.
The bleeding edge - autonomous multi-agent systems, unsupervised decision-making, cross-platform agent coordination - is where reliability breaks down. That's fine. Those capabilities are still experimental. The problem is when infrastructure protocols standardise around experimental capabilities before they're production-ready.
The protocol wars are real. Companies are racing to establish standards before the competition does. That creates pressure to ship protocols early, before all the edge cases are understood. For builders, that means careful evaluation of what's genuinely stable versus what's still moving fast.