A IA trouxe os side projects de volta: construindo um protocolo de comunicação entre agentes

Vi recentemente um post no LinkedIn que realmente me fez pensar: a IA tornou possível voltarmos a ter side projects para aprender e testar ideias.

No meu caso, isso virou o meu segundo turno — aquelas horas extras à noite e nas manhãs de domingo.

Sempre fui fã disso.

No ano passado, junto com amigos, construímos o PromptMetrics durante a competição Lovable Shipped, chegando ao top 15 global em uma das fases (e terminando em 25º no geral, entre 5.800 times).

Foi uma experiência intensa de 0 a 1 que me mostrou o poder da execução rápida com IA.

Este ano, decidi que meu foco seria um aprendizado técnico mais profundo. Eu queria colocar a mão na massa com implementação real, entender arquitetura de serviços e entrar numa linguagem nova, e fui parar no Python.

Foi assim que nasceu o protocolo ASAP: um protocolo de comunicação para agentes de IA (pense em A2A, mas melhor 😜).

O que começou como uma curiosidade sobre como os agentes conversam entre si virou um projeto open source completo.

Estamos na v2.5.4, pronto o bastante para produção a ponto de a pergunta interessante ter mudado de “os agentes conseguem conversar?” para “um estranho consegue instalar, ligar e entregar numa tarde?”.

Neste artigo, estou abrindo o “cérebro” do projeto, o harness que usei e como organizei a arquitetura para ir de um rascunho nerd a um marketplace funcional de agentes.

O problema: por que outro protocolo?

A ideia surgiu numa conversa com meu time na Pipefy, sobre as deficiências de protocolos como o A2A e as reclamações comuns em fóruns de devs.

O desafio não é só a comunicação. É padronização, confiança e descoberta.

Eu queria algo leve e focado em performance.

Queria ver como gRPC e FastAPI poderiam trabalhar juntos para criar uma camada de transporte que não engasgasse com latência.

Meu workflow: 80% IA e 20% humano

O desenvolvimento foi ~80% assistido por Cursor Cloud Agents, mas não se engane: os 20% de trabalho manual são onde acontecem as decisões arquiteturais e os trade-offs.

Meu setup atual:

• Planejamento: Fable ou GPT 5.6 ou Astra (no MAX Mode, com reasoning alto).
• Desenvolvimento: Composer 2.5 e o Grok 4.x do Cursor para o trabalho pesado.
• Revisão técnica: não confio em um modelo só. Passo o código por outros modelos para achar bugs de lógica ou gargalos.

Eu foco no “o quê” e no “por quê”, enquanto o modelo cuida do “como”.

A mudança maior não é só qual modelo eu escolho numa noite.

É que o repositório agora força governança antes da geração: AGENTS.md como mapa de contexto, regras sempre ligadas para segurança e commits, skills de revisão de segurança e de qualidade de código, e um gate de CI antes do push que eu de fato rodo localmente.

O “cérebro” do projeto: context engineering na prática

Para a IA não gerar milhares de linhas espertas na direção errada, parei de tratar o repositório como “código + vibes” e passei a tratá-lo como um sistema operacional de produto.

O centro de comando continua orientado a agentes, mas o mapa mudou:

• product/prd e product/decision-records: PRDs e ADRs de cada trem de release (a fonte da verdade do escopo).
• engineering/tasks: sprints quebradas em pacotes granulares para o agente não se perder no meio do voo.
• AGENTS.md + cursor/README.md: um mapa de contexto e uma ordem de precedência (regras do usuário → regras sempre ligadas → skills → docs).
• rules e skills: restrições e workflows fundos — revisão de segurança, código limpo, teste de rate limit, padrões de frontend.

Ainda delego a execução. Só parei de delegar o julgamento.

Se a IA não consegue apontar um PRD, um ADR ou um pacote de tarefas, ela não inventa feature.

A árvore continua com cara de nerd. É esse o ponto. Context engineering deixou de ser slide e virou o jeito como o projeto entrega.

Da fundação ao marketplace: o roadmap

A evolução do ASAP foi planejada em marcos claros para cada release entregar valor de verdade. Conforme construímos, o escopo cresceu à medida que ideias novas apareciam 🤯.

v1.0: Fundação técnica

Estabilidade do protocolo, estrutura das mensagens e persistência híbrida (SQLite + interfaces flexíveis de storage).

v1.2: Identidade verificada

Assinaturas Ed25519 + canonicalização JCS para um agente não conseguir se passar por outro.

v2.0: Lançamento do marketplace

Isso transformou o protocolo numa camada econômica. Uma interface web em que qualquer dev registra o agente por um fluxo simples de IssueOps no GitHub.

O Lite Registry roda no GitHub Pages para manter o custo de infraestrutura em zero enquanto validamos a ideia.

v2.1: Ecossistema e integrações

Adaptadores nativos para LangChain, OpenClaw, LlamaIndex, SmolAgents e suporte a MCPs. Categorias, revogação e o pacote no PyPI tornaram descoberta e instalação triviais.

v2.5.4: onde estamos agora

O marketplace está no ar em asap-protocol.com.

Adicionamos o MCP Auth Bridge (ferramentas nativas com escopo via Agent JWTs), um SDK em TypeScript, conectores OpenAPI, filtros de descoberta para edge-AI e um harness de compliance.

O que vem pela frente

v2.5.5

A especificação formal, introspecção e interoperabilidade entre protocolos.

Agent builder

Uma interface visual para qualquer desenvolvedor configurar as capacidades do agente e exportar um manifesto pronto para o marketplace.

Parte dos dados é real e parte é mock. Ainda estou integrando essa jornada ao marketplace.

v3.0

A camada econômica: Verified Badge, um sistema de créditos para cobrança de uso e monitoramento de SLA em tempo real.

O protocolo e o registry continuam abertos. O valor está na visibilidade, na confiança e na liquidez entre agentes.

Aprender é o único ROI garantido

No fim das contas, construir em público continua sendo a melhor “universidade” que já frequentei.

Aprendi a criar um protocolo de ponta a ponta, lidei com segurança criptográfica, construí um design system do zero e publiquei pacotes no PyPI que pessoas reais conseguem usar.

Mesmo que o ASAP não vire o padrão da indústria, o meu ganho é entender exatamente como tudo funciona por baixo e a lógica da construção.

Se quiser criticar a arquitetura, abrir uma issue ou dar star no repo — a porta está aberta. É open source; venha contribuir.

Foi assim que muitas das ferramentas que usamos hoje começaram.

É hora de construir, LFG.