ADR — Captura de Memory Intent y ampliación de memoria corporativa continua¶
Fecha: 2026-09-06
Estado: Accepted (con 3 condiciones obligatorias incorporadas — ver §6bis)
GO: Carlos, 2026-09-06
Ámbito: wetopi-memory Hermes plugin
Backend: Hindsight 0.9.2
Relacionado con: arquitectura mixta de memoria Wetopi
1. Contexto¶
El sistema actual utiliza dos caminos de memoria diferenciados:
- Provider nativo Hindsight de Hermes
- single-bank;
- bank personal
user-u_carlos; - auto-recall;
- auto-retain del turno completo;
-
tools explícitas
hindsight_retain,hindsight_recall,hindsight_reflect. -
Plugin general
wetopi-memory - corporate-only;
- banks
wetopi-platformywetopi-business; - routing determinista;
- ScopeACL;
- EvidenceBuffer;
- batch-retain;
- política conservadora de retención;
- recall mediante hooks y prefetch.
La separación actual establece:
El provider nativo es dueño del bank personal, mientras que wetopi-memory tiene ACL corporate-only.
Actualmente el pipeline corporate evalúa señales como durabilidad, seguridad, verificación y scope antes de hacer retain, con un máximo de un batch por scope y turno.
Este enfoque ha demostrado ser seguro, pero excesivamente conservador para el objetivo deseado de memoria organizacional.
2. Problema¶
La memoria corporativa no debe limitarse únicamente a:
- root causes importantes;
- decisiones arquitectónicas;
- procedimientos consolidados;
- aprendizajes excepcionales.
Wetopi necesita además disponer de una memoria operativa continua que represente:
- el estado actual de la plataforma;
- cambios realizados;
- servicios creados o retirados;
- hosts apagados o puestos en mantenimiento;
- despliegues;
- operaciones realizadas;
- procedimientos utilizados;
- decisiones;
- descubrimientos;
- pendientes;
- resultados de investigaciones.
Ejemplos:
Estas informaciones pueden no ser permanentemente durables, pero son muy relevantes para entender:
El incidente anterior con BookStack mostró precisamente que información útil podía terminar únicamente en la memoria personal mientras wetopi-platform no capturaba el aprendizaje correspondiente.
3. Hallazgo adicional: intención explícita del modelo¶
El provider nativo Hindsight expone:
y estas llamadas explícitas del modelo son distintas del auto-retain automático.
En el sistema actual:
corresponde al mecanismo automático del provider.
Mientras:
indica que el propio modelo decidió explícitamente que cierta información merece ser retenida.
Esta llamada constituye una señal semántica de alta calidad que wetopi-memory actualmente no utiliza de forma especial.
4. Decisión¶
Se ampliará wetopi-memory con dos cambios principales:
4.1 Captura amplia, almacenamiento compacto¶
La filosofía de corporate memory pasa de:
a:
Una interacción operativa relevante debe producir normalmente uno o varios candidatos de memoria corporativa, aunque no contenga un root cause o una decisión arquitectónica.
No se almacenará la conversación completa.
El plugin transformará la actividad del turno en información operacional compacta.
4.2 Capturar hindsight_retain como Memory Intent¶
Cuando el modelo llame explícitamente a:
wetopi-memory deberá tratarlo como una señal:
de alta prioridad.
La señal NO implica copiar automáticamente el contenido al bank corporativo.
Debe pasar igualmente por:
Flujo:
LLM
│
├── hindsight_retain
│ │
│ ├── provider nativo
│ │ └── user-u_carlos
│ │
│ └── wetopi-memory observa la intención
│ │
│ ▼
│ MemoryIntent signal
│ │
│ ▼
│ corporate relevance?
│ │ │
│ NO YES
│ │
│ ▼
│ scope routing
│ ┌──────┴──────┐
│ ▼ ▼
│ platform business
5. Nuevo componente: MemoryIntent¶
Añadir al modelo interno:
Ejemplo:
{
"type": "explicit_memory_intent",
"source": "native_hindsight_retain",
"strength": 1.0,
"content": "...",
"tool_call_id": "...",
"timestamp": "...",
"session_id": "..."
}
El evento puede formar parte del TurnEvidenceBuffer existente o almacenarse en un sub-buffer específico.
Recomendación inicial:
6. Hooks¶
pre_tool_call¶
Detectar intención antes de ejecutar la tool, si Hermes expone de forma fiable:
- tool name;
- arguments;
- session context.
Si la tool es:
registrar:
con el contenido solicitado por el modelo.
post_tool_call¶
Confirmar que la operación explícita se ejecutó.
No realizar corporate retain directamente.
Registrar:
en el buffer.
post_llm_call¶
Evaluar conjuntamente:
y decidir si se genera memoria corporativa.
7. Protección contra loops¶
Debe impedirse que las operaciones generadas por wetopi-memory creen nuevos MemoryIntent.
Regla obligatoria:
El detector solo debe considerar explícitamente las tools del provider nativo:
y no:
del propio plugin.
Idealmente identificar además el origin/call namespace.
8. Nuevo modelo de Corporate Learning¶
La memoria corporativa se clasificará inicialmente en:
STATE¶
Representa estado operativo conocido.
Ejemplos:
Puede ser temporal.
No debe requerir durabilidad permanente.
EVENT¶
Representa algo que ocurrió.
Ejemplos:
Debe preservar timestamp/contexto temporal.
DECISION¶
Representa una decisión explícita.
Ejemplos:
Debe exigir señal explícita o alta confianza.
PROCEDURE¶
Representa una forma comprobada de operar.
Ejemplo:
To deploy BookStack:
- deploy using Argo CD
- create HTTPRoute
- no additional DNS record is required because wildcard DNS already covers it
Debe exigir verificación suficiente.
LEARNING¶
Representa:
- root causes;
- gotchas;
- restricciones;
- fixes;
- relaciones descubiertas.
Ejemplo:
Debe exigir evidencia/verificación.
9. Cambio de policy¶
Eliminar como condición universal:
La condición principal pasa a ser:
La durabilidad se convierte en propiedad del candidato.
Ejemplo:
memory_policy:
state:
retain: true
temporal: true
verification: medium
event:
retain: true
temporal: true
verification: medium
decision:
retain: true
verification: explicit_or_high
procedure:
retain: true
verification: required
learning:
retain: true
verification: required
speculation:
retain: false
chatter:
retain: false
raw_output:
retain: false
10. Señales de retención¶
Crear un sistema determinista de señales.
Ejemplo conceptual:
SIGNAL STRENGTH
explicit hindsight_retain VERY HIGH
explicit user "remember this" VERY HIGH
successful infrastructure mutation VERY HIGH
successful deployment HIGH
explicit decision HIGH
verified root cause HIGH
service state change HIGH
operational procedure executed MEDIUM/HIGH
ordinary operational discussion MEDIUM
speculative discussion LOW
chatter ZERO
secret detected HARD REJECT
No es obligatorio implementar inicialmente un score numérico exacto.
Puede utilizarse un sistema de reglas/flags.
11. Operational Activity Detector¶
Añadir detección amplia de actividad corporativa.
Ejemplos de señales:
Mutación¶
created
deployed
installed
changed
migrated
updated
deleted
powered off
powered on
restarted
configured
moved
Estado¶
Decisión¶
Descubrimiento¶
El router debe soportar equivalentes ES/EN.
12. Batch retain¶
Se mantiene la política actual:
El turno puede producir varios LearningRecord, pero deben agruparse antes de llamar a Hindsight.
Ejemplo:
Esto preserva el control de backpressure ya implementado actualmente mediante semaphore, cola limitada y batch por scope.
13. Uso del LLM¶
No añadir inicialmente un LLM classifier dentro de wetopi-memory.
El plugin realizará:
mediante reglas.
Hindsight seguirá realizando:
server-side, como ya ocurre en la arquitectura actual.
14. Input enviado a Hindsight¶
No enviar toda la conversación indiscriminadamente.
Crear un batch compacto como:
Wetopi platform operational activity.
Timestamp:
2026-09-06T...
User/agent activity:
- pve04 was intentionally powered off for maintenance.
Evidence:
- workloads had already been evacuated.
- shutdown completed successfully.
Current outcome:
- pve04 is offline.
- offline state is intentional and temporary.
Hindsight será responsable de extraer los facts individuales.
15. retain_mission revisado para wetopi-platform¶
Actualizar el bank mission a:
Extract concise operational knowledge about the Wetopi platform.
Retain relevant CURRENT STATE:
- status of hosts, services, clusters and infrastructure
- online/offline/degraded/maintenance states
- deployed, removed or pending services
- important configuration currently in effect
Retain EVENTS:
- deployments
- shutdowns and startups
- migrations
- upgrades
- service creation or removal
- infrastructure changes
- incidents and recoveries
Retain DECISIONS:
- architecture decisions
- operational decisions
- selected or rejected technologies
- changes in platform policy
Retain PROCEDURES:
- verified ways of operating, deploying, recovering or maintaining systems
- repeatable operational sequences
Retain LEARNINGS:
- root causes
- discovered constraints
- validated fixes
- gotchas
- important dependencies and service relationships
Preserve:
- entity names
- timestamps and temporal context
- current outcome
- reason when known
- whether the state is temporary, pending or final
Supersede rule:
- when a resource changes state, the new observation SUPERSEDES
- the old one for the same resource (pve04 online kills pve04 offline)
Ignore:
- greetings
- conversational filler
- raw command output
- failed hypotheses
- speculation without operational consequence
- duplicate restatements
- credentials and secrets
16. wetopi-business¶
Aplicar el mismo concepto con otro dominio.
Tipos:
Ejemplos:
17. Estado versus evento¶
Cuando una acción modifica estado, conservar conceptualmente ambas dimensiones.
Ejemplo:
Debe permitir que Hindsight extraiga:
Posteriormente:
produce:
La historia se conserva mientras el estado actual puede consolidarse/supersederse.
18. Tags¶
Añadir tags informativos, nunca como mecanismo de seguridad.
Ejemplos:
y opcionalmente:
Más identificador:
ACL y aislamiento continúan dependiendo de:
no de tags.
19. Memory Intent de otras tools¶
En V1 de este ADR:
será la señal explícita principal.
Opcionalmente registrar telemetría de:
pero NO utilizarlos inicialmente como triggers de retain.
Interpretación futura:
hindsight_retain
→ persistence intent
hindsight_recall
→ past context considered relevant
hindsight_reflect
→ memory synthesis required
20. Métricas nuevas¶
Añadir:
wetopi_memory_intent_total
wetopi_memory_intent_promoted_total
wetopi_memory_intent_rejected_total
wetopi_memory_learning_candidate_total
wetopi_memory_learning_retained_total
wetopi_memory_learning_type_total
wetopi_memory_operational_activity_total
Labels permitidos:
Nunca incluir contenido sensible en labels.
21. Métricas de eficacia¶
Durante el experimento medir:
turns_total
corporate_relevant_turns
turns_with_learning
turns_without_learning
native_hindsight_retain_calls
native_intents_promoted
native_intents_personal_only
platform_retains
business_retains
policy_rejects
Objetivo inicial:
la mayoría de interacciones operativas relevantes
deben generar al menos un LearningRecord corporativo
sin aumentar significativamente:
22. Riesgos¶
Sobre-retención¶
El cambio amplía considerablemente la superficie de captura.
Mitigación:
Estados obsoletos¶
Una memoria como:
puede dejar de ser correcta rápidamente.
Mitigación:
- timestamp obligatorio;
- clasificar como temporal;
- conservar eventos;
- permitir consolidación/supersession;
- recall preferente de observations.
Promoción incorrecta personal → corporate¶
Un hindsight_retain explícito puede contener información exclusivamente personal.
Mitigación:
Siempre ejecutar corporate relevance + scope policy.
Loops¶
Mitigación:
no considerar como MemoryIntent operaciones originadas por wetopi-memory.
Backpressure¶
Se mantiene:
23. No decisiones¶
Este ADR NO decide todavía:
- utilizar router semántico LLM;
- construir promoter histórico
personal → corporate; - sustituir el provider nativo;
- modificar la ACL corporate-only;
- crear nuevos banks;
- eliminar la memoria personal abundante.
La arquitectura mixta se conserva.
24. Fases de implementación¶
M1 — Memory Intent bridge¶
Implementar:
No cambiar aún la policy global.
M2 — Corporate Activity Detector¶
Añadir reglas para:
y producir:
M3 — Revised PolicyEngine¶
Cambiar:
como requisito global por:
manteniendo verificación específica según tipo.
M4 — Hindsight mission update¶
Actualizar declarativamente:
mediante el bootstrap GitOps existente.
M5 — Observación¶
Medir comportamiento real antes de introducir:
25. Acceptance Criteria¶
El cambio se considera correcto cuando se verifican al menos estos casos.
Caso 1 — estado operativo¶
Entrada:
Resultado esperado:
Caso 2 — nuevo servicio¶
Entrada:
Resultado esperado:
en wetopi-platform.
Caso 3 — procedimiento¶
Entrada:
Resultado esperado:
información compacta de procedimiento/configuración en wetopi-platform.
Caso 4 — hindsight_retain técnico¶
El modelo llama:
con una conclusión técnica de plataforma.
Resultado esperado:
personal retain:
YES
MemoryIntent:
YES
corporate candidate:
YES
wetopi-platform:
YES if policy passes
Caso 5 — hindsight_retain personal¶
El modelo llama:
Resultado:
Caso 6 — secreto¶
Se detecta:
Resultado:
aunque exista hindsight_retain.
Caso 7 — hipótesis falsa¶
Una hipótesis de debugging posteriormente descartada.
Resultado:
Puede existir evidencia temporal local durante el turno, pero no debe convertirse en memoria corporativa.
26. Resultado esperado¶
Después del cambio:
mientras:
La memoria corporativa debe evolucionar desde una colección de aprendizajes excepcionales hacia una representación continua de:
de Wetopi.
El resultado esperado es que wetopi-platform y wetopi-business funcionen progresivamente como una memoria viva de:
qué tenemos
qué estado tiene
qué hicimos
cómo lo hicimos
por qué lo hicimos
qué aprendimos
qué cambió
sin almacenar el ruido completo de las conversaciones personales.