Direções Futuras do A2A: Os Agentes Estão Planejando Montar uma Rede Local

O A2A já permitiu que Hermes em dois computadores “ligassem” um para o outro. E o próximo passo? Na lista de desejos da comunidade, há um plano muito maior escondido.

O que já dá para fazer: revisitando o “telefone” em si

O A2A v1.0 já foi implementado. Em termos simples, ele permite que Hermes em máquinas diferentes troquem cartões de visita (Agent Card), se comuniquem com um protocolo padrão (JSON-RPC), atualizem o progresso em tempo real (streaming via SSE) e lembrem do contexto de conversas de múltiplas rodadas. A segurança já vem boa por padrão: cada peer tem um token independente e todas as operações têm logs de auditoria. Isso é como dar a cada Hermes um “telefone de trabalho” — dá para ligar, mandar SMS e deixar mensagem de voz, mas só em chamadas de um para um.

Direção 1: Rede Local de Agentes (Rede de Coordenação Multi-Nó)

A proposta mais popular na comunidade é transformar o “telefone” em uma “rede local”. Você tem uma estação de trabalho macOS, um desktop Windows, um servidor Linux, e até um notebook e um celular, cada um rodando um Hermes. Hoje eles operam isolados; no futuro, a ideia é que formem uma “rede local de agentes” através de uma rede overlay privada. É como conectar todos os dispositivos inteligentes da sua casa ao mesmo Wi-Fi: você dá um comando e a caixa de som da sala, as luzes do quarto e o forno da cozinha respondem em conjunto. Para o Hermes, isso significa que tarefas podem fluir automaticamente entre vários dispositivos: os dados coletados no notebook são sincronizados automaticamente para a estação de trabalho fazer o processamento profundo, e os resultados são enviados para o seu celular para você revisar.

Direção 2: Hierarquia de Agentes (Chefe e Subordinado)

Hoje, os Hermes estão em “pé de igualdade” — quem inicia a conversa é o lado ativo. O que a comunidade quer é uma “relação hierárquica”: um Hermes líder pode delegar tarefas para um Hermes subordinado em outra máquina, e o líder consegue ver em tempo real em que etapa a tarefa está — atenção, “ver”, não “interferir”. É como um chefe delegando trabalho a um funcionário: você só precisa saber o progresso, sem ficar monitorando cada passo. Essa “observabilidade passiva” é crucial: mantém a autonomia do subordinado e dá tranquilidade ao chefe.

Direção 3: Colaboração Multi-Sessão (De Ilhas a Sala de Reunião)

Atualmente, se você abre três sessões na mesma máquina — uma para pesquisa, uma para implementação, uma para revisão — elas são três ilhas isoladas. Informações-chave descobertas na sessão de pesquisa precisam ser copiadas e coladas manualmente na sessão de implementação, algo frágil e propenso a erros. A proposta da comunidade é permitir que essas sessões troquem “mensagens” entre si e compartilhem o contexto necessário. Imagine: em vez de três cubículos separados, uma sala de reunião onde três pessoas podem passar bilhetes e trocar ideias a qualquer momento, mas cada uma mantém suas anotações privadas.

Direção 4: Rádio Local (Mensagens Entre Sessões)

Essa proposta é mais focada: múltiplas sessões interativas de Hermes na mesma máquina deveriam ter um mecanismo de mensagens local de “primeira classe”. Sem precisar de protocolo de rede — como um rádio de escritório: aperta o botão e fala. A sessão de pesquisa encontrou um material importante e “chama” direto a sessão de implementação: “Ei, presta atenção no uso daquela API no terceiro parágrafo.” Sem copiar e colar, sem soluções frágeis como tmux send-keys. Isso complementa a Direção 3: uma cuida da comunicação entre máquinas, a outra da comunicação local.

Direção 5: Política de Aprovação Remota (Portaria de Segurança)

O A2A já permite que peers remotos enviem tarefas para sua sessão ao vivo, o que é útil, mas também arriscado — e se o outro lado pedir para você modificar um arquivo? A comunidade quer uma política de “peers confiáveis com escopo”: você pode designar um Hermes específico em uma máquina específica como “confiável”, e as tarefas que ele enviar podem executar efeitos colaterais locais; todos os outros são somente leitura. É como um crachá de empresa: uns têm acesso à sala financeira, outros só à sala de reunião. Isso é uma peça-chave para a segurança na delegação.

Direção 6: Notificações Visíveis de Conclusão de Tarefas

Hoje, quando uma tarefa A2A é concluída, o resultado vai para o log ou é retornado via resposta JSON-RPC. Mas e se você não estiver olhando o log? A comunidade quer que, quando a tarefa terminar, uma notificação apareça no canal do Hermes que você está usando normalmente — como um push no celular: “A tarefa que você delegou naquela máquina terminou, o resultado está aqui.” Não interrompe você, mas te mantém informado.

O que já foi parcialmente implementado?

Boa notícia: o conceito de “worker com limites” proposto pela comunidade já foi parcialmente implementado — um launcher externo configurável que restringe o limite de execução de tarefas remotas. Isso é como lançar a fundação para a “aprovação remota”. Além disso, detalhes como timeout de 330 segundos, resultados atrasados e isolamento de contexto já estão prontos. Mas atenção: as grandes direções como coordenação multi-nó, hierarquia e rádio local ainda são apenas desejos em issues em aberto.

O que isso significa para você?

Se você é um usuário comum, essas direções significam: no futuro, o Hermes pode deixar de ser um “soldado isolado” para se tornar um “time” que trabalha em conjunto. Você não precisa se preocupar com como eles se comunicam — só precisa saber que todos os Hermes nos seus dispositivos vão se ajudar como uma família, e nada que você precisa saber vai passar despercebido.

Um último lembrete: essas são todas issues em aberto propostas pela comunidade. O diretório oficial .plans foi removido (2026-08), então não há garantia de que tudo será implementado. Mas pelo menos, o blueprint já foi desenhado — os agentes estão planejando montar uma rede local, e desta vez, eles pretendem conectar a “casa” também.