Phase 16 - Lesson 02

Legado do FIPA-ACL e Atos de Fala

Antes do MCP, antes do A2A, existia o FIPA-ACL. Em 2000, a IEEE Foundation for Intelligent Physical Agents ratificou uma linguagem de comunicação de agentes com vinte performativos, duas linguagens de conteúdo e um conjunto de protocolos de interação — contract net, subscribe/notify, request-when. Ela desapareceu da indústria porque a sobrecarga da ontologia era muito pesada para a web, mas o renascimento dos sistemas multiagentes com LLMs está silenciosamente reimplementando as mesmas ideias sem a semântica formal: contratos JSON substituem os performativos, linguagem natural substitui as ontologias. Esta lição analisa o FIPA-ACL seriamente para que você possa ver quais decisões de protocolo de 2026 são reinvenção, quais são novidade e onde a onda atual redescobrirá problemas que os anos 2000 já haviam resolvido.

Tipo: Aprender Linguagens: Python (stdlib) Pré-requisitos: Phase 16 · 01 (Why Multi-Agent) Tempo: ~60 minutos

O Problema

O cenário dos protocolos de agentes de 2026 está movimentado: MCP para ferramentas, A2A para agentes, ACP para auditoria empresarial, ANP para confiança descentralizada, NLIP para conteúdo em linguagem natural, além do CA-MCP e duas dezenas de propostas de pesquisa. Cada especificação se anuncia como fundamental.

A leitura honesta é que a maioria delas está redescobrindo uma árvore de decisão muito específica de vinte anos atrás. A teoria dos atos de fala de Austin (1962) e Searle (1969) nos deu "enunciados são ações". O KQML (1993) transformou isso em um protocolo de comunicação (wire protocol). O FIPA-ACL (ratificado em 2000) produziu a padronização de referência: vinte performativos, linguagens de conteúdo SL0/SL1, protocolos de interação para contract-net e subscribe-notify. JADE e JACK foram as plataformas Java de referência. O esforço enfraqueceu por volta de 2010 porque a sobrecarga da ontologia era muito pesada e a web estava vencendo.

Quando você olha para o tools/call do MCP, o ciclo de vida de tarefas do A2A ou o repositório de contexto compartilhado do CA-MCP, você está olhando para uma reformulação mais leve e nativa em JSON das decisões do FIPA. Conhecer esse legado lhe diz duas coisas: quais novas "inovações" são na verdade reinvenções e quais antigos modos de falha as novas especificações irão redescobrir.

O Conceito

Atos de fala, em um parágrafo

Austin percebeu que algumas frases não descrevem o mundo — elas o alteram. "Eu prometo." "Eu solicito." "Eu declaro." Ele chamou estes enunciados de performativos. Searle formalizou cinco categorias: assertivos, diretivos, compromissivos, expressivos e declarativos. O KQML (Finin et al., 1993) tornou isso operacional para agentes de software: uma mensagem é um performativo (a ação) mais o conteúdo (sobre o que é a ação). O FIPA-ACL corrigiu as lacunas do KQML e padronizou em torno de vinte performativos.

Os vinte performativos FIPA (lista parcial)

A lista completa está em fipa00037.pdf (FIPA ACL Message Structure). O objetivo não é memorizá-la — o ponto é que cada um deles corresponde a uma primitiva que um protocolo de LLM eventualmente adiciona novamente.

Canonical FIPA-ACL message

(inform
  :sender       agent1@platform
  :receiver     agent2@platform
  :content      "((price IBM 83))"
  :language     SL0
  :ontology     finance
  :protocol     fipa-request
  :conversation-id   conv-42
  :reply-with   msg-17
)

Sete campos carregam o envelope do protocolo; um campo (content) carrega o payload. O resto dos campos é exatamente o que você reinventa toda vez que adiciona tentativas de reenvio (retries), encadeamento (threading) e ontologia a um protocolo JSON.

As duas plataformas legadas

O JADE (Java Agent DEvelopment framework, 1999–década de 2020) era o ambiente de execução em conformidade com o FIPA mais utilizado. Os agentes estendiam uma classe base, trocavam mensagens ACL, rodavam dentro de containers e se coordenavam usando "comportamentos" (behaviors). A biblioteca de protocolos de interação vinha com contract-net, subscribe-notify, request-when e propose-accept.

