À medida que ecossistemas de agentes se tornam mais distribuídos, um dos principais desafios deixa de ser a implementação da lógica de negócio e passa a ser a interoperabilidade entre agentes desenvolvidos por diferentes organizações, linguagens e infraestruturas.
O OpenIntent Protocol (OIP) propõe uma abordagem declarativa onde uma intenção é tratada como um contrato formal de execução, descrevendo não apenas a capacidade desejada, mas também como essa interação deve ocorrer.
O objetivo do protocolo é eliminar a necessidade de que agentes conheçam detalhes de comunicação, permitindo que implementações diferentes sejam interoperáveis a partir de uma especificação comum.
Observação: O OpenIntent Protocol encontra-se atualmente em desenvolvimento como parte da arquitetura H2A2H (v0.3). Sua especificação ainda está evoluindo e poderá sofrer alterações até a publicação da versão 1.0.
O problema atual
Hoje, quando dois serviços ou agentes precisam conversar, normalmente é necessário definir:
- qual protocolo será utilizado;
- como autenticar;
- como serializar mensagens;
- como tratar erros;
- como descobrir o destino;
- como realizar streaming ou eventos.
Isso faz com que a lógica da aplicação fique fortemente acoplada à infraestrutura.
Por exemplo:
Agent
↓
gRPC Client
↓
mTLS
↓
ProtoBuf
↓
Load Balancer
↓
Servidor
Se a comunicação mudar para NATS ou QUIC, normalmente o agente também precisa ser modificado.
O OpenIntent Protocol busca eliminar esse acoplamento.
Filosofia do OpenIntent Protocol
O protocolo parte de um princípio simples:
Um agente deve declarar o que deseja realizar, e não como deve se comunicar.
A infraestrutura já conhece o contrato da intenção.
O agente apenas produz ou consome intenções.
Arquitetura
O protocolo é dividido em quatro partes principais.
1. Intent
Define a operação semântica.
Exemplo:
- Validar pagamento
- Consultar estoque
- Emitir nota fiscal
- Reservar hotel
- Aprovar documento
A intenção representa o objetivo.
2. Capability
Define qual capacidade é necessária para executar aquela intenção.
Exemplo:
PaymentValidation
ou
InventoryReservation
Uma intenção pode possuir uma ou mais capacidades obrigatórias.
3. Channel
Define formalmente como aquela intenção deve trafegar.
O agente não escolhe.
O protocolo define.
4. Contract
Descreve:
- entradas;
- saídas;
- versão;
- compatibilidade;
- políticas;
- segurança.
Estrutura conceitual do arquivo
Uma possível estrutura do OpenIntent poderia ser:
version: 1
intent:
id: payment.validate
description: Validate a payment transaction
capability:
name: PaymentValidation
channel:
communication:
pattern: request_response
protocol: grpc
security:
authentication:
- mtls
authorization:
- capability_token
input:
transaction_id:
type: uuid
output:
status:
type: PaymentStatus
errors:
- PaymentNotFound
- Unauthorized
Todo o comportamento esperado está descrito no próprio contrato.
Padrões de comunicação
O protocolo suporta diferentes modelos de comunicação.
Request / Response
Utilizado quando existe resposta imediata.
Exemplos:
- autenticação;
- consulta;
- validação;
- cálculo.
Protocolos recomendados:
- gRPC
- HTTP/3
- QUIC
Streaming
Quando múltiplas respostas são esperadas.
Exemplos:
- geração de texto;
- vídeo;
- áudio;
- monitoramento.
Protocolos:
- WebTransport
- QUIC Streams
- WebSocket
- gRPC Streaming
Event
Comunicação baseada em eventos.
Exemplos:
- pedido criado;
- pagamento aprovado;
- usuário cadastrado.
Protocolos:
- NATS
- Kafka
- MQTT
Publish / Subscribe
Quando diversos agentes devem receber uma mesma informação.
Exemplo:
OrderCreated
↓
BillingAgent
InventoryAgent
AnalyticsAgent
NotificationAgent
Protocolos:
- NATS
- Kafka
- MQTT
Fire-and-Forget
Quando não existe necessidade de resposta.
Exemplos:
- auditoria;
- logs;
- métricas;
- telemetria.
Protocolos:
- UDP seguro
- QUIC Datagram
- NATS
Definição do canal
No OpenIntent o canal também faz parte do contrato.
Exemplo:
channel:
pattern: event
transport:
protocol: nats
qos:
delivery: at_least_once
persistence:
enabled: true
Outro exemplo:
channel:
pattern: streaming
transport:
protocol: webtransport
compression:
enabled: true
O agente não implementa manualmente nenhum desses protocolos.
Papel do Agent SDK
O Agent SDK é responsável por interpretar o OpenIntent Protocol.
A partir da definição declarativa ele gera automaticamente:
- clientes;
- serializadores;
- autenticação;
- conexões;
- handlers;
- validação.
O agente continua enxergando apenas uma API simples:
execute(intent)
ou
publish(intent)
Toda a infraestrutura é materializada pelo SDK.
OpenIntent + OpenEntityChannels
O OpenIntent Protocol trabalha em conjunto com o OpenEntityChannels.
Enquanto o OpenIntent descreve a intenção semântica, o OpenEntityChannels descreve as características do canal utilizado.
Essa separação permite evoluir transportes sem alterar o significado da intenção.
Benefícios
Interoperabilidade
Agentes escritos em linguagens diferentes conseguem compartilhar contratos comuns.
Padronização
Todas as intenções seguem o mesmo formato.
Geração automática
Grande parte do código de infraestrutura pode ser gerada.
Auditabilidade
O comportamento esperado fica registrado no contrato.
Evolução
Novos protocolos podem ser suportados pelo SDK sem exigir alterações na lógica dos agentes, desde que continuem compatíveis com os padrões declarados pelo OpenIntent Protocol e pelo OpenEntityChannels.
Fluxo de execução
Humano
↓
Agent
↓
OpenIntent Protocol
↓
Agent SDK
↓
OpenEntityChannel
↓
Transporte definido no contrato
↓
Agent Executor
↓
Resultado
↓
Humano
Observe que o transporte não é escolhido em tempo de execução. Ele já faz parte da especificação do contrato da intenção, garantindo comportamento determinístico entre diferentes implementações do protocolo.
Próximos passos
A especificação atual representa a base do OpenIntent Protocol, mas diversos elementos ainda estão em desenvolvimento para a versão 1.0, incluindo:
- versionamento e negociação de compatibilidade;
- composição e encadeamento de intenções;
- definição formal de tipos e schemas;
- descoberta distribuída de capacidades;
- assinatura criptográfica das intenções;
- execução assíncrona e de longa duração;
- extensões para auditoria e rastreabilidade;
- integração formal com os protocolos OpenDelegation Protocol e Proof-of-Human-Return, compondo o ecossistema H2A2H.
O objetivo é que o OpenIntent Protocol se torne um contrato aberto para comunicação entre agentes, independente de linguagem, framework ou infraestrutura, permitindo que diferentes implementações interoperem por meio de uma especificação comum.
Top comments (0)