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

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

No meu caso, isso se tornou meu “segundo turno” favorito — aquelas horas extras à noite e nas manhãs de sábado. Sempre fui fã disso.

No ano passado, junto com Marcell e Farinazzo, construímos o PromptMetrics durante a competição Lovable Shipped, e eu compartilhei cada passo dela. Foi uma experiência intensa de 0 a 1 que me mostrou o poder da execução rápida.

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 finalmente dominar 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 que acabou de chegar à versão 2.1.1.

Neste artigo, estou abrindo o “cérebro” do projeto, o workflow de vibe coding 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 em uma 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.

Vibe coding: 85% IA e 15% humano

As pessoas costumam me perguntar como eu mantenho esse ritmo. A verdade é: o desenvolvimento foi 85% assistido pelo Cursor.

Mas não se engane — os 15% de trabalho manual são onde acontecem as decisões arquiteturais e os trade-offs.

Meu setup atual é o que eu chamo de “orquestração de modelos”:

• Planejamento: Claude Opus 4.6 (no MAX Mode do Cursor, com reasoning alto).
• Desenvolvimento: Composer 1.5 e o modo auto do Cursor para o trabalho pesado.
• Revisão técnica: eu não confio em um único modelo. Passo o código por GPT-5.2 Codex, Gemini 3.1 Pro e Kimi K2.5 para encontrar bugs de lógica ou gargalos.

A IA não substitui o arquiteto; ela o potencializa. Eu foco no “o quê” e no “por quê”, enquanto a IA cuida do “como”.

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

Para não me perder no caos da IA gerando milhares de linhas de código, organizei meu repositório para que a IA pudesse entender todo o contexto de produto e de engenharia.

A pasta .cursor/ é o centro de comando:

• product-specs: onde eu mantenho ADRs (Architecture Decision Records) e PRDs de cada versão.
• dev-planning: onde as sprints são quebradas em tarefas granulares para que a IA não “alucine” nem se perca durante o processo.
• skills, rules e commands: prompts especializados que ensinam a IA a revisar segurança ou qualidade de código especificamente para os padrões do ASAP.

Essa estrutura me permite delegar a execução para a IA mantendo governança total sobre o design do sistema.

Da fundação ao marketplace: o roadmap

A evolução do ASAP foi planejada em marcos claros para garantir que cada release entregasse valor real. Conforme construímos, o escopo cresceu à medida que novas ideias surgiram 🤯.

v1.0: fundação técnica

Foco na estabilidade do protocolo. Definimos como as mensagens seriam estruturadas e como o estado seria persistido usando uma estratégia híbrida entre SQLite e interfaces flexíveis de armazenamento.

v1.2: identidade verificada

Foco em segurança. Implementei assinaturas Ed25519 para garantir que um agente não pudesse se passar por outro. Usamos o padrão JCS para canonicalização e verificação estrita.

v2.0: lançamento do marketplace

Esse marco transformou o protocolo em uma camada econômica. Criei uma interface web onde qualquer dev pode registrar seu agente por meio de um fluxo simples de IssueOps no GitHub. Nosso Lite Registry roda no GitHub Pages para manter os custos de infraestrutura em zero.

v2.1: ecossistema e integrações

Quem constrói agentes agora consegue encontrar e invocar agentes do marketplace em minutos, sem integrações manuais. Foquei em integrações nativas com LangChain, OpenClaw, LlamaIndex, SmolAgents e suporte a MCPs (Model Context Protocol).

Categorias e revogação mantêm o catálogo confiável e fácil de navegar. Com o pacote no PyPI, experimentar está a um pip install de distância.

O que vem por aí: v2.2 ➔ v3.0

Atualmente, estou focado em fechar a v2.2, que gira em torno de escala e facilidade de adoção:

• Auto-registro: implementar GitHub IssueOps para que novos agentes sejam listados sem PRs manuais.
• Agent builder: uma interface visual para qualquer desenvolvedor configurar as capacidades do seu agente e exportar um manifesto pronto para o marketplace.

Na v3.0, chegamos ao objetivo final: a camada de economia. Isso inclui o Verified Badge para agentes de alta reputação, um sistema de créditos para cobrança automatizada de uso e monitoramento de SLA em tempo real.

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

Aprender é o único ROI garantido

No fim do dia, 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 podem usar.

Mesmo que o ASAP não se torne o padrão da indústria, meu ganho é entender exatamente como tudo funciona por baixo do capô e o raciocínio por trás da construção.

Se você quiser criticar minha arquitetura, abrir uma issue ou dar uma estrela 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.