O JACK (Agent Oriented Software, comercial) enfatizava o raciocínio BDI (Belief-Desire-Intention) sobre as mensagens FIPA. Mais formal, menos adotado.

Ambos declinaram quando a stack da web absorveu os casos de uso de multiagentes. O MCP e o A2A são os "containers" de execução de 2026.

Por que o FIPA enfraqueceu

• Sobrecarga de ontologia. O FIPA exigia uma ontologia compartilhada para fazer o parse de content. Chegar a um acordo sobre ontologias é um processo de padronização que leva anos. A web simplesmente usou HTTP + JSON.
• Semântica formal que ninguém usava. A SL (Semantic Language) fornecia condições de verdade rigorosas, mas a maioria dos sistemas de produção usava conteúdo de formato livre e ignorava o formalismo.
• Bloqueio de ferramentas (Tooling lock-in). O JADE era apenas para Java; o JACK era comercial. Equipes poliglotas contornaram ambos.
• A internet venceu a stack. REST, depois JSON-RPC e depois gRPC substituíram o transporte do ACL.

O renascimento dos LLMs é um FIPA-lite

Compare uma mensagem request do FIPA com um tools/call do MCP:

(request                                {
  :sender  agent1                         "jsonrpc": "2.0",
  :receiver tool-server                   "method":  "tools/call",
  :content "(lookup stock IBM)"           "params":  {"name":"lookup_stock",
  :ontology finance                                   "arguments":{"symbol":"IBM"}},
  :conversation-id c42                    "id": 42
)                                        }

Mesmo envelope, sintaxe diferente. Ambos carregam: quem envia, quem recebe, intenção, payload, id de correlação. Nenhum é uma revolução em relação ao outro — são trade-offs diferentes sobre o mesmo design.

O levantamento de 2025 de Liu et al. ("A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, ANP", arXiv:2505.02279) torna essa linhagem explícita: MCP corresponde a atos de fala de uso de ferramentas, A2A a atos de fala de agente para agente (peer-to-peer), ACP a atos de fala de trilha de auditoria e ANP a extensões de identidade descentralizada. As novas especificações são descendentes do ACL com sintaxe JSON e semânticas mais flexíveis.

O trade-off, explicado de forma simples

O que o FIPA oferecia e as especificações modernas descartam:

• Semântica formal — você pode provar que inform implica que o remetente acredita no conteúdo.
• Um catálogo canônico de performativos — você não precisa voltar a discutir "deveríamos ter um cancel?".
• Décadas de padrões de protocolos de interação — contract-net, subscribe-notify, propose-accept — com propriedades de corretude conhecidas.

O que as especificações modernas oferecem e o FIPA não oferecia:

• Payloads nativos em JSON compatíveis com qualquer ferramenta moderna.
• Conteúdo em linguagem natural que as LLMs podem interpretar sem uma ontologia codificada manualmente.
• Transporte baseado na stack da web (HTTP, SSE, WebSocket).
• Descoberta de capacidades por meio de documentos autodescritivos (MCP listTools, A2A Agent Card).

Semântica de intenção mais flexível para facilitar a implementação. Esse é exatamente o trade-off.

Protocolos de interação que vale a pena portar

O FIPA trazia cerca de 15 protocolos de interação. Três deles valem a pena trazer para os sistemas multiagentes com LLM:

1. Contract Net Protocol (CNP). O gerente emite um cfp (call for proposals / chamada para propostas); os licitantes respondem com propose; o gerente aceita ou rejeita. Este é o padrão canônico de mercado de tarefas (Fase 16 · 16 Negotiation).
2. Subscribe/Notify. O assinante envia subscribe; o publicador envia inform sempre que o tópico muda. Isso corresponde a todos os barramentos de eventos (event-bus) em 2026.
3. Request-When. "Faça X quando a condição Y for atendida." Ação atrasada com pré-condições. O análogo de 2026 são as tarefas adiadas em engines de workflow duráveis (Fase 16 · 22 Production Scaling).

Cada um se mapeia de forma limpa em filas de mensagens modernas, HTTP + polling ou streaming via SSE.

O que quebra quando descartamos a ontologia

