Wetopi AI-First Kubernetes Rebuild¶
Memoria técnica y ejecutiva del proyecto¶
Fecha: 28 de agosto de 2026
Estado: Diseño inicial consolidado
Ámbito: Reconstrucción de Wetopi sobre Kubernetes con una arquitectura AI-first y una flota interna de sistemas agénticos.
Índice¶
- Resumen ejecutivo
- Objetivo del proyecto
- Principios de diseño
- Arquitectura general
- Actores del sistema
- Servicios agénticos prioritarios
- Work Coordination Plane: Kanban, tickets y coordinación
- Memory Plane: memoria compartida de Wetopi
- Memoria local de Hermes + memoria factual global
- Integración de Hermes con la memoria de Wetopi
- Secrets Plane: Vault central con OpenBao
- Documentation Plane: Markdown + Git + MkDocs Material
- Estrategia de repositorios
- wetopi-ai-hub: repositorio común agéntico
- Repositorios de documentación
- Modelo de distribución de tools y skills
- Relación entre memoria, documentación y Work Ledger
- Modelo de identidad y permisos
- Modelo de scopes y recursos
- Observabilidad y auditoría
- Flujos operativos de ejemplo
- Topología inicial de Kubernetes
- Orden recomendado de despliegue
- Decisiones consolidadas
- Riesgos y controles
- Cuestiones abiertas
- Resultado esperado
1. Resumen ejecutivo¶
Wetopi se va a reconstruir sobre Kubernetes con un enfoque AI-first desde el primer día.
La intención no es construir una plataforma tradicional y añadir agentes después. La nueva Wetopi debe asumir desde su base que:
- habrá agentes autónomos operando de forma continua;
- habrá varios Hermes actuando como asistentes personales de empleados y como agentes de coding;
- habrá agentes Google ADK standalone, especialistas, observers y managers;
- humanos y agentes compartirán conocimiento, tareas, documentación y servicios;
- los agentes deberán coordinarse antes de modificar recursos compartidos;
- las acciones relevantes deberán quedar registradas;
- los secrets deberán estar fuera del contexto LLM siempre que sea posible;
- la documentación debe ser directamente editable por agentes;
- la memoria factual de la organización debe ser compartida entre runtimes;
- las memorias personales de cada Hermes deberán mantenerse separadas.
La primera capa que se desplegará en la nueva infraestructura será precisamente la infraestructura agéntica común.
Los componentes iniciales serán:
- Agent Runtime Layer
- Hermes por empleado.
-
Agentes ADK de flota.
-
Memory Plane
- Memoria institucional común de Wetopi.
-
Memoria factual, procedural, operacional, decisiones y episodios relevantes.
-
Work Coordination Plane
- Kanban/ticketing como interfaz humana.
-
Work Ledger como mecanismo real de coordinación entre agentes.
-
Secrets Plane
-
OpenBao como vault central.
-
Documentation Plane
- Markdown puro versionado en Git.
-
MkDocs Material como interfaz web.
-
AI Hub
- Repositorio común para skills, tools, librerías, componentes y contratos reutilizables por todos los agentes.
El objetivo es que estos servicios formen la capa base de operación inteligente de Wetopi antes de reconstruir encima el resto de servicios de negocio y hosting.
2. Objetivo del proyecto¶
Construir una nueva plataforma interna de Wetopi sobre Kubernetes donde los agentes sean ciudadanos de primera clase.
La plataforma debe permitir que cualquier agente:
- descubra conocimiento antes de actuar;
- conozca qué tareas están en curso;
- detecte conflictos con otros agentes;
- reclame trabajo;
- adquiera leases sobre recursos;
- declare su intención;
- deje trazabilidad;
- utilice secrets sin exponerlos innecesariamente al modelo;
- consulte documentación en Markdown;
- contribuya conocimiento factual a la organización;
- comparta infraestructura común independientemente de si corre sobre Hermes, ADK u otro runtime futuro.
3. Principios de diseño¶
3.1 AI-first¶
Cada servicio deberá responder afirmativamente a esta pregunta:
¿Puede un agente consumir este sistema de forma programática, segura y auditable sin depender de una interfaz humana?
Se priorizarán:
- APIs;
- Git;
- Markdown;
- identidad de workload;
- webhooks y eventos;
- formatos estructurados;
- políticas;
- trazabilidad;
- contratos estables.
3.2 Human-compatible, agent-native¶
Los humanos seguirán teniendo UI:
- Kanban;
- documentación web;
- Web UI de secretos;
- dashboards;
- revisión de tareas.
Pero la UI nunca será el único canal de acceso.
3.3 Source of truth explícitos¶
| Dominio | Source of truth |
|---|---|
| Código | Git |
| Skills / tools / componentes AI | wetopi-ai-hub |
| Documentación | Markdown en Git |
| Trabajo y coordinación | Work Ledger |
| Conocimiento factual | Memory Plane |
| Secrets | OpenBao |
| Estado real de infraestructura | APIs del sistema correspondiente |
| Preferencias personales | Memoria local de Hermes |
3.4 No convertir la memoria en una copia del mundo¶
La memoria guarda conocimiento útil, no sustituye a los sistemas autoritativos.
Ejemplo:
Kubernetes replicas = source of truth real
Fleet Memory =
"este servicio suele correr con 5 replicas"
+
histórico
+
decisiones
+
procedimientos
Si hay contradicción, gana la fuente viva autoritativa.
3.5 Least privilege¶
Cada agente tendrá únicamente:
- tools necesarias;
- scopes de memoria necesarios;
- secrets necesarios;
- permisos de Work Ledger necesarios;
- recursos modificables necesarios.
3.6 Trazabilidad antes que autonomía ciega¶
Las acciones importantes deben poder responder:
¿Qué ocurrió?
¿Quién lo hizo?
¿Por qué?
¿Sobre qué recurso?
¿Con qué ticket?
¿Con qué tool?
¿Cuándo?
¿Cuál fue el resultado?
3.7 Runtime-agnostic¶
Los servicios compartidos no deben diseñarse exclusivamente para ADK o Hermes.
Se debe poder añadir en el futuro:
sin cambiar el diseño institucional.
4. Arquitectura general¶
HUMANS
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Hermes Web UIs Git / CLI
│
│
┌────────────┴───────────────────────────────────┐
│ AGENTIC SERVICES LAYER │
│ │
│ Memory Work Ledger Secrets Docs │
│ │ │ │ │ │
│ │ │ │ │ │
│ └──────────── AI HUB / contracts ─────┘ │
└────────────┬───────────────────────────────────┘
│
┌─────┴─────────────────────────────┐
│ │
▼ ▼
ADK Fleet Hermes Fleet
│ │
└────────────────┬──────────────────┘
│
▼
Kubernetes
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Infra Hosting Business
5. Actores del sistema¶
Modelo común:
Cada actor debe tener como mínimo:
Ejemplos:
actor_id: platform-observability-manager
actor_type: agent
runtime: adk
crew: platform
role: manager
6. Servicios agénticos prioritarios¶
Los primeros servicios funcionales que deben existir son:
1. Kubernetes base
2. Identity / workload identity
3. OpenBao
4. Memory Plane
5. Work Coordination Plane
6. Documentation Plane
7. wetopi-ai-hub
8. Hermes
9. ADK Fleet
Todos los demás servicios internos podrán después apoyarse en esta base.
7. Work Coordination Plane: Kanban, tickets y coordinación¶
7.1 El Kanban no es el sistema¶
La interfaz Kanban es para humanos.
El sistema real es un:
Shared Work Ledger / Work Coordination Plane
Su misión es evitar que Hermes, ADK y humanos ejecuten trabajos contradictorios.
7.2 Regla principal¶
Ningún agente modifica un recurso compartido sin consultar primero el Work Ledger cuando la acción pueda interferir con otro actor, requiera seguimiento o tenga impacto operativo.
No toda lectura genera ticket.
7.3 Estados¶
7.4 Ticket mínimo¶
id: OPS-381
title: Upgrade ingress
owner: hermes-sre
status: IN_PROGRESS
scope:
- k8s:cluster:k3s01
- k8s:deployment:ingress
risk: medium
lease_until: ...
activity:
- inspected current deployment
- updating configuration
7.5 Resource scopes¶
Ejemplos:
github:repo:wetopi-api
k8s:cluster:k3s01
k8s:namespace:agents
k8s:deployment:support-manager
ceph:cluster:wetopi
wordpress:site:12345
dns:zone:wetopi.com
marketing:campaign:summer
7.6 Lock modes¶
7.7 Leases¶
Los locks deben tener TTL.
Si el agente desaparece, el recurso vuelve a quedar disponible.
7.8 Intent¶
Antes de ejecutar cambios relevantes:
intent:
action: restart
target: support-manager
reason: memory leak
expected_effect: rolling restart
7.9 Activity journal¶
No guardar chain-of-thought.
Guardar hechos operativos:
11:02 claimed OPS-381
11:03 inspected deployment
11:05 rollout started
11:08 health checks OK
11:09 released lease
7.10 Task vs Agent Run¶
La tarea es durable.
El run es una ejecución.
7.11 API común¶
Dentro de wetopi-ai-hub:
Interfaz:
work.list(...)
work.get(...)
work.create(...)
work.claim(...)
work.release(...)
work.update(...)
work.comment(...)
work.complete(...)
work.find_conflicts(...)
work.acquire(...)
work.renew(...)
work.release_resources(...)
work.link(...)
Operación semántica de alto nivel:
7.12 Backend¶
Candidatos analizados:
- Muster
- Plane
- It's a Plan
La decisión arquitectónica importante es:
el backend es reemplazable.
Los agentes consumen el Wetopi Work Ledger contract, no directamente el API específico del producto.
8. Memory Plane: memoria compartida de Wetopi¶
Wetopi ya dispone de una memoria propia inspirada conceptualmente en Memory Bank.
Debe evolucionar hacia un servicio institucional central.
8.1 Consumidores¶
Hermes Developer
Hermes SRE
Hermes Marketing
ADK Observers
ADK Specialists
ADK Managers
futuros agentes
8.2 Clases de memoria¶
Factual¶
Operational¶
Debe admitir TTL.
Procedural¶
Decisions¶
Shared episodic¶
8.3 Temporalidad¶
No sobrescribir sin historia.
8.4 Escritura conservadora¶
API preferida:
Resultado:
8.5 Provenance¶
Cada memoria relevante debe poder almacenar:
8.6 Autoridad¶
8.7 Scopes¶
8.8 API¶
memory_search()
memory_get_fact()
memory_propose_fact()
memory_update_fact()
memory_get_history()
memory_forget()
La implementación interna queda desacoplada.
9. Memoria local de Hermes + memoria factual global¶
Cada Hermes tendrá dos tipos de memoria.
9.1 Local Personal Memory¶
Almacena información útil para asistir a ese empleado:
- preferencias;
- forma de trabajar;
- contexto individual;
- aprendizaje;
- tareas personales;
- hábitos.
No se comparte automáticamente.
9.2 Fleet Memory¶
Memoria institucional:
- arquitectura;
- infraestructura;
- procedimientos;
- hechos;
- decisiones;
- incidentes;
- conocimiento colectivo.
9.3 Regla¶
Local memory is permissive. Fleet memory is conservative.
10. Integración de Hermes con la memoria de Wetopi¶
Hermes dispone de un mecanismo de Memory Provider Plugin.
La integración propuesta:
10.1 Retrieval automático¶
El provider puede ejecutar:
antes del turno.
Así Hermes recibe automáticamente contexto institucional relevante.
10.2 No sincronizar conversaciones globalmente¶
Se recomienda:
Las memorias personales permanecen personales.
10.3 Escritura explícita¶
Tools:
11. Secrets Plane: Vault central con OpenBao¶
11.1 Decisión¶
OpenBao es el candidato principal.
El requisito de autofill de navegador no es relevante.
La Web UI es suficiente para humanos.
11.2 Humanos¶
Podrán:
- guardar credenciales;
- editar;
- buscar;
- copiar passwords;
- gestionar secrets.
11.3 Agentes¶
Los agentes deben usar workload identity.
11.4 Secrets fuera del LLM¶
No:
Sí:
11.5 Dynamic secrets¶
Objetivo futuro:
- DB temporary credentials;
- SSH certificates;
- PKI;
- short-lived credentials;
- automated revocation.
11.6 Audit¶
Todos los accesos relevantes deben quedar auditados.
12. Documentation Plane: Markdown + Git + MkDocs Material¶
12.1 Decisión¶
Migrar progresivamente de:
a:
12.2 Git es source of truth¶
Los agentes no necesitan API de documentación.
Pueden utilizar:
12.3 Humans¶
MkDocs Material aporta:
- navegación;
- search;
- responsive UI;
- dark mode;
- syntax highlighting;
- tablas;
- TOC;
- admonitions;
- estilos técnicos;
- CSS limpio.
12.4 Pipeline¶
13. Estrategia de repositorios¶
La nueva plataforma necesita una estrategia explícita de repositorios desde el inicio.
El objetivo es evitar:
- duplicar tools;
- copiar skills entre agentes;
- mantener variantes divergentes;
- mezclar documentación con código runtime;
- acoplar componentes compartidos a un agente concreto.
Se propone separar cinco categorías.
Wetopi Git Organization
│
├── wetopi-ai-hub
│
├── wetopi-docs
│
├── wetopi-agents
│ └── o repos por crew/agente si crece
│
├── wetopi-agent-services
│
└── wetopi-platform
La nomenclatura definitiva puede cambiar, pero las responsabilidades deben mantenerse separadas.
13.1 Repositorio: wetopi-ai-hub¶
Repositorio central reutilizable por todos los sistemas agénticos.
Contendrá:
- skills;
- tools;
- prompts/contracts compartidos;
- schemas;
- agent components;
- SDKs internos;
- wrappers;
- policies reutilizables;
- evaluaciones;
- test fixtures.
No contendrá:
- secretos;
- documentación general de Wetopi;
- state de agentes;
- memories personales;
- configuración específica sensible de producción.
13.2 Repositorio: wetopi-docs¶
Source of truth de la documentación institucional y operativa.
Renderizado mediante MkDocs Material.
13.3 Repositorio: wetopi-agents¶
Opción inicial recomendada para mantener la flota interna mientras el número de agentes sea manejable.
Puede contener:
Cada agente tendrá:
Los tools comunes NO se duplican aquí.
Se consumen desde wetopi-ai-hub.
13.4 Repositorio: wetopi-agent-services¶
Servicios centrales del plano agéntico:
memory-service/
work-ledger-adapter/
hermes-memory-provider/
agent-identity/
approval-service/
future shared services/
Puede comenzar como monorepo y separarse cuando algún componente necesite lifecycle independiente.
13.5 Repositorio: wetopi-platform¶
Infraestructura declarativa Kubernetes.
Ejemplo:
Debe ser la fuente GitOps de la infraestructura nueva.
14. wetopi-ai-hub: repositorio común agéntico¶
Este repo será una pieza estratégica.
Su propósito es responder:
¿Dónde vive cualquier capability reutilizable por más de un agente?
Respuesta:
14.1 Estructura propuesta¶
wetopi-ai-hub/
│
├── README.md
├── pyproject.toml
│
├── skills/
│ ├── kubernetes/
│ ├── ceph/
│ ├── wordpress/
│ ├── incident-response/
│ ├── development/
│ ├── marketing/
│ └── ...
│
├── tools/
│ ├── kubernetes/
│ ├── ceph/
│ ├── consul/
│ ├── wordpress/
│ ├── workledger/
│ ├── memory/
│ ├── docs/
│ ├── github/
│ └── ...
│
├── components/
│ ├── evidence-ledger/
│ ├── investigation-loop/
│ ├── approval/
│ ├── conflict-check/
│ └── ...
│
├── contracts/
│ ├── work-ledger/
│ ├── memory/
│ ├── actor-identity/
│ ├── evidence/
│ └── ...
│
├── schemas/
│ ├── task.schema.json
│ ├── fact.schema.json
│ ├── actor.schema.json
│ └── ...
│
├── sdk/
│ ├── python/
│ └── ...
│
├── evals/
│ ├── tool-calls/
│ ├── memory-retrieval/
│ └── ...
│
└── tests/
14.2 Skills vs tools¶
Debe mantenerse una separación semántica.
Skill¶
Describe:
- conocimiento;
- procedimiento;
- estrategia;
- instrucciones;
- cuándo utilizar determinadas capabilities.
Ejemplo:
Tool¶
Ejecuta una acción concreta.
Ejemplo:
Un skill puede utilizar varias tools.
14.3 Components¶
Los components son comportamientos reutilizables de nivel superior.
Ejemplos:
investigation-loop
hypothesis-manager
evidence-ledger
work-conflict-guard
human-approval
memory-curator
No son necesariamente tools individuales.
Pueden ser:
- librerías;
- callbacks;
- subagents;
- middleware;
- adapters;
- policies.
14.4 Contracts¶
Los sistemas centrales deben exponerse mediante contratos propios.
Ejemplos:
Wetopi Work Ledger Contract
Wetopi Memory Contract
Wetopi Actor Identity Contract
Wetopi Evidence Contract
Así se evita que los agentes dependan directamente de:
- Muster;
- Plane;
- OpenBao internals;
- la implementación concreta de Memory Plane.
14.5 Versionado¶
Todo componente compartido debe ser versionable.
Ejemplo:
o componentes versionados independientemente cuando sea necesario.
Los agentes desplegados deben poder informar:
para reproducibilidad.
14.6 Distribución¶
No se recomienda copiar manualmente tools.
Opciones válidas:
Python package interno¶
o paquetes separados:
Build-time vendoring¶
La imagen del agente incorpora las capabilities necesarias durante build.
Symlinks¶
Útiles en desarrollo local/monorepo, menos deseables como mecanismo de distribución productivo.
14.7 Regla¶
Una tool reutilizada por dos agentes deja de pertenecer al agente y pasa a
wetopi-ai-hub.
15. Repositorios de documentación¶
Se propone inicialmente un repositorio principal:
Estructura:
wetopi-docs/
├── mkdocs.yml
└── docs/
├── index.md
│
├── company/
│
├── architecture/
│
├── infrastructure/
│
├── kubernetes/
│
├── wordpress/
│
├── procedures/
│
├── runbooks/
│
├── agents/
│
├── security/
│
├── incidents/
│
└── adr/
15.1 Separación futura¶
Si la documentación crece mucho, podría separarse en:
pero no hacerlo inicialmente sin necesidad.
Un repositorio único ofrece:
- búsqueda global;
- enlaces simples;
- menor fragmentación;
- mejor contexto para agentes;
- CI más sencillo.
15.2 Docs del propio código¶
La documentación específica de desarrollo de un componente puede quedarse junto al código.
Ejemplo:
Mientras que el conocimiento institucional debe ir a:
Regla:
README explica el componente.
wetopi-docsexplica cómo Wetopi lo utiliza, opera y gobierna.
16. Modelo de distribución de tools y skills¶
Flujo propuesto:
wetopi-ai-hub
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Hermes Developer Hermes SRE ADK Fleet
│ │ │
└────────────────┼────────────────┘
│
shared contracts
16.1 No entregar 70 tools al LLM¶
Que existan 70 tools en el AI Hub no significa que un agente deba verlas todas.
Cada agente declara sus capabilities.
Ejemplo:
agent: wordpress-db-specialist
tools:
- memory.search
- work.plan
- work.comment
- wordpress.inspect_db
- database.query_readonly
16.2 Capabilities por rol¶
El bundle se construye según:
16.3 Testing central¶
Cada tool reutilizable debe tener:
- unit tests;
- contract tests;
- permission tests;
- safe failure behavior;
- structured result schema.
17. Relación entre memoria, documentación y Work Ledger¶
Son tres sistemas diferentes.
Work Ledger¶
Memory Plane¶
Documentation¶
Flujo:
incident
↓
ticket
↓
investigation
↓
validated facts
↓
Memory Plane
↓
procedure / ADR / postmortem
↓
wetopi-docs
18. Modelo de identidad y permisos¶
La identidad debe ser transversal.
Ejemplo:
Debe aparecer en:
- Kubernetes;
- OpenBao;
- Memory Plane;
- Work Ledger;
- audit logs;
- observability.
Ideal:
19. Modelo de scopes y recursos¶
Convención compartida:
company:wetopi
crew:platform
crew:development
crew:marketing
customer:123
site:456
cluster:k3s01
namespace:agents
repo:wetopi-api
service:foo
Puede utilizarse para:
- ACL;
- memoria;
- locks;
- visibilidad;
- ownership;
- auditoría.
20. Observabilidad y auditoría¶
Campos comunes:
Ejemplo:
actor_id: platform-sre-manager
task_id: INC-492
run_id: run-492-03
tool: kubernetes.restart
resource: k8s:deployment:support-manager
result: success
No registrar:
- secrets;
- chain-of-thought;
- información privada sin necesidad.
21. Flujos operativos de ejemplo¶
21.1 ADK detecta incidencia¶
Observer
↓
detect
↓
Work Ledger
↓
INC-492
↓
Specialist claims
↓
resource lease
↓
investigation
↓
journal
↓
fix
↓
review
↓
done
21.2 Hermes intenta tocar un recurso ocupado¶
Hermes SRE
↓
work.plan()
↓
conflict detected
↓
resource owned by ADK specialist
↓
Hermes waits / comments / coordinates
21.3 Hermes aprende un hecho de Wetopi¶
Hermes
↓
propose_fact
↓
Memory Service
↓
validation
↓
Fleet Memory
↓
available to ADK + other Hermes
21.4 Agent uses secret¶
Agent
↓
tool call
↓
Tool Runtime
↓
OpenBao
↓
credential
↓
external service
LLM does not see credential
21.5 Agent updates docs¶
Agent
↓
edit Markdown
↓
branch / commit / PR
↓
review
↓
merge
↓
MkDocs build
↓
human-readable website
22. Topología inicial de Kubernetes¶
Propuesta conceptual:
Kubernetes
│
├── agent-runtime/
│ ├── hermes-*
│ └── adk-*
│
├── agent-services/
│ ├── memory-service
│ ├── work-ledger
│ ├── openbao
│ └── docs
│
├── shared-data/
│ ├── postgres
│ └── object-storage
│
├── observability/
│
└── business-workloads/
Los namespaces definitivos deberán diseñarse considerando:
- seguridad;
- NetworkPolicies;
- lifecycle;
- RBAC;
- ownership.
23. Orden recomendado de despliegue¶
Fase 0 — Kubernetes foundation¶
- cluster;
- networking;
- ingress;
- DNS;
- TLS;
- storage;
- PostgreSQL;
- object storage si aplica;
- observabilidad básica;
- GitOps.
Fase 1 — Identity + Secrets¶
Desplegar OpenBao.
Implementar:
- Kubernetes Auth;
- workload identities;
- policies;
- audit.
Fase 2 — Git foundations¶
Crear:
Añadir:
- branch protection;
- CI;
- CODEOWNERS;
- versioning;
- release conventions.
Fase 3 — Memory Plane¶
Productivizar la memoria existente.
Añadir:
- API estable;
- scopes;
- provenance;
- candidate facts;
- contradiction handling;
- TTL;
- history.
Fase 4 — Work Coordination Plane¶
Seleccionar backend.
Crear el adapter/contract propio.
Implementar:
- actors;
- tickets;
- resource scopes;
- conflict detection;
- leases;
- intents;
- journal.
Fase 5 — Documentation Plane¶
Crear wetopi-docs.
Desplegar:
- MkDocs Material;
- CI;
- static hosting.
Migrar progresivamente documentación útil existente.
Fase 6 — wetopi-ai-hub¶
Consolidar tools hoy dispersas.
Prioridad inicial:
Definir contratos estables.
Fase 7 — Hermes¶
Desplegar un Hermes por empleado según necesidad.
Cada Hermes tendrá:
personal local memory
+
Wetopi Fleet Memory
+
Work Ledger
+
role-specific tools
+
documentation access
Fase 8 — ADK Fleet¶
Desplegar observers, specialists y managers.
Todos usan:
- Memory Plane;
- Work Ledger;
- OpenBao;
- Docs;
- AI Hub;
- observabilidad común.
Fase 9 — Construcción del resto de Wetopi¶
Con los servicios agénticos ya operativos, comenzar la migración/reconstrucción de los demás workloads de Wetopi.
Los agentes participan desde el inicio en:
- discovery;
- documentación;
- migration;
- testing;
- operaciones;
- observabilidad;
- incident response.
24. Decisiones consolidadas¶
D-001 — Kubernetes como plataforma base¶
La nueva Wetopi se reconstruirá sobre Kubernetes.
D-002 — AI-first¶
Los sistemas agénticos se despliegan antes que el resto de la plataforma.
D-003 — Hermes + ADK¶
Se combinarán:
- Hermes como asistente personal/coding por empleado;
- ADK para la flota standalone y especializada.
D-004 — Memoria dual¶
Hermes utilizará:
Los ADK utilizarán principalmente Fleet Memory más state/session cuando corresponda.
D-005 — Memoria institucional propia¶
Se reutilizará y evolucionará el Memory Plane ya creado internamente.
D-006 — Integración de Hermes mediante Memory Provider¶
El retrieval global se integrará mediante el mecanismo de provider de Hermes.
No se volcarán conversaciones personales automáticamente a Fleet Memory.
D-007 — OpenBao¶
OpenBao será el candidato principal como secrets manager central.
D-008 — Secret isolation¶
Las tools consumirán secrets sin introducirlos en contexto LLM siempre que sea posible.
D-009 — Work Ledger¶
El Kanban se considera UI de un sistema más profundo de coordinación.
D-010 — Backend desacoplado¶
Muster, Plane o alternativa se utilizarán detrás de un contrato Wetopi.
D-011 — Markdown como formato documental¶
Markdown + Git será el source of truth.
D-012 — MkDocs Material¶
Se utilizará como primera opción para renderizado web de documentación.
D-013 — AI Hub¶
Se creará wetopi-ai-hub como repositorio común de:
- skills;
- tools;
- components;
- contracts;
- schemas;
- SDKs;
- evals.
D-014 — Tools compartidas centralizadas¶
Una tool usada por más de un agente debe trasladarse al AI Hub.
D-015 — GitOps¶
La infraestructura Kubernetes debe quedar declarada en Git.
25. Riesgos y controles¶
25.1 Contaminación de memoria¶
Riesgo: agentes almacenan hipótesis como hechos.
Control:
- candidate facts;
- provenance;
- confidence;
- validation;
- source authority.
25.2 Conflictos entre agentes¶
Riesgo: varios agentes modifican el mismo recurso.
Control:
- Work Ledger;
- scopes;
- leases;
- intents;
- conflict check.
25.3 Secrets en contexto¶
Riesgo: token termina en prompt/log/trace.
Control:
- secret retrieval dentro de tool runtime;
- dynamic secrets;
- redaction;
- audit.
25.4 Tool sprawl¶
Riesgo: cada agente implementa su versión.
Control:
wetopi-ai-hub;- contracts;
- versioning;
- tests.
25.5 Context overload¶
Riesgo: demasiadas tools disponibles para un LLM.
Control:
- bundles por rol;
- tool routing;
- APIs semánticas de alto nivel.
25.6 Documentación obsoleta¶
Riesgo: los agentes confían en docs antiguas.
Control:
- Git;
- ownership;
- review dates;
- links con fuentes autoritativas;
- documentación vs factual memory claramente diferenciadas.
26. Cuestiones abiertas¶
Aún deben decidirse:
- Backend final del Work Coordination Plane:
- Muster;
- Plane;
- It's a Plan;
-
alternativa.
-
Authentication humana central:
- OIDC provider existente;
-
SSO objetivo.
-
Modelo exacto de namespaces Kubernetes.
-
Storage definitivo de Memory Plane.
-
Estrategia de embeddings/reranking del Memory Plane.
-
Convención exacta de nombres de scopes.
-
Si
wetopi-agentspermanece monorepo o se divide cuando crezca. -
Packaging definitivo de
wetopi-ai-hub. -
CI/CD y GitOps concretos.
-
Modelo de aprobación humana para acciones de alto riesgo.
27. Resultado esperado¶
Al finalizar la primera etapa, Wetopi debería disponer de una base parecida a:
WETOPI AI-FIRST FOUNDATION
Humans
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Hermes Kanban Docs
│ │ │
└──────┬──────┴──────┬──────┘
│ │
Work Ledger Fleet Memory
│ │
└──────┬──────┘
│
wetopi-ai-hub
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Hermes Fleet ADK Fleet Future Agents
│ │
└──────────────────┼──────────────────┘
│
OpenBao
│
Kubernetes
│
┌──────────┼──────────┐
▼ ▼ ▼
Infra Hosting Business
La consecuencia más importante es que Wetopi no tendrá simplemente "algunos agentes".
La organización dispondrá de una infraestructura operacional diseñada para humanos y agentes simultáneamente:
- conocimiento institucional compartido;
- trabajo coordinado;
- secrets gobernados;
- documentación agent-native;
- tools y skills reutilizables;
- identidad y auditoría comunes;
- repositorios definidos;
- capacidad de incorporar nuevos runtimes sin rediseñar la plataforma.
Ésta será la base sobre la que reconstruir el resto de Wetopi.