La IA trajo de vuelta los side projects: construyendo un protocolo de comunicación entre agentes

Publicado originalmente en Medium

La semana pasada vi un post en LinkedIn que realmente me hizo pensar: la IA hizo posible que volvamos a tener side projects para aprender y probar ideas.

En mi caso, esto se convirtió en mi “segundo turno” favorito — esas horas extra por la noche y los sábados por la mañana. Siempre he sido fan de esto.

El año pasado, junto con Marcell y Farinazzo, construimos PromptMetrics durante la competencia Lovable Shipped, y compartí cada paso del proceso. Fue una experiencia intensa de 0 a 1 que me mostró el poder de la ejecución rápida.

Este año decidí que mi foco sería un aprendizaje técnico más profundo. Quería ensuciarme las manos con implementación real, entender la arquitectura de servicios y finalmente dominar Python.

Así nació el protocolo ASAP — un protocolo de comunicación para agentes de IA (piensa en A2A, pero mejor 😜).

Lo que empezó como una curiosidad sobre cómo los agentes se hablan entre sí se convirtió en un proyecto open source completo que acaba de llegar a la versión 2.1.1.

En este artículo abro el “cerebro” del proyecto, el workflow de vibe coding que usé y cómo organicé la arquitectura para pasar de un boceto nerd a un marketplace funcional de agentes.

El problema: ¿por qué otro protocolo?

La idea surgió mientras conversaba con mi equipo en Pipefy, sobre las deficiencias de protocolos como A2A y las quejas comunes en los foros de devs.

El desafío no es solo la comunicación; es estandarización, confianza y descubrimiento.

Quería algo liviano y enfocado en el rendimiento. Quería ver cómo gRPC y FastAPI podían trabajar juntos para crear una capa de transporte que no se atragantara con la latencia.

Vibe coding: 85% IA y 15% humano

La gente suele preguntarme cómo mantengo este ritmo. La verdad es: el desarrollo fue 85% asistido por Cursor.

Pero no te engañes — el 15% de trabajo manual es donde ocurren las decisiones arquitectónicas y los trade-offs.

Mi setup actual es lo que llamo “orquestación de modelos”:

  • Planificación: Claude Opus 4.6 (en el MAX Mode de Cursor, con reasoning alto).
  • Desarrollo: Composer 1.5 y el modo auto de Cursor para el trabajo pesado.
  • Revisión técnica: no confío en un solo modelo. Paso el código por GPT-5.2 Codex, Gemini 3.1 Pro y Kimi K2.5 para encontrar bugs de lógica o cuellos de botella.

La IA no reemplaza al arquitecto; lo potencia. Yo me enfoco en el “qué” y el “por qué”, mientras la IA se encarga del “cómo”.

El “cerebro” del proyecto: context engineering en la práctica

Para no perderme en el caos de la IA generando miles de líneas de código, organicé mi repositorio para que la IA pudiera entender todo el contexto de producto y de ingeniería.

La carpeta .cursor/ es el centro de mando:

  • product-specs: donde guardo los ADRs (Architecture Decision Records) y los PRDs de cada versión.
  • dev-planning: donde los sprints se desglosan en tareas granulares para que la IA no “alucine” ni se desvíe durante el proceso.
  • skills, rules y commands: prompts especializados que enseñan a la IA a revisar seguridad o calidad de código específicamente para los estándares de ASAP.

Esta estructura me permite delegar la ejecución a la IA manteniendo la gobernanza total sobre el diseño del sistema.

De la base al marketplace: el roadmap

La evolución de ASAP se planificó en hitos claros para asegurar que cada release entregara valor real. Mientras lo construíamos, el alcance creció a medida que surgían nuevas ideas 🤯.

v1.0: base técnica

Foco en la estabilidad del protocolo. Definimos cómo se estructurarían los mensajes y cómo se persistiría el estado usando una estrategia híbrida entre SQLite e interfaces de almacenamiento flexibles.

v1.2: identidad verificada

Foco en seguridad. Implementé firmas Ed25519 para garantizar que un agente no pudiera hacerse pasar por otro. Usamos el estándar JCS para la canonicalización y una verificación estricta.

v2.0: lanzamiento del marketplace

Este hito transformó el protocolo en una capa económica. Creé una interfaz web donde cualquier dev puede registrar su agente mediante un flujo simple de IssueOps en GitHub. Nuestro Lite Registry corre en GitHub Pages para mantener los costos de infraestructura en cero.

v2.1: ecosistema e integraciones

Quienes construyen agentes ahora pueden encontrar e invocar agentes del marketplace en minutos, sin integraciones manuales. Me enfoqué en integraciones nativas con LangChain, OpenClaw, LlamaIndex, SmolAgents y en el soporte para MCPs (Model Context Protocol).

Las categorías y la revocación mantienen el catálogo confiable y fácil de navegar. Con el paquete en PyPI, experimentar está a un pip install de distancia.

Lo que viene: v2.2 ➔ v3.0

Actualmente estoy enfocado en cerrar la v2.2, que gira en torno a la escala y la facilidad de adopción:

  • Auto-registro: implementar GitHub IssueOps para que los nuevos agentes se listen sin PRs manuales.
  • Agent builder: una interfaz visual para que cualquier desarrollador configure las capacidades de su agente y exporte un manifiesto listo para el marketplace.

En la v3.0 llegamos al objetivo final: la capa de economía. Esto incluye el Verified Badge para agentes de alta reputación, un sistema de créditos para el cobro automatizado del uso y monitoreo de SLA en tiempo real.

El protocolo y el registry seguirán siendo abiertos. El valor está en la visibilidad, la confianza y la liquidez entre agentes.

Aprender es el único ROI garantizado

Al final del día, construir en público sigue siendo la mejor “universidad” a la que he asistido.

Aprendí a crear un protocolo de punta a punta, lidié con seguridad criptográfica, construí un design system desde cero y publiqué paquetes en PyPI que personas reales pueden usar.

Incluso si ASAP no se convierte en el estándar de la industria, mi ganancia es entender exactamente cómo funciona todo por debajo del capó y el razonamiento detrás de la construcción.

Si quieres criticar mi arquitectura, abrir un issue o darle una estrella al repo — la puerta está abierta. Es open source; ven a contribuir. Así empezaron muchas de las herramientas que usamos hoy.

Es hora de construir, LFG.

Volver a Artículos