Beyond MCP and A2A: the case for a semantic agent runtime layer

Two posts, one argument: protocols are not semantics

Two posts published on dev.to — one in English, one in Portuguese, both from the same author's account — make a shared case about where agentic architecture is heading. The argument: today's agent infrastructure has solved communication and execution, but not meaning. Their proposed fix is a "semantic agent runtime" layer that sits above existing protocols rather than replacing them.

The posts are tied to a project called AllasCode, which the Portuguese post describes as the author's own runtime written in Zig, designed around intent with adaptive and self-healing behavior. Importantly, the author positions it as complementary: MCP, A2A, WebAssembly, OpenTelemetry and frameworks like LangGraph would stay in place underneath, while the semantic layer remains independent of protocol, framework, model or implementation language.

What the current stack actually covers

According to the English post, each piece of the modern agent stack answers a different question:

• MCP handles how an agent communicates with tools and context. Its specification covers tools, resources, prompts, elicitation, sampling, notifications and authorization, and describes the protocol itself as stateless, with long-lived state represented through explicit identifiers.
• A2A handles agent-to-agent communication, and its documentation explicitly frames it as complementary to MCP. Version 1.0 added production-oriented features such as multi-tenancy, signed Agent Cards, multiple protocol bindings, polling, streaming and webhooks.
• WebAssembly and sandboxes handle isolated, portable execution, while tracing, policy engines and workflow engines cover observability, allow/deny decisions and step coordination.

All useful, the author concedes — but none of them, individually, can say what the user's actual intention was, which actor was authorized, what state transition occurred, whether the result should count as accepted, or what evidence proves any of it happened.

The HTTP analogy

The core analogy is borrowed from the web. HTTP defines verbs, headers and status codes; it does not define what a bank transfer is. A request to a transfer endpoint can carry the operation, but questions of authorization, validity, ledger transitions, finality and proof belong to higher layers. The same split, the posts argue, now exists in agentic systems: MCP, A2A, HTTP and message brokers transport; WASM, containers and native runtimes execute; something above them must define what is being executed and what executing it correctly means.

The proposed chain: Intent to Proof

The model both posts propose is a fixed semantic chain:

Intent, or what should happen; Behavior, the named behavior that satisfies it; Action, the concrete operations that implement the behavior; Actor, the entity authorized to perform it; Runtime, where it executes; Result, what actually happened; Acceptance, whether that result meets the stated criteria; and Proof, the evidence demonstrating it occurred.

One worked example: the intent "cancel my order 123" resolves to a CancelOrder behavior, decomposed into actions such as validating the order, checking the cancellation policy, cancelling it, and emitting an event — performed by an authorized actor (a customer, an order service, an administrator) on whatever runtime is available, from Zig or Rust to a container or an MCP server.

Completed is not the same as accepted

The sharpest distinction in the posts is between three different things that often get collapsed: a protocol response, an execution result, and an accepted outcome. MCP's Tasks extension defines durable state machines with states like working, completed, failed and cancelled — but a task reporting completed only means the protocol operation finished. It does not confirm that a payment actually settled, to the correct beneficiary, for the correct amount. The Portuguese post gives a compact example: intent "receive the product tomorrow", result "order created", acceptance rejected.

Multi-agent chains sharpen the problem. When a customer agent delegates through A2A to reservation, payment and notification agents, the posts ask: who owns the original intent, who was authorized for each action, which state transition constitutes success, what happens if payment succeeds but notification fails, and which agent is responsible for recovery?

Why it matters

For anyone building agent tooling, this is a useful framing of the next competitive layer. MCP is rapidly becoming table stakes for tool integration, and A2A is standardizing agent delegation — which means transport and discovery stop being differentiators. The open questions the posts identify, particularly acceptance criteria and verifiable evidence for each execution, map directly onto what enterprises ask before trusting agents with real transactions. The analogy to domain models in banking and e-commerce, where concepts like Order, Ledger and Settlement sit above the transport layer, suggests agent systems will need the equivalent.

It is worth keeping perspective: this is one project's proposal published as blog posts on dev.to, not an industry standard, and both pieces come from the same author advocating for their own runtime. But the underlying gap they describe — protocols that report completion without ever defining success — is one that MCP Tasks and A2A, in their current forms, genuinely leave open.