Resumo

  • A ata publicada chama os oito resultados de sondagem não vinculante do sentimento da sala e diz que o consenso seria confirmado na lista. Ela não registra uma Working Group criada nem uma carta aprovada.
  • A pergunta sobre o escopo inicial terminou em 38 sim, 124 não e 40 sem opinião; os entregáveis, em 92–58–49; a formação de uma WG “com esta carta”, em 154–51–5.
  • É coerente desejar uma sede institucional e exigir outro escopo. Ainda assim, a expressão “com esta carta” obriga os responsáveis a explicar qual reparo condicionava o apoio geral.
  • Os totais variam e não há cruzamento por participante. Não se pode afirmar que as mesmas 124 pessoas que rejeitaram o escopo compunham uma parcela determinada dos 154 apoios.
  • A carta mostrada pode ser congelada no commit a9405f3d5d0a4e8c67342d7945137c8230b9cd05. Mensagens e uma pull request posterior, ainda aberta e não incorporada, comprovam que limites centrais continuavam em disputa.
  • No corte, o Datatracker mantinha Agentproto como BOF, com Carta (None). Uma matriz de reconciliação de proposições ligaria pergunta, texto, objeções, mudanças, confirmação e decisão sem transformar rough consensus em eleição.

A pergunta é parte do dado

A leitura mais curta diz: 154 pessoas apoiaram o Agentproto. Outra leitura curta diz: 124 pessoas rejeitaram o Agentproto. As duas frases escolhem um verbo que a fonte não oferece.

A ata do BoF no IETF 126 descreve uma sessão de formação de WG em 23 de julho de 2026. O próprio documento, porém, está marcado como rascunho para revisão dos chairs. Foi compilado com um agent harness de IA a partir de notas humanas, conversa no Zulip e slides; nomes e afiliações eram provisórios, a presença total não estava disponível e a responsabilidade pela correção final permanecia humana.

Essa declaração de origem deve acompanhar a citação. Ela não prova que algum número esteja errado, mas impede que um rascunho seja apresentado como transcrição encerrada.

O limite institucional é ainda mais explícito. As mãos levantadas no Meetecho mediram o sentimento da sala; o resultado não era vinculante e o consenso precisava ser confirmado na lista. A agenda 01 colocou as chamadas de consenso depois das apresentações e do microfone aberto. O texto prévio sobre os BoFs do IETF 126 explicou que uma sessão formativa testa consenso, energia e estreiteza de escopo. Não havia razão para esperar que os três testes produzissem o mesmo placar.

O mapa completo das respostas

O problema bem compreendido, solucionável e útil recebeu 124–72–14. A necessidade clara de interoperabilidade, 155–30–8. O IETF como lugar correto, 158–30–14. O escopo inicial correto, 38–124–40. Os entregáveis iniciais corretos, 92–58–49. Formar uma WG “com esta carta”, 154–51–5. Disposição para escrever ou revisar, 137–17–40. Disposição para implementar, 42–28–40.

A síntese da ata respeita as diferenças. Ela encontra apoio forte para resolver o problema, para a interoperabilidade, para o IETF e para formar um grupo. Ao mesmo tempo, declara que o escopo inicial escrito não recebeu apoio e que os entregáveis dividiram opiniões. Laurent Ciavaglia advertiu que “correto” não deveria ser confundido com “completo”. A discussão seria levada à lista.

Os totais de respostas — 210, 193, 202, 202, 199, 210, 194 e 110 — também variam. Não existiu um colégio estável emitindo oito votos formais. Não sabemos quem se absteve, saiu, chegou ou preferiu não responder a uma pergunta.

Também não existe uma tabela conjunta. O dado público não mostra quantas pessoas disseram não ao escopo e sim à formação. Logo, não autoriza dizer que “as mesmas 124 pessoas” executaram os dois atos. Presumir que os grupos não se sobrepunham seria igualmente injustificado.

