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

Hace poco 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 — esas horas extra por la noche y los domingos por la mañana.

Siempre he sido fan de esto.

El año pasado, junto con amigos, construimos PromptMetrics durante la competencia Lovable Shipped, llegando al top 15 global en una de las fases (y terminando 25º en total, entre 5.800 equipos).

Fue una experiencia intensa de 0 a 1 que me mostró el poder de la ejecución rápida con IA.

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 meterme en un lenguaje nuevo, y acabé en 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.

Estamos en v2.5.4, lo bastante listo para producción como para que la pregunta interesante pasara de “¿los agentes pueden hablar?” a “¿un desconocido puede instalar, conectar y entregar en una tarde?”.

En este artículo abro el “cerebro” del proyecto, el harness 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.

Mi workflow: 80% IA y 20% humano

El desarrollo fue ~80% asistido por Cursor Cloud Agents, pero no te engañes: el 20% de trabajo manual es donde ocurren las decisiones de arquitectura y los trade-offs.

Mi setup actual:

• Planificación: Fable o GPT 5.6 o Astra (en MAX Mode, con reasoning alto).
• Desarrollo: Composer 2.5 y el Grok 4.x de Cursor para el trabajo pesado.
• Revisión técnica: no confío en un solo modelo. Paso el código por otros modelos para encontrar bugs de lógica o cuellos de botella.

Me concentro en el “qué” y el “por qué”, mientras el modelo se encarga del “cómo”.

El cambio mayor no es solo qué modelo elijo una noche cualquiera.

Es que el repositorio ahora obliga a gobernanza antes de generar: AGENTS.md como mapa de contexto, reglas siempre activas para seguridad y commits, skills de revisión de seguridad y de calidad de código, y un gate de CI antes del push que de verdad corro en local.

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

Para que la IA no genere miles de líneas ingeniosas en la dirección equivocada, dejé de tratar el repositorio como “código + vibes” y empecé a tratarlo como un sistema operativo de producto.

El centro de mando sigue orientado a agentes, pero el mapa cambió:

• product/prd y product/decision-records: PRDs y ADRs de cada tren de release (la fuente de verdad del alcance).
• engineering/tasks: sprints partidos en paquetes granulares para que el agente no se pierda a mitad de camino.
• AGENTS.md + cursor/README.md: un mapa de contexto y un orden de precedencia (reglas del usuario → reglas siempre activas → skills → docs).
• rules y skills: restricciones y workflows profundos — revisión de seguridad, código limpio, pruebas de rate limit, estándares de frontend.

Sigo delegando la ejecución. Solo dejé de delegar el juicio.

Si la IA no puede señalar un PRD, un ADR o un paquete de tareas, no inventa una feature.

El árbol sigue pareciendo de nerd. Ese es el punto. El context engineering dejó de ser una diapositiva y pasó a ser cómo el proyecto entrega.

De la base al marketplace: el roadmap

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

v1.0: Base técnica

Estabilidad del protocolo, estructura de los mensajes y persistencia híbrida (SQLite + interfaces flexibles de storage).

v1.2: Identidad verificada

Firmas Ed25519 + canonicalización JCS para que un agente no pueda hacerse pasar por otro.

v2.0: Lanzamiento del marketplace

Esto convirtió el protocolo en una capa económica. Una interfaz web donde cualquier dev registra su agente con un flujo simple de IssueOps en GitHub.

Nuestro Lite Registry corre en GitHub Pages para mantener el costo de infraestructura en cero mientras validamos la idea.

v2.1: Ecosistema e integraciones

Adaptadores nativos para LangChain, OpenClaw, LlamaIndex, SmolAgents y soporte para MCPs. Categorías, revocación y el paquete en PyPI hicieron triviales el descubrimiento y la instalación.

v2.5.4: dónde estamos ahora

El marketplace está en línea en asap-protocol.com.

Añadimos el MCP Auth Bridge (herramientas nativas con alcance vía Agent JWTs), un SDK de TypeScript, conectores OpenAPI, filtros de descubrimiento para edge-AI y un harness de compliance.

Lo que viene

v2.5.5

La especificación formal, la introspección y la interoperabilidad entre protocolos.

Agent builder

Una interfaz visual para que cualquier desarrollador configure las capacidades de su agente y exporte un manifiesto listo para el marketplace.

Parte de los datos es real y parte está mockeada. Sigo integrando este recorrido con el marketplace.

v3.0

La capa económica: Verified Badge, un sistema de créditos para el cobro por uso y monitoreo de SLA en tiempo real.

El protocolo y el registry seguirán 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, lidie con seguridad criptográfica, construí un design system desde cero y publiqué paquetes en PyPI que personas reales pueden usar.

Aunque ASAP no se convierta en el estándar de la industria, mi ganancia es entender exactamente cómo funciona todo por dentro y la lógica de la construcción.

Si quieres criticar mi arquitectura, abrir una issue o dar star 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.