A simpler way to understand where agentic architecture is going
The current generation of agentic systems is already solving several difficult problems.
Agents can call tools through the Model Context Protocol (MCP). They can communicate with other agents through the Agent2Agent Protocol (A2A). They can execute isolated workloads through sandboxes and increasingly portable WebAssembly components. They can propagate distributed traces, authenticate remote identities, and apply policies before or after tool execution.
These are important advances.
But there is a gap between all of these mechanisms.
They tell us how agents communicate, how they discover capabilities, how they call tools, and how software is executed.
They do not yet provide a sufficiently strong common semantic model for answering a more fundamental question:
«What exactly is the thing being executed?»
This article introduces that problem in a deliberately simple way before defining the technical foundations of a more formal architecture.
The goal is not to replace MCP, A2A, WebAssembly, or existing agent runtimes.
The goal is to explain the layer that could exist above them.
- How we build agents today
A simplified agentic application usually looks something like this:
User
|
v
LLM Agent
|
+----> Tool
|
+----> API
|
+----> Database
|
+----> Another Agent
The LLM receives a request, decides what to do, calls one or more tools, receives their results, and eventually produces an answer.
Modern frameworks make this much more sophisticated.
There may be:
- tool registries;
- memory;
- planners;
- sub-agents;
- retries;
- workflow engines;
- tracing;
- authorization;
- guardrails;
- human approval;
- durable execution;
- sandboxed code execution.
The problem is not that the industry lacks infrastructure.
The problem is that these capabilities are often described at different architectural levels.
For example:
MCP → How an agent communicates with tools
A2A → How agents communicate with agents
WASM → How portable code can be executed
Tracing → How execution can be observed
Policy → How actions can be allowed or denied
Workflow → How execution steps can be coordinated
These are all useful.
But none of them, individually, answers:
What was the user's actual intention?
What behavior was selected to satisfy it?
What actor was authorized to perform that behavior?
What exact action was executed?
What state transition occurred?
Why should the result be considered accepted?
What evidence proves what happened?
That is the gap AllasCode is trying to address.
- The first analogy: HTTP did not define the business meaning
A useful analogy is the evolution of the Web.
HTTP tells us how to communicate.
It does not tell us what a bank transfer means.
For example:
POST /transfer
can transport a bank-transfer request.
But HTTP does not define:
who is authorized to transfer money
what constitutes a valid transfer
what account state must exist
what ledger transition must happen
when the transfer becomes final
what evidence proves the transfer
Those semantics belong to higher layers.
The same distinction exists in agentic systems.
MCP and A2A are becoming something similar to infrastructure protocols.
MCP defines a standardized interaction model between clients and servers, including tools, resources, prompts, elicitation, sampling, notifications and authorization. The current specification explicitly describes MCP as stateless: information required to process a request must be present in that request, while long-lived state is represented through explicit identifiers rather than connection state.
A2A provides the complementary agent-to-agent layer.
Its official documentation explicitly positions MCP as agent-to-tool/context communication and A2A as agent-to-agent communication. A2A 1.0 also introduced production-oriented features such as multi-tenancy, signed Agent Cards, multiple protocol bindings, polling, streaming and webhooks.
This is already a useful architecture.
But it still leaves another layer open.
- MCP is not an agent runtime
Consider a simple request:
"Book me a table tomorrow at 8 PM."
An MCP-enabled agent may discover a restaurant tool:
search_restaurants
create_reservation
cancel_reservation
The agent can call the tool.
MCP solves the communication problem.
It does not define the semantic lifecycle of:
Intent
↓
Decision
↓
Authorization
↓
Action
↓
Side effect
↓
Acceptance
↓
Evidence
This distinction becomes even clearer with MCP Tasks.
The MCP Tasks extension defines durable task state machines around requests. A task can be "working", "input_required", "completed", "failed", or "cancelled", and tasks can be polled for deferred results.
That is useful.
But the task is still fundamentally the execution state of a protocol request.
It does not become the semantic definition of the user's intention.
This distinction matters:
MCP Task
=
"the protocol request is being executed"
AllasCode Execution
=
"this semantic behavior is being executed for this intent
by this actor under these policies"
The first is a transport/runtime abstraction.
The second is a semantic execution abstraction.
- A2A solves another part of the problem
Now imagine the reservation agent delegates the request:
Customer Agent
|
| A2A
v
Restaurant Agent
A2A is designed precisely for this.
A2A allows agents implemented using different frameworks and technology stacks to discover capabilities, communicate, delegate tasks and collaborate without exposing their internal memory or implementation.
This is a major improvement over proprietary agent-to-agent integrations.
But again, A2A answers:
«How can Agent A communicate with Agent B?»
It does not fully answer:
«What is the semantic contract of the behavior being delegated?»
That distinction becomes important when several agents participate in one business process.
For example:
Customer Agent
|
v
Reservation Agent
|
v
Payment Agent
|
v
Notification Agent
Who owns the original intent?
Who is authorized to perform each action?
Which state transition constitutes success?
What happens if payment succeeds but notification fails?
Which agent is responsible for healing?
What evidence proves that the reservation actually became accepted?
These questions are above A2A.
- The missing analogy: business semantics
Traditional distributed systems solved this problem through domain models.
A banking system does not model everything as:
HTTP Request
It has concepts such as:
Account
Transaction
Authorization
Ledger
Settlement
Likewise, an e-commerce system does not define its entire architecture as:
POST /something
It has:
Order
Payment
Shipment
Customer
Inventory
Fulfillment
Agentic systems need an equivalent semantic layer.
Instead of starting with:
tool_call
we can start with:
Intent
And instead of treating the entire execution as a sequence of LLM decisions, we can model:
Intent
↓
Behavior
↓
Action
↓
Actor
↓
Runtime
↓
Result
↓
Acceptance
↓
Evidence
This is the fundamental idea behind AllasCode.
- The AllasCode model in simple terms
A simple analogy is:
Intent = What should happen?
Behavior = What behavior satisfies that intent?
Action = What concrete operation performs it?
Actor = Who/what is authorized to perform it?
Runtime = Where and under what capabilities does it execute?
Result = What happened?
Acceptance = Is what happened good enough to be considered successful?
Proof = What evidence demonstrates what happened?
For example:
Intent:
"Register this customer."
could resolve to:
Behavior:
CustomerRegistration
which decomposes into:
Action:
ValidateCustomer
Action:
CheckDuplicate
Action:
PersistCustomer
Action:
EmitCustomerRegistered
The runtime can then execute those Actions through different technologies:
Native Zig
WASM
MCP tool
Remote A2A agent
Database adapter
Human approval
The implementation can change.
The semantic contract does not.
That is the key idea.
- This is where WASM becomes interesting
WebAssembly is solving a different problem.
The WebAssembly Component Model provides a portable interface model between components, while WASI 0.3 adds asynchronous interfaces such as:
async func
future
stream
making asynchronous composition across components substantially more practical.
WASI 0.3.1 further adds features such as:
map
implements
external-id
to the Component Model.
The important idea for AllasCode is not merely "run WASM."
It is:
«An Action can be implemented in another language without changing the semantic contract of the Action.»
For example:
AllasCode Action
"PersistCustomer"
|
v
WIT
|
+----+----+
| |
v v
Rust Zig
| |
+----+----+
|
v
same semantic Action
The runtime owns the capabilities.
The component does not automatically receive arbitrary network, filesystem or operating-system authority.
This makes WASM a possible execution substrate for the AllasCode Action model rather than the model itself.
- Existing projects already implement parts of this idea
AllasCode is not proposing something that has no precedent.
Several projects already solve important pieces.
The interesting question is therefore not:
«"Does anybody do this?"»
They do.
The interesting question is:
«"Which parts exist independently today, and what happens if we connect them under one semantic execution model?"»
MCP
MCP standardizes agent-to-tool and agent-to-resource interaction.
It already provides:
tools
resources
prompts
elicitation
sampling
authorization
tasks
notifications
and increasingly explicit statelessness and observability mechanisms.
AllasCode would use MCP as a binding.
It would not replace MCP.
AllasCode Action
|
v
MCP Adapter
|
v
MCP Server
A2A
A2A standardizes agent-to-agent communication, delegation and capability discovery. It is particularly relevant when execution crosses organizational or technological boundaries.
AllasCode would use A2A as another binding:
AllasCode Behavior
|
v
A2A Adapter
|
v
Remote Agent
The semantic Behavior remains independent of A2A.
LangGraph and durable agent workflows
Frameworks such as LangGraph already treat agent execution as something more structured than a single LLM call.
They provide stateful graphs, checkpoints, durable execution and human-in-the-loop patterns.
This is conceptually close to:
Behavior
↓
state transitions
↓
checkpoint
↓
resume
The difference is that AllasCode attempts to make the semantic objects themselves independent of a particular workflow framework.
LangGraph can therefore be considered an implementation/runtime approach that solves part of the problem rather than the semantic standard itself.
Agent runtimes
Modern agent runtimes increasingly provide:
durable state
sandboxing
tool execution
context management
sub-agents
observability
recovery
This is important because it demonstrates that the industry is moving from:
LLM API
toward:
Agent Runtime
AllasCode agrees with this direction.
The difference is that AllasCode asks one additional question:
«What should the runtime consider to be the canonical unit of semantic execution?»
The proposal is:
Intent → Behavior → Action
rather than:
LLM → tool call
- The important distinction: protocol vs semantic layer
We can now make the architecture easier to understand.
Imagine the Internet:
HTTP
TCP
IP
Ethernet
None of these define:
Order
Payment
Customer
Shipment
Those belong to application semantics.
Agent systems are developing something similar:
A2A
MCP
WASM
HTTP
gRPC
NATS
These provide infrastructure.
AllasCode proposes:
Intent
Behavior
Action
Actor
Runtime
Result
Acceptance
Proof
as the semantic layer above that infrastructure.
So:
SEMANTICS
────────────────────────────────────
Intent
Behavior
Action
Actor
Runtime
Result
Acceptance
Proof
────────────────────────────────────
BINDINGS
A2A MCP REST NATS
────────────────────────────────────
EXECUTION
WASM Native Sandbox Remote
────────────────────────────────────
INFRASTRUCTURE
Network / OS / Database / Compute
That is a much simpler way to understand the proposal.
- Why "Result" is more important than "Response"
There is another distinction that becomes important here.
A protocol normally produces a response.
A runtime produces a result.
Those are not necessarily the same thing.
For example:
HTTP Response:
200 OK
does not mean:
Business Result:
Customer successfully registered.
Likewise:
MCP tool call:
completed
does not necessarily mean:
Domain outcome:
Inventory was successfully reserved.
The semantic runtime therefore needs an explicit distinction between:
Protocol Response
Execution Result
Accepted Outcome
This is one of the reasons the concept of Outcome Acceptance becomes important.
An execution can technically complete while failing to produce an acceptable business outcome.
- Healing is also different from retry
Existing agent frameworks frequently implement retry or replanning.
That is useful but insufficient.
Consider:
Action A
↓
Action B
↓
Action C
↓
failure
A simple system might do:
retry C
A more sophisticated system might:
replan
AllasCode proposes that healing should be treated as an explicit runtime behavior:
Failure
↓
Diagnosis
↓
Containment
↓
Healing Strategy
↓
Re-execution
↓
Verification
↓
Acceptance
This distinction matters because a retry can actually amplify a failure.
Recent research such as AGENTCHAOSBENCH is beginning to evaluate failures across tool, model, guardrail and inter-agent boundaries rather than treating the final answer as the only outcome.
This supports treating the trajectory itself as an object of analysis.
- The runtime therefore becomes the authority
The architecture can now be expressed very simply:
LLM
│
│ proposes
▼
Intent / Behavior
│
│ validated by
▼
Runtime
│
├── Identity
├── Authorization
├── Policy
├── Capability
├── Execution
├── Healing
├── Observability
└── Evidence
│
▼
Side Effect
The most important property is:
«The model proposes. The runtime authorizes and executes.»
This is fundamentally different from architectures where the model effectively controls tool invocation directly.
It also provides a clean security boundary.
- What existing protocols still do not express
Recent research is beginning to identify this gap explicitly.
A 2026 analysis of governance in agent interoperability protocols found that MCP, A2A, ACP, ANP and ERC-8004 provide mechanisms for identity, discovery and communication, but do not fully express governance concepts such as deliberation, voting, dissent preservation, human escalation and audit/replay. The authors conclude that governed agent communities represent an architectural layer above current interoperability protocols.
Another recent study, A2ABreak, systematically modeled A2A as a finite-state machine and identified 11 vulnerabilities that can arise even from specification-compliant behavior, including cross-client context injection, multi-hop identity loss and rogue agents advertising unattested capabilities.
These results are important because they demonstrate something broader:
«Having an interoperability protocol does not automatically produce a safe semantic execution model.»
That is precisely the layer AllasCode is trying to make explicit.
- The proposed architecture
The first simplified version can therefore be:
HUMAN
│
▼
INTENT
│
▼
BEHAVIOR
│
▼
ACTION
│
┌──────┴──────┐
│ │
ACTOR GOVERNOR
│ │
└──────┬──────┘
▼
RUNTIME
│
┌──────────────┼──────────────┐
│ │ │
WASM MCP A2A
│ │ │
└──────────────┼──────────────┘
▼
EFFECT
│
▼
RESULT
│
▼
ACCEPTANCE
│
▼
PROOF
│
▼
TRAJECTORY
This diagram is intentionally simple.
The more formal architecture can later define the precise ontology and contracts.
- What makes this different from "another agent framework"
The proposal is not:
"Here is another way to call an LLM."
It is also not:
"Here is another agent orchestration framework."
The intended abstraction is closer to:
Agent Applications
│
▼
Semantic Agent Runtime
│
┌────────────┼────────────┐
▼ ▼ ▼
MCP A2A WASM
│ │ │
└────────────┼────────────┘
▼
Infrastructure
The runtime becomes the place where semantics, authority, execution and evidence meet.
- The research hypothesis
This leads to a testable hypothesis:
«Agentic systems become more interoperable, governable and verifiable when semantic execution is defined independently of the communication protocol, agent framework, model provider and Action implementation language.»
This hypothesis can be experimentally evaluated.
The same Behavior could be executed through:
Native Zig
WASM/Rust
WASM/Go
MCP
A2A
REST
NATS
while testing whether the system preserves:
Intent identity
Behavior identity
Authorization
State transitions
Outcome semantics
Acceptance criteria
Evidence
If those properties remain invariant, then interoperability is no longer merely:
«"different agents can talk."»
It becomes:
«"different implementations can participate in the same semantic execution."»
That is a much stronger definition of interoperability.
- From this article to the scientific paper
The next paper should therefore not start by introducing every AllasCode concept.
It should formalize the problem discovered here.
The progression should be:
Current industry
↓
MCP / A2A / Agent Runtimes / WASM
↓
Observed architectural gap
↓
Semantic Execution Layer
↓
Intent → Behavior → Action → Actor → Runtime
↓
Governance
↓
Acceptance
↓
Evidence
↓
Formal model
↓
Experiments
The scientific contribution would then be much easier to evaluate.
The question is no longer:
«"Is AllasCode a good architecture?"»
The question becomes:
«"Can a protocol-independent semantic execution model preserve behavioral invariants across heterogeneous agent runtimes, communication protocols and Action implementations?"»
That is a research question.
And it can be tested.
- The relationship with existing work
The intended positioning is therefore:
Project / standard| What it solves| What AllasCode reuses| What remains different
MCP| Agent ↔ tool/context| Tool interoperability| Semantic execution model
A2A| Agent ↔ agent| Agent interoperability| Semantic ownership of execution
LangGraph| Stateful agent workflows| Durable/stateful execution ideas| Protocol/framework-independent semantics
Agent runtimes| Execution, state, tools, sandbox| Runtime concepts| Canonical Intent/Behavior/Action model
WASM Component Model| Portable component execution| Polyglot Action implementation| Semantic Action contract
OpenTelemetry| Distributed observability| Trace propagation| Intent/Behavior/Trajectory semantics
Policy engines| Authorization/governance| Deterministic enforcement| Lifecycle-wide semantic governance
AgentChaosBench| Failure evaluation| Failure injection/testing| Runtime semantic model
A2ABreak| Protocol security analysis| Formal state-machine analysis| Formalization of semantic execution
TRACE / attestation work| Runtime evidence| Evidence/provenance| Combining evidence with semantic outcomes
This is important because AllasCode should not claim to have invented each individual capability.
The novelty is in the composition and the semantic boundary.
- The simplest possible definition
If I had to explain the entire idea without any architecture diagram, I would say:
«Today's agent infrastructure is getting very good at helping agents communicate, discover tools, execute code, persist state and enforce policies.
AllasCode asks what comes immediately above those mechanisms: a common semantic representation of what an agent is trying to accomplish, what behavior is being executed, who is authorized to execute it, what actually happened, whether the outcome is acceptable, and what evidence proves the execution.
MCP, A2A and WASM can then become interchangeable implementation mechanisms underneath that semantic layer.»
That is the conceptual bridge to the technical paper.
Sources
The most important primary sources used in this comparison are the MCP specification and Tasks extension, which define MCP's stateless request model and durable task state machine; the A2A 1.0 specification and project documentation; and recent research examining governance gaps and A2A security.
For the formal paper, I would then expand this foundation with the WebAssembly Component Model/WASI specifications, OpenTelemetry trace context, runtime-governance research, failure benchmarks such as AGENTCHAOSBENCH, and the relevant durable-execution/agent-runtime systems.
Top comments (0)