O processo pode esclarecer a interpretação sem expor nomes. Os chairs podem agrupar motivos — escopo excessivo, falta de item, conceito ambíguo, entregável errado — e indicar se o apoio geral pressupunha correções específicas. Essa é uma explicação de julgamento, não um cadastro eleitoral.

Uma condição não é uma contradição

Há posições perfeitamente razoáveis que geram os dois resultados. Uma pessoa pode querer um grupo e retirar o ciclo de vida de sessões. Outra pode aceitar um framework e rejeitar um protocolo. Outra pode considerar o texto incompleto e, por isso, não “correto”. Outra pode confiar que a lista resolverá as fronteiras antes da aprovação.

O RFC 5434 recomenda perguntas por partes justamente para localizar acordos e lacunas. Mas seu exemplo de pergunta integrada é apoio para formar uma WG com a carta seguinte, explicado como teste de que a própria carta está pronta. A pergunta 6 de Agentproto preservou essa ligação textual.

Por isso, a interpretação positiva não precisa ser descartada, mas deve declarar sua condição. Se o sim queria dizer “depois de corrigir o escopo”, o registro precisa nomear as correções. Se “correto” foi ouvido como “completo”, precisa identificar o que faltava. Se uma futura carta mudar substancialmente, ela não herdará 154 apoios de pessoas que não viram aquela redação; dependerá da confirmação e aprovação posteriores.

Ao manter a condição, o 154 não vira cheque em branco e o 124 não vira rejeição de toda a área de trabalho.

A carta da sala deve ser imutável no passado

A ata liga a carta e relata que o texto corrente ficou visível. O repositório oficial conserva a carta no commit a9405f3…, criado em 21 de julho, dois dias antes do BoF. No corte, o histórico do arquivo devolvia apenas esse commit.

O conteúdo abrangia comunicação agent-to-agent, agent-to-tools e determinados mecanismos humano-agente. Falava de identidade independente, autorização, confidencialidade, integridade e auditabilidade. Os entregáveis incluíam um protocolo de sessão Standards Track e um framework Informational. O protocolo lidaria com sessões curtas e longas, contexto, recuperação de falhas, dados de ritmos distintos e topologias ponto a multiponto.

Fixar o commit não prova leitura integral nem interpretação uniforme. Ele impede que “esta carta” se torne um link móvel. Uma revisão pode ser melhor e continuar legítima; só não é o mesmo objeto consultado.

As disputas posteriores mudavam a substância

Em 12 de agosto, Suresh Krishnan escreveu “Sussing out points of disagreement on the charter” e relatou duas reescritas de raiz. Seis questões permaneciam: substrate ou semantics; ciclo de vida de sessão; correlação ou prova de binding; ponto a multiponto ou bilateral; número, status e ordem dos entregáveis; e precisão da terminologia.

Cada uma altera o que o eventual grupo poderia fazer.

A pull request 77, aberta depois do BoF contra o commit da reunião, propôs um “minimum viable primitive”. Ela tiraria o ciclo de vida de sessão do escopo e substituiria o protocolo de sessão por uma interaction reference e seu binding envelope. Continuava aberta e não mesclada. Sua descrição informa que a formulação usou análise de chat assistida por IA. Isso é procedência, não aprovação.

Uma proposta de 26 de agosto sobre requisitos de evidência mostra o mesmo problema em escala menor. Nancy Sahu sugeriu dizer o que uma evidência operacional prova e não prova, e remover ou reparar a referência a auditabilidade caso o único entregável que a carregava fosse excluído. É uma contribuição individual. Seu valor aqui está em mostrar a dependência entre promessa e entrega.

O balanço do IETF 126 de 1º de setembro diz que Agentproto testou consenso para chartering e que a conversa continua na lista. A página atual do Datatracker mantinha BOF, Carta (None) e “Not chartered yet”. O valor nulo não nega o trabalho; informa que a transferência de autoridade não ocorreu.

