Every technology wave eventually produces a stack diagram. Someone draws boxes on a whiteboard, labels them with layer names, and argues about where the boundaries should go. Then other people disagree about the boundaries, draw their own diagrams, and a productive mess follows until the industry settles on something roughly consensus.
We're in the productive mess phase for agent infrastructure right now. I'm going to draw my version of the diagram, fully aware that I'll get some of it wrong and that my perspective is biased by what we're building at SocioLogic. Take this as one informed opinion, not gospel.
The Five Layers
As I see it, the agent infrastructure stack has five layers. Bottom to top:
- Transport
- Discovery
- Payments
- Verification
- Orchestration
Each layer solves a different problem. Each has different maturity levels. Some have clear winners. Some are wide open. Let me walk through them.
Layer 1: Transport
The problem: How does one agent talk to another?
The answer, for now: MCP (Model Context Protocol).
Anthropic released MCP in late 2024, and it's become the de facto standard for agent-to-tool communication. An MCP client (the AI agent) connects to an MCP server (the tool or service), discovers what tools are available, and invokes them with structured arguments. JSON-RPC transport. Streaming support. Capability negotiation on connect.
MCP is the layer I'm most confident about. It works. It's well-designed. It's open. Multiple implementations exist across languages. The spec is actively maintained and improving.
There are competitors. The Agent Protocol from e2b. Various custom RPC schemes that individual companies have built. But MCP has enough momentum that I'd bet on it remaining dominant through at least 2027. The network effects of a shared transport protocol are strong, and MCP got there first with a good enough design.
What's still missing at this layer: better security primitives (sandboxing, capability restrictions), standardized error handling across implementations, and performance optimization for high-frequency agent-to-agent calls. These are solvable engineering problems, not design flaws.
Layer 2: Discovery
The problem: How does an agent find a service it hasn't been pre-configured to use?
The answer: Nobody has won this yet.
This is the layer I find most interesting and most underserved. MCP tells you how to talk to a service. It doesn't tell you how to find one. Right now, "discovery" means a human reads a GitHub README and pastes a URL into a config file. That's fine for developer tooling. It's a dead end for autonomous agents.
There are a few approaches emerging. We're building a verified agent registry at SocioLogic. Agents publish structured metadata (agent cards at /.well-known/agent.json), and other agents can search the registry by capability. ACI.dev has a similar registry concept. There are open-source efforts like the Agent Directory project that take a more decentralized approach.
The DNS analogy keeps coming up in discussions about discovery, and I think it's apt. DNS didn't try to be a single centralized directory. It was a federated protocol that any name server could implement. I suspect agent discovery will end up similarly federated: multiple registries that interoperate through a shared protocol, rather than one registry to rule them all.
We haven't built that federation protocol yet. Nobody has. It's one of the biggest gaps in the stack. We're building a single registry first and planning to federate later, which is either pragmatic or naive depending on who you ask.
Layer 3: Payments
The problem: How does an agent pay for services without human intervention for each transaction?
The answer, for the agent-native crowd: x402.
x402 takes the long-dormant HTTP 402 status code ("Payment Required") and gives it actual semantics. A service responds with 402 and a price. The agent pays with USDC on Base. The transaction settles on-chain. Sub-second, sub-cent gas fees, no accounts or API keys needed.
I'm biased here because we use x402 for all our paid services. But I also think the logic holds independently: agents need to make spending decisions in real time, without pre-establishing billing relationships with every service they might use. Per-call payments on cheap rails are the natural fit.
The alternatives are traditional billing (API keys tied to accounts, monthly invoices) which requires human setup and doesn't work for autonomous discovery, and various token-based schemes that require buying a specific cryptocurrency. USDC avoids the volatility problem, and Base avoids the gas cost problem. The combo is good enough to build on.
Where payments are still weak: refund mechanisms (on-chain payments are final), fiat onramps for non-crypto users, and regulatory clarity. The "your grandma can't buy USDC to fund an agent wallet" problem is real and unsolved. Custodial solutions will probably bridge this gap, but they add a trust dependency that partially defeats the purpose of on-chain payments.
Layer 4: Verification
The problem: How does an agent know a service is legitimate and does what it claims?
The answer: Early and varied.
This layer is less mature than I'd like. The web has TLS certificates and certificate authorities. Package managers have code signing and verified publishers. The agent world has... not much yet.
At SocioLogic, we run smoke tests on registered agents, verify the identity of the entity behind each service, and continuously check that agents respond and behave as advertised. Our registry marks agents as verified or unverified, and clients can filter accordingly.
Other approaches exist. Some teams are using blockchain-based reputation systems where agents accumulate trust scores from interactions. Others are using traditional PKI (public key infrastructure) to sign agent cards. A few are exploring zero-knowledge proofs for capability attestation, which is theoretically interesting but I haven't seen it work in production.
The honest assessment: verification for agent services is roughly where SSL was in 1998. We know we need it. We have some early implementations. The standards haven't consolidated. Most people are still connecting to services without checking anything, and they'll keep doing that until something bad enough happens to change behavior.
Layer 5: Orchestration
The problem: How do you coordinate multi-agent workflows across service boundaries?
The answer: Nobody's close.
MCP is point-to-point. Agent A calls Agent B. But real workflows involve chains: Agent A calls B, passes the result to C, aggregates with output from D, makes a decision, and routes to E or F. Error handling, retries, fallbacks, budget tracking across the whole chain. This is orchestration, and there's no standard for it.
Today, orchestration lives in application code. Developers write Python scripts or TypeScript that call MCP tools in sequence and handle the control flow. Frameworks like LangGraph, CrewAI, and AutoGen provide patterns for this, but they're opinionated application frameworks, not protocol-level standards.
I don't think orchestration will standardize as quickly as transport did. The patterns are more varied. A research pipeline has different orchestration needs than a trading bot or a customer service workflow. We'll probably see orchestration frameworks proliferate for a few years before any common abstractions emerge.
What I do expect: the orchestration layer will need built-in budget management (how much can this workflow spend in total?), cross-service error handling (if step 3 fails, what happens to the payments from steps 1 and 2?), and observability (what did this workflow do, and how long did each step take?). Whoever solves those three problems well will have a popular orchestration framework.
Where the Gaps Are Biggest
If I rank the layers by maturity: Transport is solid. Payments are functional. Verification is early. Discovery is nascent. Orchestration is the wild west.
The two gaps that worry me most:
Discovery-to-payments integration. An agent should be able to discover a service, check the price, and pay for it in one seamless flow. Right now, discovery and payments are separate systems with separate protocols. Bridging them cleanly is harder than it sounds, because the discovery layer needs to present pricing information in a format the payment layer can act on, and the payment layer needs to know which discovered service it's paying. We've built this bridge in our system, but there's no standard for it.
Cross-layer security. Each layer has its own security concerns, but attacks often span layers. A malicious service might pass verification checks (layer 4) but manipulate orchestration behavior (layer 5) by returning tool responses that contain prompt injection. Defending against cross-layer attacks requires coordination between layers that doesn't exist yet.
Where SocioLogic Fits (Honestly)
We're not building the whole stack. Nobody should try. Here's what we actually do:
Registry + Discovery: The Verified Agent Registry. Agents register, we verify them, other agents search and discover. This is our core infrastructure bet.
Payments: We integrate x402 for all our services and support it in our CLI. We didn't build x402 itself. We adopted it and built tooling around it.
Verification: We verify agents in our registry through smoke testing, identity checks, and continuous monitoring. This is tightly coupled with our registry layer.
Transport: We use MCP. We run Signal Relay, an MCP server that bridges to our infrastructure. We didn't build MCP. We implement it.
Orchestration: We don't have an orchestration product. Users bring their own. OpenClaw, Claude, custom scripts. We're a node in their workflows, not the workflow engine.
That positioning is deliberate. Trying to own every layer means doing all of them poorly. We'd rather be good at registry, discovery, and verification and let other teams own transport and orchestration.
Predictions for 2026
I'll go out on some limbs:
MCP remains the dominant transport protocol through 2026. Alternatives exist but don't gain critical mass. The MCP spec adds optional extension points for payments and verification but doesn't mandate specific implementations.
At least three major agent registries launch. Interoperability between them is poor initially but becomes a priority by late 2026 when developers get tired of registering the same agent in multiple places.
x402 becomes the default payment mechanism for agent-to-agent transactions under $10. Larger transactions still go through traditional billing because the risk tolerance is different.
A significant agent security incident (data exfiltration or financial loss through a malicious agent service) makes mainstream tech news and accelerates adoption of verification layers.
No dominant orchestration standard emerges. The layer remains fragmented across frameworks, with each one serving a different use case well.
I'll revisit these in twelve months and see how I did. Stack diagrams are easy to draw. Getting the timing right is the hard part.