Hay algo que me incomoda en gran parte del trabajo con code agents: cada herramienta inventa su propia forma de entender un proyecto. Una lee un archivo de instrucciones en la raíz, otra espera convenciones implícitas, otra simplemente carga todo al contexto y cruza los dedos. Cada caso parece un detalle. Cuando el proyecto crece — más módulos, decisiones antiguas, direcciones que cambiaron — ese detalle empieza a definir la calidad de todo lo que el agente produce.

De ahí nació Prumo. No como “otra CLI más”, sino como una pregunta: ¿y si el repositorio fuera la fuente durable de verdad, legible tanto por humanos como por agentes, sin depender de la herramienta del momento?

Lo que intentaba resolver

Quiero que cualquier agente pueda entrar a un proyecto y responder rápido: cuál es el objetivo actual, qué decisiones no se pueden romper, qué ya fue validado y con qué evidencias. Hoy ese contexto vive disperso — un poco en la cabeza de las personas, un poco en docs sueltos, un poco en historiales de chat que ya nadie encuentra.

Dónde empieza a fallar la solución obvia

El camino más obvio sería escribir un AGENTS.md cada vez más grande. Funciona hasta cierto punto, pero tiene un techo bajo: cuantas más cosas entran al archivo, menos sabe el agente qué importa para esa tarea específica. Podemos tener carpetas enteras de ADRs, specs y roadmaps y seguir con el mismo problema, porque nada dice qué documento tiene autoridad sobre qué parte.

La idea, entonces, no es más documentación. Es documentación con estructura: metas, decisiones, contratos, tareas y evidencias relacionados entre sí, versionados en Git, validados por schema.

Lo que propone Prumo

En términos simples: estado canónico del proyecto en Markdown, JSON y JSON Schema dentro del propio repo — y todo lo demás (cachés, índices, adapters por herramienta) como derivado. Las metas tienen ciclo de vida con integridad verificable, los planes se validan como DAGs, y los adapters traducen ese estado a cada harness: Claude Code, Codex, OpenCode, Gemini y los que vengan.

Lo que me lleva a preferir este diseño es la reversibilidad. Si mañana aparece un agente nuevo, nadie reescribe el proyecto: se escribe un adapter. El contenido sigue perteneciendo a los lugares correctos; el protocolo solo mantiene las relaciones.

Lo que aún me preocupa

Dos huecos honestos. Primero, un protocolo sin adopción es solo una especificación bonita — Prumo debe probar valor en el uso diario, no en el diagrama. Segundo, existe el riesgo de que el sistema se convierta en una plataforma que intenta controlar demasiados detalles. No quiero eso: su función es mantener relaciones, autoridad y procedencia, no dictar cómo trabaja cada herramienta.

Estado actual

Hoy Prumo es un binario único en Go, sin dependencias externas de runtime, más pruebas de conformidad que comparan el comportamiento con baselines. Pondría esta parte en 7/10: la base está bien, pero aún faltan validación en proyectos grandes reales y más adapters en el día a día.

El próximo paso que puede confirmar o tumbar estas decisiones es usar el protocolo en proyectos de verdad durante algunas semanas y medir: ¿menos retrabajo de los agentes? ¿menos decisiones rotas? Si sí, tenemos infraestructura. Si no, tenemos lección. Ambas valen. Código y docs en el repositorio.