Resultado clave: Espacio de trabajo multiagente totalmente automatizado con memoria persistente FTS5, 21 habilidades personalizadas y 24 tareas de orquestación cron activas
Resumen: Diseñé y desplegué una red autónoma de multiagentes ejecutándose en un VPS dedicado de Google Cloud. El sistema actúa como un ejecutor digital unificado, enrutando las comunicaciones a través de múltiples pasarelas de chat (Telegram, Discord, WhatsApp, correo electrónico) hacia un núcleo cognitivo singular respaldado por Obsidian con memoria persistente entre sesiones. Además, Oz está configurado para comunicarse directamente con mi proyecto Hermes Agent para coordinar flujos de trabajo distribuidos.
El Problema
Desafío:
Fragmentación multicanal: Gestión de flujos de información dispares a través de múltiples canales de comunicación.
Ejecución autónoma a alta velocidad: Necesidad de ejecución programada y continua de copias de seguridad, correos electrónicos, actualizaciones del sistema y auditorías de bóvedas.
Amnesia de sesión: Los agentes LLM tradicionales carecen de memoria persistente, lo que degrada la continuidad de múltiples turnos a lo largo de días o semanas.
Complejidad de la bóveda de Obsidian: Mantener la consistencia estructural, los formatos de esquema y el enrutamiento de notas para una bóveda de Obsidian de más de 230 archivos.
Vulnerabilidades de seguridad: Alto perfil de amenaza de las pasarelas de mensajería pública que requieren una defensa estricta contra inyección de prompts y controles de acceso.
Audiencia: Espacio de trabajo de productividad personal, asistente de base de conocimientos y operador de sistema automatizado.
Restricciones:
Restricciones de API de motores de búsqueda: No se permiten claves de API de búsqueda, lo que obliga a recurrir a una capa de abstracción de extracción personalizada para múltiples motores de búsqueda.
Límites de VPS: Desplegado en un VPS de Google Cloud con 4 vCPUs / 15GB RAM sin swap, lo que exige una gestión cuidadosa de la memoria.
Bloqueos de autenticación: Todas las operaciones de GitHub están limitadas a la autenticación mediante clave SSH debido a entornos de cliente no autenticados.
Almacenamiento de datos: Limitado a archivos locales planos (Markdown, JSON, SQLite) en lugar de bases de datos externas distribuidas.
Enfoque y Decisiones
Arquitectura: Un patrón de despachador centralizado donde Oz actúa como el orquestador principal, enrutando dinámicamente las tareas entrantes a subagentes especializados y basados en roles según la complejidad de la tarea.
Decisiones clave:
Integración de Claude-Mem: Implementación de una base de datos SQLite + FTS5 para inyectar automáticamente contexto entre sesiones en las ejecuciones activas.
Almacenamiento basado primero en Obsidian: Elección de archivos markdown planos para facilitar la visualización, la portabilidad y el análisis manual de gráficos.
Cadena de respaldo multimodelo: Configuración de DeepSeek V4 Flash como el motor principal económico, con rutas de respaldo a los modelos Google Gemini y Grok para mantener el tiempo de actividad.
Compromisos:
Sondeo (Polling) vs Webhooks: Elección de verificación de correo electrónico basada en cron y keepalives (gratuito y sin configuración en la pasarela de OpenClaw) pero introduciendo hasta 8 horas de latencia para las verificaciones de correo electrónico.
Base de conocimientos de archivos planos: Markdown y SQLite requieren menos gestión de infraestructura pero limitan las agregaciones de consultas de múltiples nodos en tiempo real en comparación con las bases de datos vectoriales completas.
Resultados clave e Impacto
Resultado: Ejecución exitosa de un ejecutor autónomo que gestiona autocommits diarios, procesamiento de correos electrónicos, automatización en segundo plano y archivos de notas.
Comparación: Reemplazo de diarios actualizados manualmente, extracción compleja de múltiples aplicaciones y chats desconectados con un único asistente de espacio de trabajo persistente e inteligente.
Impacto: Se lograron operaciones automatizadas robustas con capacidades de respaldo que garantizan un servicio continuo incluso durante las interrupciones del modelo principal.
Métricas principales
Métrica
Valor
Origen / Detalle
LLM Principal
DeepSeek V4 Flash
openclaw.json (agents.defaults)
Registro de modelos
27 modelos (3 proveedores)
Pool de respaldo personalizado (DeepSeek, Gemini, Grok)
Tareas Cron activas
24 programadas
Salida de cron list
Bóveda de Obsidian
232 notas (37MB)
Espacio de trabajo personal y base de memoria
Base de datos de memoria
323 entradas (11MB)
Sistema SQLite + FTS5 de Claude-Mem
Habilidades personalizadas
21 habilidades de espacio de trabajo
Plugins personalizados y scripts de automatización
Recursos de servidor
4 vCPUs / 15GB RAM
Google Cloud VPS (Ubuntu 22.04 LTS)
Uso de RAM
~1.8GB / 15GB
Huella de memoria promedio en inactividad
Latencia de respuesta
1 - 3 segundos
Caché activa de DeepSeek (hasta 15s en inicios en frío de multiagentes)
Pasarelas activas
Telegram, Discord, WhatsApp
Menciones, DMs abiertos y grupos de difusión
Inmersión técnica profunda
Detalles destacados:
imap-smtp-email: Integra iCloud SMTP con enrutamiento de cadena CC obligatorio (oz@franzdomingo.dev → lista CC) ejecutándose mediante scripts de Node.js.
multi-search-engine: Agrega 16 motores de búsqueda (globales y regionales) sin requerir claves de API activas.
self-improving-agent: Admite persistencia de aprendizaje al guardar experiencias directamente en un directorio .learnings/ para moldear futuros parámetros de ejecución.
prompt-injection-guard: Clasificación de mensajes en tiempo real, validación de hash de contraseña y detección de suplantación de identidad (spoofing).
Verificación: Monitoreado a través de turnos de agentes aislados y vinculados a la sesión, confirmaciones de Git automatizadas y transmisiones periódicas de registros en Telegram.
Optimizaciones: Se implementó un enrutamiento consciente de los costos, enviando tareas simples a modelos económicos y reservando modelos de razonamiento premium para tareas lógicas de múltiples pasos.
Reflexiones
Qué haría diferente: Exploraría la migración de algunas de las acciones de sondeo (polling) a integraciones de webhooks para lograr una menor latencia en las entradas (como las actualizaciones de correo electrónico) en lugar de depender únicamente del sondeo programado.
Éxitos: El patrón de despachador centralizado demostró ser altamente confiable, aislando flujos de trabajo especializados (prosa, recuperación, código) a entornos de subagentes dedicados y limpios.
Lecciones aprendidas: Las estructuras de archivos planos son excepcionalmente portátiles y eficientes a escala (~200+ notas), pero a medida que la bóveda se acerque a más de 1000 notas, la indexación y la recuperación requerirán la migración a un almacenamiento en caché de base de datos estructurada.
Mis contribuciones
Arquitectura de sistemas y despliegue: Configuré y desplegué el entorno de ejecución Node.js/OpenClaw en Google Cloud, gestionando las configuraciones de acceso SSH, la administración de procesos VPS y los enlaces systemd personalizados.
Desarrollo de habilidades: Desarrollé la biblioteca de espacio de trabajo de 21 habilidades desde cero, implementando relés de correo electrónico de iCloud, raspadores de búsqueda sin clave, utilidades de PDF y bases de datos de inyección de memoria.
Diseño de seguridad e integridad: Construí el subsistema Prompt Injection Guard, manteniendo la seguridad de acceso a través de endpoints públicos expuestos (bot de Telegram, servidores de Discord).
Diseño del pipeline de automatización: Configuré el programador cron de 24 tareas que ejecuta copias de seguridad diarias, sincronizaciones de código y señales de vida (health heartbeats).
Arquitectura del Proyecto
El sistema utiliza un patrón de despachador centralizado para enrutar y ejecutar entradas a través de tres capas operativas principales:
Capa
Componentes
Rol y flujo de datos
Pasarelas de ingreso
Telegram, Discord, WhatsApp, WebChat
Actúa como la interfaz de usuario, recibiendo consultas y formateando respuestas adecuadas al canal.
Enrutamiento central
Agente principal Oz (Despachador)
Evalúa la complejidad de la carga útil, determina la cascada de despacho y gestiona el ciclo de vida de los agentes ejecutores (workers).
Pool de ejecución
Más de 15 subagentes especializados
Ejecuta tareas personalizadas del espacio de trabajo (recuperación, scripting, ejecución, seguridad).
Despachador principal Oz: único punto de decisión. Evalúa la complejidad de la carga útil ocurrida (simple=0 envíos, compleja=1-2, ultra=5+) y delega al especialista adecuado. Mantiene límites de profundidad: no más de 5 llamadas de herramientas consecutivas sin validación del usuario.
Tríada de la Bóveda: tres agentes especializados gestionan el ciclo de vida de la bóveda de Obsidian:
Librarian (Bibliotecario): Propietario de los pipelines de índice, búsqueda y recuperación de la bóveda. Oz nunca busca con grep directamente; Librarian confirma las rutas y luego Oz maneja la salida. Ejecuta su propia tarea cron de archivo diario.
Writer (Escritor): Especializado en formatear prosa, informes y archivos de documentación. Entrenado en Hemingway, Orwell, Strunk & White, King. Controla la gramática, la selección del registro y la imposición de "mostrar en lugar de contar". Produce todo el contenido escrito de la bóveda.
Keeper (Guardián): Maneja plantillas de metadatos, conformidad de frontmatter y archivado de elementos obsoletos. Ejecuta una tarea cron de mantenimiento cada 3 días. Impone una estructura de bóveda altamente escalable a lo largo de notas y directorios.
Motor Claude-Mem: se conecta directamente a SQLite local (FTS5, gestionado por systemd), recuperando embeddings de búsqueda e inyectando historial entre sesiones en los prompts de los LLM. Almacena en caché las solicitudes de contexto durante 60 segundos para evitar sobrecargas. Disyuntor (circuit breaker): 3 fallos consecutivos = 30 segundos de enfriamiento. Los agentes excluidos (coder, math-solver, front-end-developer, multimedia-specialist) deben consultarlo manualmente a través del endpoint curl. Hay una interfaz web privada disponible para la navegación manual. Tenga en cuenta que este mecanismo reduce significativamente el uso total de tokens.
Pool de subagentes ejecutores (Workers) (14 especialistas nombrados + Oz): todos los agentes de la red tienen acceso a Claude Code, Gemini CLI y Antigravity, cada uno equipado con sus respectivas habilidades integradas:
Researcher (Investigador) → Pipeline que prioriza la bóveda: Librarian → Gemini CLI → web_search → web_fetch
Coder (Programador) → Programación de archivos múltiples, depuración y scripts complejos
Messenger (Mensajero) → Toda la comunicación externa (correo electrónico con cadena CC obligatoria, Discord, Telegram)
Math-solver (Resolutor matemático) → Todos los problemas de matemáticas, sin excepciones (comprobación rigurosa de casos límite)
Front-end-developer (Desarrollador front-end) → React/UI a través de Claude Code respaldado por DeepSeek + MCP de 21st.dev
Pasarelas de canales: 4 activas (Telegram: 3 grupos, Discord: 1 servidor con menciones filtradas, WhatsApp: DMs abiertos, WebChat), 2 deshabilitadas (Signal, SMS). El correo electrónico opera como una habilidad externa (iCloud SMTP), no como una pasarela.
Límites de recursos: 4 vCPUs, 15GB RAM, 49GB de disco (63% lleno), Node v22.22.2, Ubuntu 22.04 LTS en GCP. 24 tareas cron programadas.
Nota operativa y de alojamiento:
Oz se encuentra alojado activamente en Google Cloud Platform y se ejecuta localmente en una MacBook Air de desarrollo. El código fuente subyacente y el repositorio siguen siendo privados.
