Por que o AllasCode, meu runtime Zig com uma arquitetura um evolutiva, adaptativa, generativa, anti-fragil e com auto-cura baseada em intenção; precisa de uma camada acima de MCP, A2A e Wasm.
Os sistemas agentivos estão evoluindo rapidamente. Hoje já temos protocolos para agentes conversarem com ferramentas, protocolos para agentes conversarem com outros agentes, runtimes para executar tarefas de longa duração, mecanismos de observabilidade, motores de políticas e plataformas capazes de executar código de forma isolada.
Mas existe uma questão que ainda permanece parcialmente sem resposta:
Como representar, de maneira independente do protocolo, framework, modelo ou linguagem de implementação, o significado daquilo que o agente está tentando realizar?
Essa é a questão central que o AllasCode procura abordar.
A proposta não é substituir MCP, A2A, WASM, OpenTelemetry, LangGraph ou os runtimes existentes. Pelo contrário: é posicionar essas tecnologias embaixo de uma camada semântica comum.
A ideia pode ser resumida assim:
Intenção → Comportamento → Ação → Ator → Runtime → Resultado → Aceitação → Evidência
Essa camada permitiria que diferentes protocolos e tecnologias fossem utilizados como mecanismos de transporte, comunicação, execução e observabilidade sem que o significado da operação ficasse preso a nenhum deles.
- O que temos hoje
A arquitetura típica de um sistema agentivo pode ser simplificada para:
Usuário
↓
LLM / Agente
↓
Ferramenta / API / Banco / Outro Agente
↓
Resultado
Isso já funciona muito bem para diversos casos.
O problema aparece quando precisamos responder perguntas mais profundas:
- O que exatamente o usuário queria realizar?
- Qual comportamento do sistema foi escolhido?
- Qual ação foi realmente executada?
- Quem estava autorizado a executá-la?
- Qual política permitiu essa execução?
- Qual estado mudou?
- Qual foi o resultado semântico da operação?
- Esse resultado foi realmente aceito?
- Que evidência comprova que tudo isso aconteceu?
- Se algo falhou, o que exatamente deve ser corrigido?
- Podemos executar o mesmo comportamento usando outra linguagem, protocolo ou runtime sem alterar seu significado?
Os protocolos atuais resolvem partes diferentes desse problema, mas não necessariamente fornecem uma representação comum para todas essas respostas.
- MCP resolve uma parte importante do problema
O Model Context Protocol (MCP) fornece uma padronização para a comunicação entre aplicações de IA e servidores que disponibilizam ferramentas, recursos e outros mecanismos de interação.
A especificação atual do MCP define um protocolo de comunicação baseado em mensagens e enfatiza que o protocolo em si é stateless: as informações necessárias para processar uma requisição devem estar disponíveis na própria requisição, enquanto estados de longa duração podem ser mantidos explicitamente por identificadores.
O MCP também passou a incorporar Tasks como uma extensão formal para operações duráveis. Uma Task representa uma máquina de estados durável associada à execução de uma operação.
Isso é extremamente útil.
Mas existe uma diferença importante:
MCP Task
estado protocolar de uma operação
AllasCode Execution
execução semântica de um comportamento
para uma intenção, ator e contexto específicos
Uma Task pode dizer que uma operação está "working", "completed" ou em outro estado definido pelo protocolo.
Isso não significa necessariamente que o objetivo de negócio tenha sido atingido.
Por exemplo:
MCP:
"process_payment" → completed
Negócio:
Pagamento realmente confirmado?
Pedido efetivamente quitado?
Valor correto?
Beneficiário correto?
Resultado aceito?
Evidência produzida?
O protocolo pode informar que a execução terminou.
A camada semântica precisa determinar se o resultado pretendido realmente aconteceu.
- A2A resolve outro problema
O Agent2Agent Protocol (A2A) foi criado para permitir que agentes diferentes se comuniquem e cooperem.
A própria documentação do A2A posiciona o protocolo como complementar ao MCP: MCP trata principalmente da interação entre agentes e ferramentas/contexto, enquanto A2A trata da comunicação entre agentes.
Podemos representar isso assim:
MCP
Agent
↓
Tool / Resource
A2A
Agent
↕
Agent
Novamente, isso resolve uma camada importante.
Mas comunicação entre agentes não define, por si só, a semântica completa da execução.
Imagine:
Agent A
↓
A2A
↓
Agent B
↓
Ação
Precisamos saber:
Qual intenção originou a operação?
Qual comportamento foi delegado?
Quem é o ator responsável?
Qual autoridade foi delegada?
Qual política autorizou?
Qual ação foi executada?
Qual estado foi alterado?
Qual resultado ocorreu?
Esse resultado satisfaz o critério de aceitação?
Que evidência comprova isso?
O A2A fornece a infraestrutura para a comunicação.
O AllasCode pretende definir uma semântica que possa permanecer intacta independentemente de essa comunicação ocorrer por A2A, MCP, HTTP, NATS ou outro mecanismo.
- A analogia com HTTP
Uma forma simples de entender essa diferença é comparar com a web.
HTTP define coisas como:
GET
POST
PUT
DELETE
status codes
headers
body
Mas HTTP não define o significado de:
Transferir dinheiro
Criar um pedido
Emitir uma receita
Contratar um funcionário
Cancelar uma assinatura
Podemos transportar uma operação bancária por HTTP:
POST /transfer
Mas o HTTP não sabe o que é uma transferência bancária.
Essa semântica pertence a uma camada superior.
A mesma separação pode ser aplicada aos sistemas agentivos:
┌───────────────────────────────────────┐
│ Semântica de execução │
│ │
│ Intent → Behavior → Action → Actor │
│ → Result → Acceptance → Proof │
├───────────────────────────────────────┤
│ Protocolos │
│ MCP / A2A / HTTP / NATS / gRPC │
├───────────────────────────────────────┤
│ Execução │
│ WASM / Native / Containers / Runtime │
└───────────────────────────────────────┘
MCP, A2A e HTTP transportam.
WASM e outros runtimes executam.
Mas uma camada superior precisa definir o que está sendo executado e o que significa ter sido executado corretamente.
- A proposta: uma camada de execução semântica
O modelo proposto pelo AllasCode pode ser inicialmente representado como:
Intent
↓
Behavior
↓
Action
↓
Actor
↓
Runtime
↓
Result
↓
Acceptance
↓
Proof
Cada elemento possui uma responsabilidade diferente.
Intent
Representa aquilo que o usuário ou sistema pretende alcançar.
Exemplo:
"Quero cancelar meu pedido 123."
Behavior
Representa o comportamento que deve ser realizado para atender à intenção.
CancelOrder
Action
Representa uma operação executável específica.
ValidateOrder
CheckCancellationPolicy
CancelOrder
EmitCancellationEvent
Actor
Representa quem ou qual entidade possui autoridade para realizar a ação.
Customer
OrderService
Administrator
Agent
Runtime
É o ambiente que efetivamente executa a ação.
Pode ser:
Zig
Rust
Go
TypeScript
WASM
Container
MCP server
Remote service
Result
Representa aquilo que efetivamente aconteceu durante a execução.
Isso é diferente de uma simples resposta de protocolo.
Acceptance
Representa a decisão sobre se o resultado satisfaz o objetivo e os critérios estabelecidos.
Proof
Representa a evidência necessária para demonstrar o que ocorreu.
Essa última parte é especialmente importante para sistemas agentivos governáveis.
- Resultado não é a mesma coisa que resposta
Essa distinção é fundamental.
Podemos ter:
Protocol Response
↓
Execution Result
↓
Accepted Outcome
Uma resposta HTTP:
200 OK
não significa necessariamente que o resultado de negócio foi alcançado.
Da mesma maneira:
MCP Task = completed
não significa necessariamente:
Outcome = accepted
Imagine:
Intent:
"Quero receber o produto amanhã."
Result:
"Pedido criado."
Acceptance:
REJECTED
A operação técnica terminou.
Mas o resultado desejado não foi alcançado.
Portanto:
Response ≠ Result ≠ Accepted Outcome
Essa separação permite tratar Outcome Acceptance como uma etapa explícita do sistema.
- WASM resolve a portabilidade da execução
WebAssembly e o Component Model oferecem outra peça importante.
O WASI 0.3 introduz capacidades assíncronas como "future" e "stream", enquanto versões subsequentes do modelo de componentes continuam ampliando a capacidade de interoperabilidade entre linguagens e componentes.
Isso torna WASM particularmente interessante como substrato de execução.
Por exemplo:
Action: CalculateShipping
Rust implementation
↓
WASM
Go implementation
↓
WASM
Zig implementation
↓
WASM
Todas poderiam implementar o mesmo contrato semântico.
O ponto importante é:
WASM não precisa definir o significado da Action.
Ele pode ser simplesmente o mecanismo portátil utilizado para executar a Action.
Assim:
Semantic Contract
↓
Action
↓
WIT / ABI
↓
WASM
↓
Rust / Go / Zig / ...
Isso cria uma separação muito interessante entre:
O que deve ser feito
e
Como é executado
- O que projetos existentes já fazem
O AllasCode não precisa reinventar todas essas capacidades.
Na realidade, vários projetos já resolvem partes importantes do problema.
MCP
Resolve:
Agent ↔ Tool / Context
O AllasCode pode utilizar MCP como binding de transporte e integração.
A2A
Resolve:
Agent ↔ Agent
O AllasCode pode utilizar A2A como binding de comunicação entre agentes.
LangGraph
Resolve problemas relacionados a:
stateful workflows
checkpoints
durable execution
human-in-the-loop
O AllasCode compartilha várias preocupações de execução e recuperação, mas procura colocar a semântica de execução em um nível independente do framework.
Agent Runtimes
Os runtimes modernos estão começando a tratar:
durable state
sandboxing
tools
context
recovery
execution
O AllasCode adiciona uma questão anterior:
Qual é exatamente a unidade semântica que está sendo executada?
WASM Component Model
Resolve:
portable execution
language interoperability
capability-oriented execution
O AllasCode pode utilizar essa infraestrutura para implementar Actions.
OpenTelemetry
Resolve:
logs
metrics
traces
distributed observability
O AllasCode pode adicionar uma dimensão semântica:
IntentID
BehaviorID
ActionID
ActorID
TrajectoryID
Outcome
Acceptance
Proof
Assim, não observamos somente uma requisição.
Observamos o significado da execução.
- Observabilidade não é o mesmo que evidência semântica
Um trace tradicional pode mostrar:
HTTP request
↓
service A
↓
service B
↓
database
Isso é extremamente útil.
Mas em um sistema agentivo podemos precisar saber:
Intent:
CancelOrder
Behavior:
CancelOrderBehavior
Actor:
Customer#123
Action:
CancelOrder
Policy:
CancellationPolicy.v4
State transition:
PENDING → CANCELLED
Result:
Cancelled
Acceptance:
ACCEPTED
Proof:
event + database state + authorization decision
Isso transforma observabilidade em algo mais próximo de uma trajetória semântica verificável.
É uma direção compatível com trabalhos recentes sobre análise de falhas de sistemas agentivos, que mostram que uma única trace frequentemente não é suficiente para explicar falhas distribuídas e cascatas de agentes.
- Governance precisa estar acima do protocolo
Outro ponto importante é governança.
Protocolos de interoperabilidade permitem que entidades se comuniquem.
Mas:
Comunicar ≠ Autorizar
Um agente pode conseguir chamar outro agente sem necessariamente possuir autorização para executar determinado comportamento.
Pesquisas recentes sobre segurança de A2A demonstraram problemas possíveis mesmo assumindo agentes que cumprem formalmente a especificação. O trabalho A2ABreak identificou 11 vulnerabilidades, incluindo injeção de contexto entre clientes, perda de identidade em cadeias de delegação e agentes com alegações de capacidade não atestadas.
Isso reforça uma separação:
Interoperability
≠
Governance
≠
Authorization
A governança precisa acompanhar a execução.
- O runtime deve ser a autoridade
Uma regra importante para o modelo é:
LLM proposes.
Runtime decides.
O modelo pode sugerir:
"Execute RefundOrder."
Mas isso não significa que a operação será executada.
O runtime deve verificar:
Intent
Behavior
Actor
Authorization
Policy
Context
Constraints
Somente depois:
ALLOW
↓
EXECUTE
ou:
DENY
Isso evita que a autoridade final fique implicitamente dentro do modelo.
A arquitetura passa a ser:
┌─────────────┐
│ LLM │
│ Proposes │
└──────┬──────┘
↓
┌─────────────┐
│ Governor │
│ Authorizes │
└──────┬──────┘
↓
┌─────────────┐
│ Runtime │
│ Executes │
└──────┬──────┘
↓
┌─────────────┐
│ Outcome │
└─────────────┘
- Healing não é simplesmente retry
Esse modelo também muda a forma de pensar sobre self-healing.
Um sistema tradicional frequentemente faz:
Failure
↓
Retry
↓
Retry
↓
Retry
Em sistemas agentivos isso pode ser perigoso.
Um erro pode estar sendo causado por:
wrong actor
wrong policy
invalid state
tool failure
dependency failure
semantic mismatch
bad model decision
security violation
Portanto, healing deveria ser algo como:
Failure
↓
Diagnosis
↓
Containment
↓
Healing Strategy
↓
Re-execution
↓
Verification
↓
Acceptance
E não:
Failure → Retry
A diferença é importante porque uma execução só deve ser considerada recuperada quando o resultado volta a satisfazer seus critérios de aceitação.
- Onde o AllasCode se posiciona
Podemos visualizar o ecossistema assim:
┌─────────────────────────────────────────────┐
│ SEMANTIC EXECUTION │
│ │
│ Intent → Behavior → Action → Actor │
│ → Runtime → Result → Acceptance → Proof │
├─────────────────────────────────────────────┤
│ GOVERNANCE │
│ Authorization / Policy / Identity / Healing │
├─────────────────────────────────────────────┤
│ INTEROPERABILITY │
│ MCP / A2A / HTTP / NATS / gRPC │
├─────────────────────────────────────────────┤
│ EXECUTION │
│ WASM / Native / Containers / Services │
├─────────────────────────────────────────────┤
│ OBSERVABILITY │
│ Logs / Metrics / Traces / Events │
└─────────────────────────────────────────────┘
A ideia não é substituir as camadas inferiores.
É estabelecer uma fronteira semântica acima delas.
- O que cada tecnologia faz e o que ainda falta
Tecnologia / projeto| Resolve principalmente| O que o AllasCode acrescenta
MCP| Agent ↔ Tool/Context| Semântica da execução acima do protocolo
A2A| Agent ↔ Agent| Identidade semântica, comportamento e resultado
LangGraph| Workflows e estado| Modelo independente de framework
Agent Runtimes| Execução, estado, sandbox| Unidade semântica canônica
WASM| Execução portátil| Contrato semântico independente da implementação
OpenTelemetry| Observabilidade| Trajetória semântica e evidência
Policy Engines| Decisão de autorização| Governança vinculada ao comportamento
AgentChaosBench| Avaliação de falhas| Semântica para diagnóstico e recuperação
A2ABreak| Segurança do protocolo A2A| Segurança no nível da execução semântica
TRACE / attestation| Evidência e proveniência| Associação da evidência ao Outcome
O objetivo, portanto, não é afirmar que essas tecnologias não fazem essas coisas.
É identificar que elas fazem partes diferentes do problema.
- Uma arquitetura possível
A arquitetura simplificada seria:
Human
│
▼
Intent
│
▼
Behavior
│
▼
Action
│
▼
Actor / Governor
│
▼
Runtime
│
├── WASM
├── Native
├── MCP
├── A2A
├── REST
└── NATS
│
▼
Effect
│
▼
Result
│
▼
Acceptance
│
▼
Proof
│
▼
Trajectory
O ponto mais importante é que os mecanismos abaixo podem mudar sem necessariamente mudar a semântica acima.
Por exemplo:
CancelOrder
poderia ser executado por:
Zig native
ou:
Rust → WASM
ou:
Remote MCP Tool
ou:
A2A delegated agent
ou:
REST service
Desde que todos preservem os invariantes semânticos necessários.
- A hipótese de pesquisa
Isso leva a uma hipótese testável:
«Sistemas agentivos tornam-se mais interoperáveis, governáveis e verificáveis quando a execução semântica é definida independentemente do protocolo de comunicação, framework de agentes, provedor de modelos e linguagem utilizada na implementação da Action.»
Essa hipótese pode ser testada experimentalmente.
Podemos implementar o mesmo comportamento utilizando:
Native Zig
WASM/Rust
WASM/Go
MCP
A2A
REST
NATS
E verificar se conseguimos preservar:
Intent identity
Behavior identity
Actor identity
Authorization
State transitions
Outcome semantics
Acceptance criteria
Evidence
Se esses invariantes permanecerem preservados, teremos evidência de que a semântica pode ser separada da infraestrutura de execução.
- A relação com os trabalhos existentes
Essa direção não parte da premissa de que todos esses problemas são novos.
Pelo contrário.
Trabalhos recentes sobre interoperabilidade de agentes mostram que MCP, A2A e outros protocolos resolvem diferentes aspectos da comunicação entre componentes agentivos.
O trabalho sobre lacunas de governança em protocolos de interoperabilidade argumenta explicitamente que protocolos como MCP e A2A não cobrem todas as dimensões necessárias de governança e que essa preocupação pertence a uma camada arquitetural superior à interoperabilidade.
A2ABreak, por sua vez, mostra que mesmo uma implementação que respeita formalmente um protocolo pode apresentar problemas relacionados a identidade, contexto e capacidades declaradas.
Esses trabalhos não são concorrentes diretos da proposta.
Eles ajudam a demonstrar que o problema arquitetural existe.
- O que é realmente novo aqui?
É importante não afirmar:
«"AllasCode inventou Intent."»
Nem:
«"AllasCode inventou governance."»
Nem:
«"AllasCode inventou agent runtime."»
Nem:
«"AllasCode inventou WASM para agentes."»
Essas afirmações seriam incorretas.
A possível contribuição está na composição e na fronteira semântica.
A proposta é tratar como uma unidade formal:
Intent
→ Behavior
→ Action
→ Actor
→ Runtime
→ Result
→ Acceptance
→ Proof
e tornar essa unidade independente de:
LLM
Framework
Protocol
Transport
Programming Language
Execution Runtime
Essa separação pode permitir que MCP, A2A, WASM e outras tecnologias funcionem como bindings ou mecanismos de implementação, em vez de definirem a semântica fundamental do sistema.
- A definição mais simples
Podemos resumir toda a proposta desta forma:
«Os sistemas agentivos atuais estão ficando muito bons em permitir que agentes se comuniquem, descubram ferramentas, executem código, persistam estado, observem operações e apliquem políticas.
O AllasCode propõe uma camada imediatamente acima desses mecanismos: uma representação semântica comum daquilo que um agente está tentando realizar, do comportamento que está sendo executado, de quem está autorizado a executá-lo, do que realmente aconteceu, de quando o resultado é aceitável e das evidências que comprovam a execução.
MCP, A2A, WASM, REST, NATS e outras tecnologias podem então se tornar mecanismos intercambiáveis de implementação dessa semântica.»
- O caminho para o artigo científico
A partir dessa versão conceitual, o próximo passo é transformar a ideia em uma definição técnica e científica.
A estrutura natural seria:
Abstract
-
Introduction
- Agentic systems
- Interoperability
- Current architectural fragmentation
-
Related Work
- MCP
- A2A
- Agent runtimes
- LangGraph
- WASM
- OpenTelemetry
- Policy engines
- Agent security
Problem Statement
-
Semantic Execution Model
- Intent
- Behavior
- Action
- Actor
- Runtime
- Result
- Acceptance
- Proof
Execution Semantics
Governance Model
Outcome Acceptance
Evidence and Provenance
Healing Model
-
Protocol Bindings
- MCP
- A2A
- HTTP
- NATS
WASM Execution Model
Formal Properties / Invariants
Implementation Architecture
Experimental Methodology
Benchmark
Threats to Validity
Discussion
Conclusion
A pergunta científica central poderia ser:
«É possível preservar invariantes comportamentais de uma execução agentiva através de diferentes runtimes, protocolos de comunicação e implementações de Actions quando a semântica da execução é definida independentemente da infraestrutura?»
Essa é uma pergunta muito mais forte do que simplesmente perguntar se "AllasCode funciona".
Ela permite transformar o conceito em algo que pode ser formalizado, implementado, comparado e experimentalmente falsificado.
Fontes principais
A especificação oficial do "Model Context Protocol (MCP)" (https://reference-url-citation.invalid/7) e a especificação de Tasks do MCP são as referências para a camada de comunicação e execução durável.
A documentação oficial do "Agent2Agent Protocol (A2A)" (https://reference-url-citation.invalid/9) e o anúncio da versão 1.0 fundamentam a análise da interoperabilidade entre agentes.
O trabalho "A2ABreak" (https://reference-url-citation.invalid/11) fundamenta a discussão sobre segurança, identidade e delegação em A2A.
O trabalho "Governance Gaps in Agent Interoperability Protocols" (https://reference-url-citation.invalid/13) fundamenta a distinção entre interoperabilidade protocolar e governança arquitetural.
O estudo "Collaborative Agentic AI Needs Interoperability" (https://reference-url-citation.invalid/15) e o "Survey of Agent Interoperability Protocols" (https://reference-url-citation.invalid/16) servem como base para o panorama de interoperabilidade entre agentes.
Top comments (0)