Sem uma ontologia compartilhada, os agentes inferem o significado a partir do conteúdo em linguagem natural. O modo de falha documentado em 2026 é o desvio semântico (semantic drift): dois agentes usam a mesma palavra ("customer") para conceitos sutilmente diferentes, o agente receptor age com base na interpretação errada e nenhum validador de esquema detecta isso. A exigência de ontologia do FIPA teria rejeitado a mensagem no momento do parse.

Mitigações sem adotar uma ontologia completa:

• JSON Schema no content — rejeita erros estruturais na comunicação (wire).
• Artefatos tipados (A2A) — rejeitam a modalidade errada.
• Performativo explícito no envelope — torna a intenção inequívoca mesmo quando o conteúdo é em linguagem natural.

The 2026 specs, mapped to speech-act heritage

Build It

O arquivo code/main.py implementa um tradutor FIPA-ACL feito puramente com a biblioteca padrão (stdlib). Ele codifica e decodifica o envelope ACL canônico e mostra como cada formato de mensagem do MCP / A2A se reduz aos mesmos sete campos. A demonstração:

• Codifica cinco mensagens dos estilos MCP e A2A como FIPA-ACL.
• Decodifica FIPA-ACL de volta para o equivalente moderno.
• Executa uma negociação Contract Net de brinquedo entre um gerente e três licitantes usando cfp, propose, accept-proposal e reject-proposal.

Execute:

python3 code/main.py

A saída é um rastreamento lado a lado que mostra cada mensagem moderna tanto em sua forma JSON de 2026 quanto em sua forma FIPA-ACL, e então uma ida e volta de uma proposta contract-net. As mesmas primitivas de protocolo sobrevivem à ida e volta; apenas a sintaxe difere.

Use It

outputs/skill-fipa-mapper.md é uma habilidade (skill) que lê qualquer especificação de protocolo de agentes e produz o mapeamento FIPA-ACL. Use-a antes de adotar um novo protocolo para responder à pergunta: "Isso é genuinamente novo ou é apenas um inform com sintaxe JSON?"

Ship It

Não traga o FIPA-ACL de volta. Traga de volta a sua lista de verificação (checklist):

• Qual é a primitiva de intenção (performativo) de cada mensagem?
• Existe um id de correlação para requisição-resposta e cancelamento?
• Existe uma linguagem de conteúdo explícita (JSON-RPC, texto simples, artefato estruturado e tipado)?
• Os protocolos de interação são de primeira classe ou você está reimplementando o contract-net do zero?
• O que acontece quando dois agentes discordam sobre o significado do conteúdo (desvio semântico)?

Documente estas cinco perguntas para qualquer novo protocolo antes de enviá-lo para produção.

Exercícios

1. Execute code/main.py. Observe a codificação de ida e volta. Identifique qual performativo do FIPA corresponde a tools/call, resources/read e à criação de tarefas do A2A.
2. Estenda a demonstração do contract-net com um performativo cancel que permita ao gerente retirar a tarefa no meio da licitação. Qual caso de falha o cancel resolve que apenas as tentativas de reenvio (retries) não conseguem resolver?
3. Leia as seções 4.1 a 4.3 da FIPA ACL Message Structure (http://www.fipa.org/specs/fipa00037/). Escolha um performativo não abordado nesta lição e descreva seu análogo moderno em JSON-RPC.
4. Leia Liu et al., arXiv:2505.02279. Para cada um dos protocolos MCP, A2A, ACP e ANP, liste as famílias de performativos do FIPA que eles mantêm e descartam.
5. Projete um JSON-Schema mínimo para o campo content de um performativo request no seu próprio sistema. O que esse esquema oferece que a linguagem natural pura não oferece e qual é o seu custo?

Key Terms

Further Reading

• Liu et al. — A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, ANP — o levantamento canônico de 2025 que conecta as especificações modernas ao legado do FIPA
• FIPA ACL Message Structure Specification (fipa00037) — o formato de envelope ratificado em 2000
• FIPA Communicative Act Library Specification (fipa00037) — o catálogo completo de performativos
• MCP specification 2025-11-25 — o equivalente moderno de request/query-ref para uso de ferramentas
• A2A specification — o equivalente moderno de contract-net e subscribe-notify para comunicação entre agentes pares