Da sondagem à autorização

O RFC 2418 / BCP 25 atribui a aprovação final de uma carta ao IESG, com aconselhamento do IAB e trabalho prévio do Area Director. O IESG pode aprovar, pedir mudanças ou recusar. Depois de aprovado, o grupo é registrado e anunciado.

O texto também diz que 51% não é rough consensus e trata da confirmação em lista de conclusões presenciais. Números, julgamento e autoridade desempenham funções complementares: os números expõem intensidade; chairs avaliam objeções; a lista inclui ausentes; os órgãos definidos concluem o ato.

A crítica de Heng Lu sobre presença convertida em mandato é usada aqui de forma estreita. Participação oferece evidência, perícia, alerta e oposição. Não ocupa automaticamente o lugar da autoridade formal. Aplicar essa disciplina ao Agentproto preserva tanto o apoio quanto a rejeição de escopo, em vez de usar “a comunidade” para apagar um deles.

A matriz de reconciliação de proposições

Uma linha começa por identificador, pergunta integral e decisão que ela pretende informar. Em seguida vêm commit e blob exibidos, horário, método, sim/não/sem opinião, total e rótulo não vinculante.

Outra parte registra interpretação: termos ambíguos, classes não identificáveis de objeção, diferença entre correto e completo, cláusulas a alterar e condições do apoio. A ausência de cruzamento individual deve permanecer como desconhecida, não ser preenchida por inferência.

Por fim vêm confirmação e autoridade: intervalo da lista, links, síntese fundamentada dos chairs, disposição das objeções, ação do Area Director, aconselhamento do IAB, decisão do IESG e commit final — ou null enquanto não existir. Correções entram como histórico, sem apagar o estado anterior.

Hoje, Agentproto mostraria apoio ao problema, à interoperabilidade e à sede; falta de apoio ao escopo inicial; divisão sobre entregáveis; energia para escrever; revisão ainda aberta; carta final e aprovação ausentes. Não é um resultado indeciso. É um diagnóstico específico.

Objeções e limites

Uma matriz pode seduzir leitores para maioria simples. Por isso, a fundamentação dos chairs, as objeções e o status de autoridade precisam ter o mesmo peso visual dos totais. A versão fixa também não deve congelar debate: ela separa objetos para que a mudança seja honesta.

Boletas nominais seriam contraproducentes. Criariam facções e pressão de empregadores. Agregados e motivos bastam. A carga administrativa deve ser pequena: atas, commits, lista e eventos do Datatracker já existem; a matriz apenas os une.

Este artigo não decide se Agentproto deve nascer, não escolhe protocolos e não avalia MCP, A2A ou outras implementações. Não prova erro, manipulação, má-fé nem invalidez. Não conhece respostas individuais. A ata é rascunho, mensagens e pull requests são propostas, e o estado poderá mudar.

O achado é delimitado: uma proposição integrada recebeu apoio enquanto o componente de escopo não recebeu, e o texto continuou em disputa. A confiança depende de preservar o caminho entre o que foi perguntado e o que vier a ser autorizado.

Fontes

  1. Heng Lu — The Multi-Stakeholder Mirage
  2. IETF 126 — Ata do BoF Agentproto
  3. IETF 126 — Agenda Agentproto, versão 01
  4. IETF — IETF 126 Highlights
  5. IETF — Birds of a Feather at IETF 126
  6. Carta Agentproto no commit a9405f3…
  7. Datatracker — Página atual do Agentproto
  8. RFC 5434 — Considerations for Having a Successful BOF Session
  9. RFC 2418 / BCP 25 — IETF Working Group Guidelines and Procedures
  10. Lista Agentproto — Sussing out points of disagreement on the charter
  11. Lista Agentproto — Proposed charter text: evidence requirements
  12. Repositório de cartas ART — Pull request 77