Presento el diseño de un sistema que mantiene un grafo de conocimiento estructurado de inteligencia de producto — features, decisiones arquitectónicas, convenciones, transcripciones de reuniones, feedback de usuarios y métricas — y lo expone a agentes de código basados en LLM a través de un protocolo de herramientas, habilitando pipelines de desarrollo autónomo multi-sesión que construyen, revisan y despliegan código con contexto completo de producto.
Marzo 2026
Los agentes de código LLM actuales (Claude Code, Cursor, Copilot) operan con una única fuente de verdad: el codebase. No tienen acceso al contexto a nivel de producto del que dependen los desarrolladores humanos para tomar decisiones correctas.
El agente ve el código pero no el razonamiento detrás de él. El conocimiento de producto permanece fragmentado en herramientas desconectadas.
Diseñé un sistema que unifica inteligencia de producto, gestión de tareas y orquestación de agentes en una única plataforma local. Cada capa alimenta a las demás a través de un grafo de conocimiento compartido.
Las tres capas comparten el mismo modelo de datos. El servidor MCP expone la inteligencia a los agentes de código via el protocolo estándar de herramientas.
Modelo el conocimiento de producto como nodos tipados con relaciones explícitas. Una tarea nunca es huérfana — se conecta al feature que afecta, la decisión que la condiciona, la reunión que la creó y el feedback que la justifica.
Compongo el grafo de conocimiento con siete categorías de nodos tipados. Cada nodo lleva metadatos estructurados y aristas explícitas hacia nodos relacionados.
| Tipo de nodo | Descripción | Ejemplo |
|---|---|---|
| Feature | Una capacidad del producto con arquitectura, estado y métricas | Flujo de checkout — Stripe, React SPA, 34% conversión |
| Decisión | Una elección arquitectónica o de producto registrada con razonamiento | "Usar collaborative filtering" — 14 ene, elegido sobre content-based |
| Convención | Un estándar del equipo que el agente debe respetar | "Todas las APIs retornan {data, error, meta}" — 47 endpoints siguen esto |
| Reunión | Extracto estructurado: decisiones, tareas, temas discutidos | Sprint planning Mar 25 — generó 3 tareas, 1 discusión de arquitectura |
| Feedback | Señales de usuarios agrupadas y mapeadas a features | 12 quejas sobre velocidad de checkout — vinculado al feature checkout |
| Métrica | KPI rastreado vinculado a features y tareas | Conversión mobile: 34%, objetivo 50%, tendencia bajista |
| Bug | Defecto mapeado a feature con impacto en usuarios | Imágenes del carrusel sin comprimir — afecta checkout, decisión CDN |
Implemento un orquestador que gestiona sesiones aisladas de Claude Code como un pipeline secuencial. Cada sesión recibe un prompt específico según su rol y el segmento relevante de contexto de producto. Las sesiones son creadas, monitoreadas y terminadas por el proceso daemon.
Expongo la inteligencia de producto a través del Model Context Protocol (MCP), haciéndola accesible a cualquier agente LLM compatible. El agente puede leer contexto antes de construir y escribir resultados de vuelta al completar.
El ciclo lectura-escritura crea un bucle auto-reforzante: el agente construye con contexto, luego enriquece el grafo con lo que aprendió. Esto es lo que hace que el sistema mejore solo.
El daemon corre en un servidor dedicado, VPS, o container — no en la laptop de nadie. Los pipelines se ejecutan 24/7. Cuando el sistema necesita una decisión humana, notifica al developer por el canal configurado.
Configuro el canal una vez: Slack, Discord, WhatsApp (Twilio), email, o SMS. Toda interacción humano-sistema pasa por ahí. El developer responde "aprobado" desde el celular y el pipeline continúa.
El sistema envía notificaciones ricas: qué tarea se afecta, qué conflicto detectó, la decisión arquitectónica relevante, y botones de acción. No necesito abrir una terminal, un dashboard, ni una laptop.
Implemento agentes de análisis que corren en schedule sobre el mismo orquestador. Cruzan el codebase con el grafo de producto para detectar lo que ningún humano está mirando.
Código que viola convenciones registradas en el grafo. Dependencias con CVEs conocidos. Features eliminadas con código huérfano. Áreas críticas sin cobertura de tests.
"Decidimos usar lazy loading en enero, pero el carrusel de la página de producto todavía carga todo sincrónico." Cruza decisiones registradas con implementación real.
"5 usuarios pidieron filtros en la búsqueda esta semana. La data ya está indexada." Agrupa feedback, detecta quick wins, y los propone como tareas priorizadas.
Cada hallazgo genera un ítem de backlog con evidencia completa (feature afectado, decisión relevante, impacto estimado) y notifica al equipo según la severidad configurada.
Un tag de versión en mi sistema captura el estado completo: código, features, decisiones, convenciones, métricas, y backlog. Un rollback restaura todo ese contexto, no solo un commit.
Comparo dos tags y veo no solo cambios de código, sino qué features cambiaron, qué decisiones se tomaron, qué métricas se movieron, y qué feedback se abordó.
Después de un rollback, los agentes construyen con la inteligencia de la versión restaurada, no con el estado roto. El sistema sabe cómo era el producto cuando funcionaba.
No encontré ningún sistema que combine las cinco capas. Cada herramienta del mercado aborda una sola dimensión.
| Sistema | Inteligencia | Gestión | Orquestación | Proactividad | Versionado |
|---|---|---|---|---|---|
| Jira / Linear | No | Tickets planos | No | No | No |
| Notion | Docs sueltos | No | No | No | No |
| Devin | Solo código | No | 1 sesión | No | No |
| LangSmith | Post-deploy | No | No | No | No |
| Mi sistema | Grafo | Grafo | Multi-sesión | Continua | Producto |
El diferenciador no es ninguna capa individual sino la integración entre las cinco. La inteligencia alimenta la gestión, ambas alimentan al orquestador, la proactividad enriquece el grafo continuamente, y el versionado captura el estado completo en cada release.