Introducción
Cuando hablamos de agentes de inteligencia artificial, gran parte de la conversación se centra en los modelos, las herramientas y el prompting.
Sin embargo, al trabajar con varios agentes especializados, aparece un problema más profundo: la continuidad del conocimiento.
Un agente puede resolver una tarea compleja, documentar una decisión importante o descubrir un riesgo. Pero si ese conocimiento queda encerrado en una sesión, el sistema no ha aprendido realmente.
La siguiente tarea puede comenzar de nuevo desde cero.
El agente puede repetir el análisis, ignorar una decisión anterior o llegar a una conclusión incompatible con el trabajo ya realizado.
Para resolver este problema utilicé un patrón llamado Knowledge-Grounded Agents.
Su principio fundamental es sencillo:
Antes de realizar una tarea, cada perfil debe consultar el conocimiento curado que ya existe sobre el sistema.
El objetivo no es aumentar indefinidamente la memoria de cada agente.
El objetivo es construir una infraestructura donde varios perfiles independientes puedan trabajar sobre contexto compartido, sin mezclar su estado y sin perder trazabilidad.
Contexto no es memoria
Los modelos de lenguaje trabajan principalmente con contexto.
Ese contexto puede contener una conversación, instrucciones, documentos recuperados o resultados obtenidos mediante herramientas.
Pero el contexto es temporal.
Cuando la sesión termina, gran parte de la información deja de estar disponible.
La memoria persistente puede aliviar este problema, pero también tiene límites. No conviene guardar en ella cada descubrimiento, diagnóstico, decisión o detalle técnico.
Una memoria sin curación termina convirtiéndose en ruido.
Por eso esta arquitectura separa dos conceptos:
Memoria del perfil
Contiene información estable y acotada, como:
- identidad y comportamiento del agente;
- preferencias del usuario;
- restricciones permanentes;
- reglas generales de trabajo.
Conocimiento operativo
Contiene información durable sobre el entorno:
- decisiones anteriores;
- topologías;
- riesgos;
- hallazgos técnicos;
- heurísticas;
- contradicciones;
- procedimientos;
- relaciones entre componentes.
La memoria define cómo trabaja el agente.
El vault contiene lo que el sistema sabe.
El patrón Knowledge-Grounded Agents
El patrón establece que ningún perfil especializado debe comenzar una tarea sin consultar previamente el sistema de conocimiento.
El flujo general es el siguiente:
1. El perfil recibe una tarea.
2. Consulta el índice del Curator.
3. Identifica las notas relevantes.
4. Lee heurísticas, decisiones y contradicciones.
5. Aplica ese contexto a la tarea.
6. Utiliza herramientas cuando es necesario.
7. Registra cualquier nuevo conocimiento durable.
8. El Knowledge Curator clasifica, enlaza y publica el hallazgo.Puede representarse de forma más compacta así:
Usuario
↓
Perfil especializado
↓
Curator y vault
↓
Contexto relevante
↓
Análisis o ejecución
↓
Nuevo hallazgo
↓
Curator/inbox
↓
Clasificación y enlaces
↓
Conocimiento disponible para futuras tareasLa respuesta al usuario no es el final del proceso.
El proceso termina cuando el conocimiento generado queda incorporado al sistema.
Los componentes de la arquitectura
La arquitectura se apoya en cinco elementos principales:
- perfiles aislados de Hermes;
- memoria persistente acotada;
- MCP como capa de herramientas;
- Knowledge Curator como gobierno del conocimiento;
- Obsidian como interfaz visual del grafo.
1. Perfiles aislados de Hermes
Cada perfil de Hermes funciona como una instancia independiente.
Mantiene su propia:
- configuración;
- memoria;
- sesión;
- colección de skills;
- conjunto de herramientas;
- estado operativo.
Este aislamiento permite asignar funciones diferentes sin contaminar el contexto entre dominios.
En mi arquitectura existen, entre otros, los siguientes perfiles:
Default
Actúa como perfil generalista.
Captura notas rápidas, trabajo cotidiano y tareas que todavía no requieren una especialización clara.
Cuando detecta que un problema pertenece a otro dominio, deriva el contexto o deja material para que otro perfil pueda retomarlo.
Home Assistant Specialist
Se ocupa del análisis funcional y técnico de Home Assistant.
Trabaja con integraciones, automatizaciones, entidades, escenas, estados y configuración.
Si el problema depende de red, contenedores o servicios externos, colabora con el perfil de infraestructura.
Infrastructure Engineer
Razona sobre homelab, redes, Docker, servicios, copias de seguridad, proxies, migraciones y topología.
Consulta primero las decisiones y heurísticas existentes para evitar proponer cambios incompatibles con la arquitectura ya definida.
Security Auditor
Evalúa exposición, permisos, controles, hardening y superficie de ataque.
Cuando detecta información incompatible o un riesgo no resuelto, registra una contradicción para que pueda ser revisada de forma explícita.
Technical Researcher
Investiga fuentes técnicas, contrasta información y transforma los resultados en documentación utilizable.
Puede producir notas, análisis, borradores o artículos, pero no sustituye al Curator ni publica directamente conocimiento definitivo sin pasar por el flujo de clasificación.
Knowledge Curator
Es el perfil encargado del gobierno del conocimiento.
No analiza infraestructura como función principal, no ejecuta cambios y no inventa contenido. Responde a preguntas con conocimiento tácito.
Su responsabilidad es convertir información entrante en conocimiento durable, navegable y trazable.
2. Memoria persistente acotada
Hermes utiliza memoria persistente para mantener información entre sesiones.
En esta arquitectura, la memoria está deliberadamente limitada a elementos estables.
Dos piezas tienen un papel central:
- MEMORY.md, para hechos o instrucciones persistentes relacionados con el agente;
- USER.md, para preferencias y contexto estable del usuario.
La limitación es una ventaja.
Obliga a mantener la memoria enfocada y evita utilizarla como un almacén indiscriminado.
Los detalles operativos, las decisiones técnicas y los descubrimientos se almacenan en el vault, donde pueden clasificarse y relacionarse correctamente.
3. MCP como capa de herramientas
Los perfiles no trabajan únicamente con información textual.
Necesitan consultar sistemas, buscar documentos, acceder a servicios o ejecutar acciones controladas.
MCP proporciona una vía estructurada para conectar esas herramientas.
En este diseño existen dos grupos diferenciados.
Herramientas de consulta
Los perfiles especializados utilizan un MCP de conocimiento en modo de solo lectura.
Entre sus operaciones se encuentran:
- buscar notas por palabra clave;
- leer documentos concretos;
- listar el contenido disponible;
- consultar backlinks;
- consultar enlaces de salida;
- localizar enlaces rotos.
Esto permite que un perfil explore el grafo sin modificarlo accidentalmente.
Herramientas de mantenimiento
El Knowledge Curator utiliza un MCP con permisos de escritura.
Puede:
- crear o actualizar notas;
- mover notas entre carpetas;
- añadir o actualizar frontmatter;
- incorporar wikilinks;
- archivar contenido;
- solicitar la sincronización del vault.
La separación entre lectura y escritura aplica un principio importante:
Los perfiles producen conocimiento; el Curator gobierna su publicación.
4. Curator como capa de gobierno
El Curator no es únicamente una carpeta.
Es una capa de gobierno del conocimiento.
Su función es establecer qué información merece persistir, dónde debe almacenarse y cómo se relaciona con el resto del sistema.
La estructura principal se divide en cuatro espacios.
Inbox
Curator/inbox/ funciona como punto de entrada.
Los perfiles depositan allí cualquier hallazgo que pueda ser útil más adelante.
Una nota de entrada sigue una convención predecible:
<perfil>-<fecha>-<descripción>.mdPor ejemplo:
infra-20260718-arquitectura-homelab.mdTambién incluye metadatos básicos:
---
type: inbox-item
status: pending
source: infra
created: 2026-07-18
tags: [infra, homelab]
---Estas convenciones permiten identificar el origen, el estado y el tema de cada aportación.
Heuristics
heuristics/ almacena conocimiento validado, reutilizable y relativamente estable.
Una heurística puede describir:
- una topología;
- una buena práctica;
- una restricción técnica;
- un patrón de resolución;
- una lección aprendida.
No es una observación puntual. Es conocimiento que puede orientar tareas futuras.
Decisions
decisions/ registra decisiones que afectan a la arquitectura, la organización o el método de trabajo.
El objetivo es evitar que los perfiles propongan repetidamente alternativas que ya fueron evaluadas o que ignoren compromisos anteriores.
Contradictions
contradictions/ contiene incompatibilidades, ambigüedades o conflictos.
Por ejemplo:
- dos notas describen estados diferentes del mismo servicio;
- una decisión contradice la configuración real;
- dos perfiles llegan a conclusiones incompatibles;
- falta información suficiente para resolver un riesgo.
Las contradicciones no se ocultan ni se resuelven automáticamente.
Se hacen visibles para facilitar la mediación humana.
5. Obsidian como interfaz del grafo
Obsidian proporciona la interfaz visual y navegable de la arquitectura.
El vault no está diseñado como una jerarquía rígida de carpetas.
Se estructura mediante:
- un MOC raíz;
- MOCs por dominio;
- notas atómicas;
- wikilinks;
- backlinks;
- enlaces de entrada y salida;
- Graph View.
El MOC raíz funciona como punto de acceso al conjunto completo.
Desde ahí se puede navegar hacia MOCs técnicos, documentación de arquitectura, infraestructura, inteligencia artificial, seguridad o cualquier otro dominio.
Las notas atómicas mantienen el conocimiento granular.
Cada nota intenta representar una idea, hallazgo, decisión o concepto identificable.
Los backlinks permiten descubrir qué otras notas dependen de una idea.
Los enlaces de salida muestran el contexto en el que esa idea se apoya.
El grafo hace visibles las relaciones entre dominios que una estructura basada únicamente en carpetas podría ocultar.
Por eso Obsidian no funciona simplemente como editor de Markdown.
Funciona como una interfaz para inspeccionar la memoria operativa del sistema.
El checklist antes de cada tarea
El patrón puede convertirse en una rutina verificable.
Antes de comenzar, cada perfil debería comprobar:
- ¿He consultado el índice del Curator?
- ¿He leído las notas relevantes?
- ¿Existen decisiones previas que afecten a la tarea?
- ¿Hay heurísticas que debo respetar?
- ¿Existen contradicciones pendientes?
- ¿Estoy a punto de repetir un análisis que ya se realizó?
Después de completar la tarea, debería revisar:
- ¿He descubierto algo reusable?
- ¿Ha cambiado el estado del sistema?
- ¿Existe un nuevo riesgo?
- ¿Debe registrarse una decisión?
- ¿Hay información contradictoria?
- ¿Debo depositar una nota en el inbox?
Este checklist convierte una intención arquitectónica en un comportamiento operativo.
Ejemplo práctico
Supongamos que el Infrastructure Engineer recibe una tarea para modificar la red de un servicio del homelab.
Sin knowledge grounding, el perfil podría:
- inspeccionar la situación actual;
- proponer una arquitectura razonable;
- aplicar criterios generales;
- ignorar decisiones tomadas meses atrás.
Con el patrón, el flujo cambia:
- consulta el índice del Curator;
- localiza la nota de topología;
- lee decisiones anteriores sobre segmentación;
- comprueba si existen riesgos abiertos;
- analiza la modificación dentro de esas restricciones;
- consulta al Security Auditor si aparecen implicaciones de seguridad;
- registra el resultado en el inbox;
- el Curator actualiza la heurística o crea una nueva decisión.
La diferencia no está únicamente en la calidad de la respuesta.
Está en que el trabajo se acumula.
La siguiente tarea parte de un estado de conocimiento mejor que la anterior.
Sin knowledge grounding y con knowledge grounding
Sin knowledge grounding
- El perfil empieza desde cero
- Las decisiones pueden variar entre sesiones
- Se repiten investigaciones
- El conocimiento queda en conversaciones
- Los riesgos se olvidan
- La memoria depende de cada agente
- La información se acumula sin gobierno
Con knowledge grounding
- El perfil parte de contexto
- Las decisiones se mantienen coherentes
- Se reutilizan hallazgos previos
- El conocimiento se integra en el vault
- Los riesgos quedan enlazados y visibles
- Existe una memoria operativa compartida
- El Curator clasifica y mantiene el sistema
La separación entre estado y conocimiento
Uno de los elementos más importantes de esta arquitectura es la separación entre estado y conocimiento.
Los perfiles no comparten directamente sus sesiones, memorias o configuraciones.
Siguen siendo instancias aisladas.
Lo que comparten es una representación curada del conocimiento relevante.
Esta separación ofrece dos ventajas.
Evita la contaminación de contexto
Un auditor de seguridad no necesita incorporar todo el razonamiento interno de un especialista en Home Assistant.
Necesita conocer los hechos, decisiones y riesgos relevantes.
Mejora la trazabilidad
Una conclusión importante no queda escondida dentro de la memoria opaca de un agente.
Se convierte en una nota legible, enlazada y revisable.
El sistema permite saber:
- quién produjo el hallazgo;
- cuándo fue creado;
- qué fuentes utilizó;
- con qué notas está relacionado;
- si fue validado;
- si existe una contradicción pendiente.
La función humana no desaparece
Este diseño no intenta eliminar la supervisión humana. La hace más precisa.
El Knowledge Curator puede clasificar, sanitizar y enlazar información, pero no debería inventar hechos ni resolver silenciosamente conflictos importantes.
Las contradicciones y decisiones sensibles permanecen visibles.
La persona mantiene la autoridad sobre:
- cambios estructurales;
- aceptación de riesgos;
- resolución de contradicciones;
- modificación de contenido de fondo;
- operaciones con impacto real.
La automatización organiza el conocimiento. La gobernanza humana mantiene la responsabilidad.
De una colección de notas a una memoria operativa
Una carpeta con archivos Markdown puede almacenar mucha información y, aun así, ser difícil de utilizar. El valor no aparece por el simple hecho de guardar notas.
Aparece cuando existe un sistema que decide:
- qué información entra;
- quién puede modificarla;
- cómo se clasifica;
- cómo se relaciona;
- cuándo debe revisarse;
- cómo vuelve a utilizarse.
Eso es lo que convierte el vault en una memoria operativa. Cada interacción puede mejorar el conocimiento disponible para la siguiente. Cada especialista puede aprovechar el trabajo de los demás sin heredar su estado completo. Cada decisión puede mantenerse visible y trazable.
Una tesis sobre el futuro de los agentes
Durante los últimos años hemos dedicado mucha atención al diseño de prompts.
Los prompts seguirán siendo importantes.
Pero no resuelven por sí solos el aprendizaje acumulativo, la colaboración entre perfiles o la gobernanza del conocimiento.
La siguiente evolución probablemente dependerá más de la arquitectura que rodea al modelo:
- sistemas de recuperación;
- memoria estructurada;
- agentes especializados;
- herramientas conectadas;
- flujos de curación;
- trazabilidad;
- validación humana.
Un modelo avanzado puede producir una respuesta excelente.
Una arquitectura de conocimiento permite que esa respuesta no se pierda.
Conclusión
Esta arquitectura puede resumirse en:
Obsidian es la interfaz, Curator es la capa de gobierno del conocimiento y Hermes utiliza perfiles, memoria persistente y MCP para convertir el vault en contexto operativo.
Los perfiles permanecen aislados.
El conocimiento se comparte.
Las herramientas están controladas.
Las decisiones son trazables.
Los hallazgos se acumulan.
El sistema no intenta conseguir que cada agente recuerde todo.
Intenta conseguir que todos sepan dónde consultar, cómo contribuir y qué conocimiento merece permanecer.
No se trata únicamente de construir agentes con memoria.
Se trata de construir sistemas capaces de aprender de su propio trabajo.
Conversación
Comparte una idea, pregunta o mejora sobre esta publicación.