Início/Blog/Padrões para agentes de IA Arquitetura de IAPadrões para agentes de IA e a nova fronteira backend
Fronteiras backend costumavam ser definidas principalmente por contratos de request e response. Agentes interoperáveis ampliam essa superfície: descoberta de capacidades, autoridade delegada, tarefas longas, tool calls, mensagens entre agentes, artefatos, aprovações, orçamentos e trilhas de auditoria.
Publicado em 8 de junho de 202612 min de leituraInteroperabilidade de agentes
Padrões estão tirando agentes de demos isoladas
O NIST lançou sua AI Agent Standards Initiative em fevereiro de 2026 com foco em interoperabilidade, desenvolvimento de protocolos abertos, segurança e identidade. Seu relatório de segurança de maio de 2026 encontrou amplo consenso de que princípios conhecidos de cibersegurança continuam relevantes, mas precisam ser adaptados para sistemas de agentes. Esse é o sinal importante para times backend: agentes estão se tornando atores externos dentro de sistemas reais, não apenas interfaces de chat.
MCP padroniza como agentes interagem com ferramentas e recursos. A2A padroniza como agentes independentes se descobrem e trocam tarefas. OpenAPI continua descrevendo os contratos de serviço por baixo. Padrões de identidade e autorização definem quem pode agir. A nova fronteira backend é onde tudo isso se encontra.
Ecossistema de padrões para agentesPrincipalPessoa, tenant, organização ou serviço delega uma tarefa.
IdentidadeIdentidade do agente, principal responsável, escopos e cadeia de delegação.
A2AAgentes descobrem capacidades e trocam tarefas, mensagens e artefatos.
MCPAgentes descobrem e invocam tools, resources, prompts e dados.
BackendServiços OpenAPI, filas, workflows, bancos de dados e policy engines.
EvidênciasEstado da tarefa, aprovações, custos, tool calls, resultados e histórico.
Interoperabilidade cria contratos além do formato JSON
Contratos tradicionais de API se concentram em entradas, saídas e erros. Contratos de agentes também precisam explicar capacidade, autoridade, duração esperada, efeitos colaterais, progresso, cancelamento, artefatos, custos e o que acontece quando o agente remoto desaparece. Um schema informa que um campo é string. Ele não informa se um agente pode realizar o pedido representado por aquela string.
É por isso que a conversa sobre padrões muda a arquitetura backend. A fronteira precisa de compatibilidade de protocolo e compatibilidade de política. Dois agentes podem falar o mesmo protocolo e ainda discordar sobre identidade, confiança, tratamento de dados ou efeitos colaterais aceitáveis.
CapacidadeO que o agente ou a tool realmente pode fazer e em qual versão?
AutoridadeQuem delegou a tarefa, com quais escopos, limites e expiração?
EstadoQual é o ciclo de vida, progresso, timeout, retry e caminho de cancelamento?
EvidênciaCada mensagem, ação, artefato, aprovação e custo pode ser reconstruído?
A fronteira precisa de um control plane para agentes
Protocolos não devem ser confundidos com governança. MCP pode descrever e invocar tools, mas o backend ainda precisa verificar permissões. A2A pode mover tarefas entre agentes, mas o backend ainda precisa decidir quais agentes são confiáveis. OpenAPI pode descrever uma operação, mas o backend ainda precisa de idempotência, quotas e rollback.
Um control plane prático fica entre os protocolos e os sistemas de produção. Ele verifica a identidade do agente, resolve o principal responsável, aplica política, cria registros de tarefa, limita orçamento, roteia chamadas, observa progresso, exige aprovação para ações de alto risco e produz evidências de auditoria.
| Superfície padronizada | O que ela padroniza | Controle backend ainda necessário |
|---|
| MCP tools e resources | Descoberta e invocação de capacidades e contexto externos. | Allowlists de tools, validação de argumentos, política de tenant, rate limits e aprovação. |
| Tarefas A2A e agent cards | Descoberta de agentes, troca de tarefas, mensagens, artefatos e ciclo de vida. | Registro de confiança, validação de delegação, orçamento, cancelamento e evidências. |
| Serviços OpenAPI | Operações HTTP, schemas, respostas e descrições de autenticação. | Autorização em runtime, idempotência, classificação de dados, quotas e rollback. |
| Padrões de identidade | Autenticação, claims, tokens, escopos e acesso delegado. | Mapeamento do responsável humano, credenciais efêmeras, revogação e segregação de funções. |
| Padrões de eventos | Notificações estruturadas para mudanças de estado e workflows assíncronos. | Proteção contra replay, ordenação, deduplicação, retenção e correlação de incidentes. |
| Evidências de auditoria | Nenhum protocolo isolado possui a trilha completa. | Ledger unificado ligando identidades, mensagens, tools, aprovações, outputs e custos. |
O que eu construiria
Eu construiria um serviço de fronteira para agentes que fala MCP com ferramentas, A2A com agentes externos, OpenAPI com serviços internos e eventos com sistemas de workflow. Cada request viraria um registro de tarefa com principal, identidade do agente, escopos, orçamento, nível de risco, artefatos esperados, política de aprovação e expiração.
O produto visível seria um mapa do ecossistema de agentes: quais agentes existem, quem é responsável por eles, quais protocolos e versões suportam, quais tools e agentes podem chamar, quais dados acessam, suas tarefas atuais e as evidências por trás de cada ação concluída.
O princípio de design
Padrões tornam agentes interoperáveis. Controles backend tornam essa interoperabilidade sustentável. A nova fronteira não é um único endpoint de API; é o ponto onde capacidade, identidade, delegação, estado, política e evidências são reunidos antes que software autônomo receba permissão para agir.