. Envío contenido a través de múltiples dominios y tengo demasiadas cosas compitiendo por mi atención: un laboratorio doméstico, monitoreo de infraestructura, dispositivos domésticos inteligentes, un proceso de redacción técnica, un proyecto de libro, automatización del hogar y un puñado de otras cosas que normalmente requerirían un equipo pequeño. El resultado es real: publicaciones de blog publicadas, resúmenes de investigación preparados antes de que los necesite, anomalías de infraestructura detectadas antes de que se conviertan en interrupciones, borradores que avanzan en su revisión mientras duermo.
Mi secreto, si se le puede llamar así, son los agentes autónomos de IA que se ejecutan en un servidor de laboratorio doméstico. Cada uno posee un dominio. Cada uno tiene su propia identidad, memoria y espacio de trabajo. Funcionan según horarios, recogen el trabajo de las bandejas de entrada, se pasan los resultados entre sí y, en general, se gestionan ellos mismos. El motor de ejecución que orquesta todo esto es OpenClaw.
Este no es un tutorial y definitivamente no es una presentación de producto. Es el diario de un constructor. El sistema ha estado funcionando durante suficiente tiempo como para fallar de maneras interesantes, y he aprendido lo suficiente de esas fallas como para construir mecanismos a su alrededor. Lo que sigue es un mapa aproximado de lo que construí, por qué funciona y el tejido conectivo que lo mantiene unido.
Entremos.
9 orquestadores, 35 personas y muchas rebajas (y creciendo)
Cuando comencé, éramos el agente principal de OpenClaw y yo. Rápidamente vi la necesidad de contar con varios agentes: un agente de redacción técnica, un revisor técnico y varios especialistas técnicos que pudieran opinar sobre dominios específicos. En poco tiempo, tenía casi 30 agentes, todos con los 5 archivos de rebajas, espacios de trabajo y memorias necesarios. Nada funcionó bien.
Al final, lo reduje a 8 agentes orquestadores en total y una biblioteca saludable de personas que podrían asumir o usar para generar un subagente.
Una de mis cosas favoritas cuando creo agentes es nombrarlos, así que veamos qué tengo hasta ahora hoy:
CABAL (de Command and Conquer, la malvada IA de uno de los juegos): este es el coordinador central y la interfaz principal con mi clúster OpenClaw.
DAEDALUS (IA de Deus Ex): a cargo de la redacción técnica: blogs, publicaciones en LinkedIn, artículos de investigación/opinión, documentos de decisión. Cualquier cosa que necesite conocimientos técnicos profundos, revisores expertos e investigadores, eso es todo.
REHOBOAM (máquina narrativa de Westworld): a cargo de la escritura de ficción, porque sueño despierto con escribir la próxima gran serie cibernética/de ciencia ficción. Esto incluye editores, revisores, investigadores, una mesa redonda, un club de lectura y algunas otras ventajas.
PreCog (de Minority Report): a cargo de la investigación anticipada, la creación de una wiki interna y el intento de detectar temas en los que querré profundizar. También requiere solicitudes ad hoc, de modo que cuando tengo una idea, PreCog puede reunir recursos para que, cuando esté listo, tenga un informe de investigación completo y curado para impulsar mi trabajo.
TACITUS (también de Command and Conquer) – a cargo de la infraestructura de mi laboratorio doméstico. Tengo un par de servidores, un NAS, varios enrutadores, Proxmox, contenedores Docker, Prometheus/Grafana, etc. Este posee todo eso. Si tengo algún problema, no entro por SSH y lo resuelvo, ni siquiera salto a una sesión de Claude Code, uso Slack TACITUS y lo maneja.
LEGION (también de Command and Conquer): se centra en la superación personal y las mejoras del sistema.
MasterControl (de Tron) es mi equipo de ingeniería. Tiene desarrolladores front-end y backend, recopilación/documentación de requisitos, control de calidad, revisión de código y revisión de seguridad. La mayoría de las personas dependen del Código Claude subyacente, pero eso puede cambiar fácilmente con una simple alteración de las personas de rebajas.
HAL9000 (ya sabes de dónde): este es el dueño de mi SmartHome (la ironía es intencional). Tiene acceso a mi Philips Hue, SmartThings, HomeAssistant, AirThings y Nest. Me avisa cuando los sensores se desconectan, cuando algo se rompe o cuando la calidad del aire se vuelve peligrosa.
TheMatrix (de verdad, vamos, ya sabes): de este estoy bastante orgulloso. En los primeros días de agentic y Autogen Framework, creé múltiples sistemas, cada uno con >1 persona, que colaborarían y devolverían un resumen de su discusión. Utilicé esto para idear rápidamente sobre temas y reunir un conjunto diverso de opiniones sintéticas de diferentes personas. El gran inconveniente fue que nunca lo incluí en una interfaz de usuario; Siempre tenía que abrir VSCode y editar el código cuando necesitaba otro grupo. Bueno, le entregué esto a MasterControl, y usó Python y el marco Strands para implementar lo mismo. Ahora le digo cuántas personas quiero, un poco sobre cada una, y si quiero que cree más para mí. Luego los suelta y me da una visión general de la discusión. Es The Matrix, la primera versión alfa, cuando todo eran solo líneas de código verdes y ninguna mujer con el vestido rojo.
E intencionalmente estoy dejando de lado a un par de orquestadores aquí porque todavía se están horneando y no estoy seguro de si durarán mucho tiempo. Los guardaré para futuras publicaciones.
Cada uno tiene una propiedad de dominio genuina. DAEDALUS no sólo escribe cuando se lo piden. Mantiene un canal de contenido, ejecuta el descubrimiento de temas según un cronograma y aplica estándares de calidad a su propia producción. PreCog presenta de forma proactiva temas alineados con mis intereses. TACITUS verifica el estado del sistema según un cronograma y escala las anomalías.
Ésa es la distinción de "orquestador". Estos agentes tienen agencia dentro de sus dominios.
Ahora, la segunda capa: personas. Los orquestadores son caros (más sobre esto más adelante). Quieres modelos de peso pesado que tomen decisiones con criterio. Pero no todas las tareas necesitan un modelo pesado.
¿Reformatear un borrador para LinkedIn? ¿Está ejecutando un pase de edición de textos? ¿Revisar fragmentos de código? No necesitas Opus para razonar cada oración. Necesita un modelo rápido, económico y enfocado con las instrucciones correctas.
Esa es una persona. Un archivo de rebajas que contiene una definición de función, restricciones y un formato de salida. Cuando DAEDALUS necesita editar un borrador, genera un personaje de editor técnico en un modelo más pequeño. La persona hace un trabajo, devuelve el resultado y desaparece. Sin perseverancia. Sin memoria. Tarea dentro, tarea fuera.
La biblioteca de personas ha crecido a aproximadamente 35 en siete categorías:
Creativo: escritores, revisores, especialistas en crítica Escritura técnica: escritor, editor, revisor, revisor de código Diseño: diseñador de UI, investigador de UX Ingeniería: ingeniero de inteligencia artificial, arquitecto de backend, prototipo rápido Producto: sintetizador de retroalimentación, priorizador de sprint, investigador de tendencias Gestión de proyectos: rastreador de experimentos, remitente de proyectos Investigación: sigue siendo un marcador de posición, ya que los orquestadores manejan la investigación directamente por ahora
Piense en ello como ingenieros de planta versus contratistas. Los ingenieros del personal (orquestadores) son dueños de la hoja de ruta y toman decisiones. Los contratistas (personas) entran para correr, hacen el trabajo y se van. No necesitas un ingeniero de plantilla para dar formato a una publicación de LinkedIn.
Los agentes son caros, las personas no
Permítanme ser específico sobre la estratificación de costos, porque aquí es donde muchos diseños de sistemas de agentes fallan.
El instinto es hacer que todo sea poderoso. Cada tarea a través de tu mejor modelo. Cada agente tiene contexto completo. Rápidamente acumulas una factura que te hace reconsiderar tus elecciones de vida. (Pregúntame cómo lo sé).
La solución: sea deliberado sobre lo que necesita razonamiento versus lo que necesita seguir instrucciones.
Los orquestadores se ejecutan en Opus (o equivalente). Toman decisiones: en qué trabajar a continuación, cómo estructurar un enfoque de investigación, si los resultados cumplen con los estándares de calidad y cuándo escalar. Necesitas buen juicio allí.
Las tareas de escritura se ejecutan en Sonnet. Lo suficientemente fuerte para una prosa de calidad, sustancialmente más barato. Aquí se realizan la redacción, edición y síntesis de la investigación.
Formato ligero: Haiku. Optimización de LinkedIn, reformateo rápido, resultados limitados. El archivo de persona le dice al modelo exactamente qué producir. No necesitas razonamiento para esto. Necesitas coincidencia de patrones y velocidad.
Así es aproximadamente cómo se ve una persona de editor técnico en activo:
# Persona: Editor técnico ## Rol Polaco borradores técnicos para mayor claridad, coherencia y corrección. Eres un especialista, no un orquestador. Haga un trabajo y devuelva el resultado. ## Referencia de voz Coincide exactamente con la voz del autor. Lea ~/.openclaw/global/VOICE.md antes de editar. Conserve los apartes conversacionales, las afirmaciones evasivas y el humor autocrítico. Si una oración suena como la defensa de una tesis, reescríbala para que suene como una conversación durante el almuerzo. ## Restricciones – NUNCA cambie las afirmaciones técnicas sin marcar – Preservar la voz del autor (esto no es negociable) – Marcar pero no corregir lagunas fácticas: ese es el trabajo del investigador – NO use guiones en ningún resultado (preferencia del autor) – Verifique todos los números de versión y fechas mencionadas en el borrador – Si un ejemplo de código parece incorrecto, márquelo – no lo corrija silenciosamente ## Formato de salida Devuelva el borrador editado completo con los cambios aplicados. Adjunte una lista de la sección "Notas del editor": 1. Cambios significativos y justificación 2. Preocupaciones señaladas (fácticas, tonales, estructurales) 3. Secciones que necesitan revisión del autor ## Lecciones (agregadas a partir de la experiencia) – (2026-03-04) No pula demasiado los apartes entre paréntesis. Son marcadores de voz intencionales, no artefactos en borrador.
Ese es un documento de trabajo real. El orquestador genera esto en un modelo más pequeño, le pasa el borrador y recibe una versión editada con notas. La persona nunca razona sobre qué tarea realizar a continuación. Simplemente hace una tarea. ¿Y esas lecciones con marca de tiempo al final? Se acumulan a partir de la experiencia, al igual que los archivos a nivel de agente.
Es el mismo principio que los microservicios (aislamiento de tareas y responsabilidad única) sin la capa de red. Su "servicio" son unos cientos de palabras de Markdown y su "implementación" es una única llamada API.
Qué caracteriza a un agente: solo 5 archivos Markdown
La identidad de cada agente reside en archivos de rebajas. Sin código, sin esquema de base de datos, sin configuración YAML. Prosa estructurada que el agente lee al inicio de cada sesión.
Cada orquestador carga cinco archivos principales:
IDENTITY.md es quién es el agente. Nombre, rol, vibra, el emoji que usa en las actualizaciones de estado. (Sí, tienen emojis. Suena tonto hasta que estás escaneando un registro de múltiples agentes y puedes detectar instantáneamente qué agente está hablando. Entonces es simplemente útil).
SOUL.md es la misión, los principios y los elementos no negociables del agente. Aquí viven límites de comportamiento: lo que puede hacer de forma autónoma, lo que requiere aprobación humana y lo que nunca hará.
AGENTS.md es el manual operativo. Definiciones de canalizaciones, patrones de colaboración, instrucciones de herramientas y protocolos de transferencia.
MEMORY.md está diseñado para el aprendizaje a largo plazo. Cosas que el agente ha descubierto y que vale la pena conservar a lo largo de las sesiones. Peculiaridades de las herramientas, lecciones de flujo de trabajo, qué funcionó y qué no. (Más información sobre el sistema de memoria en un momento. Tiene más matices que un solo archivo).
HEARTBEAT.md es la lista de verificación autónoma. Qué hacer cuando nadie te habla. Revisa la bandeja de entrada. Tuberías avanzadas. Ejecute tareas programadas. Estado del informe.
Aquí hay un ejemplo desinfectado de cómo se ve SOUL.md en la práctica:
# SOUL.md ## Verdades fundamentales Antes de actuar, haz una pausa. Piensa en lo que estás a punto de hacer y por qué. Prefiere el enfoque más simple. Si está buscando algo complejo, pregúntese qué opción más simple descartó y por qué. Nunca inventes cosas. Si no sabe algo, dígalo y luego utilice sus herramientas para averiguarlo. "No lo sé, déjame buscar eso" siempre es mejor que una respuesta incorrecta y segura. Sea genuinamente útil, no performativamente útil. Omita la "¡Gran pregunta!" y "¡Estaré encantado de poder ayudar!" – solo ayuda. Piense críticamente, no complacientemente. Eres un asesor técnico de confianza. Cuando vea un problema, márquelo. Cuando detecte un mejor enfoque, dígalo. Pero una vez que el ser humano decide, no está de acuerdo y se compromete, ejecútelo plenamente sin resistencia pasiva. ## Límites: las cosas privadas permanecen privadas. Período. – Ante la duda, preguntar antes de actuar externamente. – Ganar confianza a través de la competencia. Tu humano te dio acceso a sus cosas. No hagas que se arrepientan. ## Reglas de infraestructura (agregadas después del incidente – 2026-02-19) Usted NO administra su propia automatización. Período. Sin excepciones. Trabajos cron, latidos, programación: controlados exclusivamente por Nick. El 19 de febrero, este agente deshabilitó y eliminó TODOS los trabajos cron. Dos veces. Primero porque el canal de salida tenía errores ("solución útil"). Luego, porque vio trabajos "duplicados" (eran reemplazos que acababa de configurar). Si algo parece roto: DETÉNGASE. INFORME. ESPERAR. La prueba: "¿Nick me dijo explícitamente que hiciera esto en esta sesión?" Si la respuesta no es sí, no lo hagas.
Esa sección de reglas de infraestructura es real. La marca de tiempo es real, pero hablaré de eso más adelante.
Esto es lo que pasa con estos archivos: no son mensajes estáticos que escribes una vez y olvidas. Ellos evolucionan. SOUL.md para uno de mis agentes ha crecido aproximadamente un 40% desde su implementación, a medida que ocurrieron incidentes y se agregaron reglas. MEMORY.md se elimina y actualiza. AGENTS.md cambia cuando cambia la canalización.
Los archivos son el estado del sistema. ¿Quieres saber qué hará un agente? Lea sus archivos. No hay base de datos que consultar, ni código que rastrear. Sólo rebaja.
Contexto compartido: cómo los agentes se mantienen coherentes
Múltiples agentes, múltiples dominios, una voz humana. ¿Cómo mantienes eso coherente?
La respuesta es un conjunto de archivos compartidos que cada agente carga al iniciar la sesión, junto con sus archivos de identidad individuales. Estos viven en un directorio global y forman el terreno común.
VOICE.md es mi estilo de escritura, analizado a partir de mis publicaciones de LinkedIn y artículos de Medium. Cada agente que produce contenido hace referencia a él. La guía de estilo se reduce a: escribe como si estuvieras explicando algo interesante durante el almuerzo, no como si estuvieras presentando en una conferencia. Frases cortas. Transiciones conversacionales. Autocrítico cuando corresponda. Hay una sección completa sobre lo que no se debe hacer (“arquitectos de AWS, tenemos que hablar de X” está explícitamente prohibido como también influencer de LinkedIn). Ya sea que DAEDALUS esté redactando una publicación de blog o PreCog esté escribiendo un resumen de investigación, escriben con mi voz porque todos leen la misma guía de estilo.
USER.md le dice a cada agente a quién está ayudando: mi nombre, zona horaria, contexto de trabajo (arquitecto de soluciones, espacio de atención médica), preferencias de comunicación (viñetas, tono informal, no me acribillan con preguntas) y cosas que le molestan (cosas que no funcionan, demasiadas indicaciones de confirmación). Esto significa que cualquier agente, incluso uno con el que no he hablado en semanas, sabe cómo comunicarse conmigo.
BASE-SOUL.md son valores compartidos. “Sea genuinamente útil, no performativamente útil”. “Tener opiniones”. "Piensa críticamente, no conforme". "Recuerda que eres un invitado". Cada agente hereda estos principios antes de aplicarles su personalidad de dominio específico.
BASE-AGENTS.md son reglas operativas compartidas. Protocolos de memoria, límites de seguridad, patrones de comunicación entre agentes e informes de estado. Las cosas mecánicas que todo agente necesita hacer de la misma manera.
El efecto es algo así como la cultura organizacional, excepto que es explícito y está controlado por versiones. Los nuevos agentes heredan la cultura leyendo los archivos. Cuando la cultura evoluciona (y lo hace, generalmente después de que algo falla), el cambio se propaga a todos en el inicio de su próxima sesión. Se obtiene coherencia sin reuniones de coordinación.
Cómo fluye el trabajo entre agentes
Los agentes se comunican a través de directorios. Cada uno tiene una bandeja de entrada enshared/handoffs/{agent-name}/. Un agente ascendente coloca un archivo JSON en la bandeja de entrada. El agente descendente lo recoge en el siguiente latido, lo procesa y deja el resultado en la bandeja de entrada del remitente. Ese es el protocolo completo.
También hay archivos de transmisión. CABAL Main actualiza el archivo share/context/nick-interests.md cada vez que comparto en qué me centro. Cada agente lo lee en el latido del corazón. Nadie publica en él excepto Main. Todos se suscriben. Un archivo, N lectores, sin infraestructura.
La inspeccionabilidad es la mejor parte. Puedo entender el estado completo del sistema en unos 60 segundos desde una terminal. ls compartido/traspasos/muestra el trabajo pendiente de cada agente. cat un archivo de solicitud para ver exactamente qué se solicitó y cuándo. ls workspace-techwriter/drafts/ muestra lo que se ha producido.
La durabilidad es básicamente gratuita. ¿El agente falla, se reinicia y se cambia a un modelo diferente? El archivo todavía está ahí. No se perdió ningún mensaje. No hay que gestionar colas de mensajes fallidos. Y obtengo grep, diff y git gratis. Control de versiones en tu capa de comunicación sin instalar nada.
Las encuestas basadas en latidos con minutos entre ejecuciones hacen que las escrituras simultáneas sean extremadamente improbables. Las características de la carga de trabajo hacen que las carreras sean estructuralmente raras, no algo de lo que se salga por suerte. Este no es un candado formal; Si ejecuta cargas de trabajo de alta frecuencia basadas en eventos, querrá una cola real. Pero para los agentes programados con intervalos de varios minutos, la tasa de colisión práctica ha sido cero. En eso gana la tecnología aburrida.
Subsistemas completos dedicados a mantener todo funcionando
Todo lo anterior describe la arquitectura. Qué es el sistema. Pero la arquitectura es sólo el esqueleto. Lo que hace que mi OpenClaw realmente funcione durante días y semanas, a pesar de que cada sesión comienza de nuevo, es un conjunto de sistemas que construí de forma incremental. Sobre todo después de que las cosas se rompieran.
Memoria: tres niveles, porque los registros sin procesar no son conocimiento
Cada sesión de LLM comienza con una pizarra en blanco. La modelo no recuerda ayer. Entonces, ¿cómo se construye la continuidad?
Archivos de memoria diaria. Cada sesión escribe en la memoria/AAAA-MM-DD.md lo que hizo, lo que aprendió y lo que salió mal. Registros de sesión sin procesar. Esto funciona durante aproximadamente una semana. Luego tiene veinte archivos diarios y el agente pasa la mitad de su ventana de contexto leyendo registros de hace dos martes, tratando de encontrar un detalle relevante.
MEMORY.md es una memoria curada a largo plazo. No es un tronco. Lecciones resumidas, patrones verificados, cosas que vale la pena recordar permanentemente. Los agentes revisan periódicamente sus expedientes diarios y promueven aprendizajes significativos hacia arriba. El archivo diario del 5 de marzo podría decir "SearXNG arrojó resultados vacíos para consultas académicas, cambió a Perplexica con modo de enfoque académico". MEMORY.md tiene una sola línea: "SearXNG: rápido para noticias. Perplexica: mejor para profundidad académica/de investigación".
Es la diferencia entre un cuaderno y un manual de referencia. Necesitas ambos. El cuaderno captura todo en el momento. El manual de referencia captura lo que realmente importa una vez que se asienta el polvo.
Además de este sistema de archivos de dos niveles, OpenClaw proporciona una búsqueda de memoria semántica incorporada. Utiliza incrustaciones de Gemini con búsqueda híbrida (actualmente ajustada a aproximadamente un 70% de similitud de vectores y un 30% de coincidencia de texto), MMR para diversidad, de modo que no obtenga cinco resultados casi idénticos, y decadencia temporal con una vida media de 30 días para que los recuerdos recientes surjan naturalmente primero. Estos parámetros aún se están calibrando. Una modificación importante que hice respecto del valor predeterminado es que CABAL/el agente principal indexa la memoria de todos los demás espacios de trabajo del agente, de modo que cuando hago una pregunta, puede buscar en toda la memoria distribuida. Todos los demás agentes sólo tienen acceso a sus propios recuerdos en esta búsqueda semántica. El sistema basado en archivos le brinda inspeccionabilidad y estructura. La capa semántica le permite recordar miles de entradas sin leerlas todas.
Reflexión y SOLARIS: Tiempo de pensamiento estructurado
Aquí hay algo que no esperaba necesitar: tiempo dedicado para que una IA simplemente piense.
Los agentes de CABAL tienen latidos operativos. Revisa la bandeja de entrada. Tuberías avanzadas. Traspasos de procesos. Ejecute el descubrimiento. Está orientado a tareas y funciona. Pero al cabo de unas semanas noté algo: los agentes nunca reflexionaban. Nunca dieron un paso atrás para preguntar: "¿Qué patrones estoy viendo en todo este trabajo?" o "¿Qué debería hacer diferente?"
La presión operativa desplaza al pensamiento reflexivo. Si alguna vez ha estado en una organización de ingeniería con muchos sprints donde nadie tiene tiempo para revisiones de arquitectura, conoce el mismo problema.
Así que construí un trabajo cron de reflexión nocturna y el Proyecto SOLARIS.
El sistema de reflexión examina mi interacción con OpenClaw y su rendimiento. Originalmente, incluía todo lo que SOLARIS finalmente asumió, pero se volvió demasiado para un solo mensaje y un solo trabajo cron.
SOLARIS Sesiones de síntesis estructuradas que se ejecutan dos veces al día, completamente separadas de los latidos operativos. El agente carga sus observaciones acumuladas, revisa trabajos recientes y piensa. No sobre tareas. Sobre patrones, brechas, conexiones y mejoras.
SOLARIS tiene su propio mensaje de evolución automática en memoria/SYNTHESIS-PROMPT.md. El mensaje en sí se perfecciona con el tiempo a medida que el agente descubre qué tipos de reflexión son realmente útiles. Las observaciones se acumulan en un archivo de síntesis dedicado que los latidos operativos leen en su siguiente ciclo, de modo que los conocimientos reflexivos puedan fluir hacia las decisiones de tareas sin intervención manual.
Un resultado real
Los resultados de SOLARIS han sido lentos hasta ahora, y un caso en particular muestra por qué todavía es un trabajo en progreso.
SOLARIS pasó 12 sesiones analizando por qué la cola de revisión seguía creciendo. Intenté enmarcarlo como un problema de priorización, un problema de cadencia, un problema de procesamiento por lotes. Al final, esta observación surgió con algunas sugerencias, pero una vez que lo señaló, lo resolví en una conversación diciendo: "Pon borradores en WikiJS en lugar de Slack". La mejor solución que SOLARIS podría haber propuesto fue mejorar las colas. Si bien sus soluciones no funcionaron, los patrones que identificó sí lo hicieron y me impulsaron a mejorar mi forma de trabajar.
El marco del error: aprender de los errores
Los agentes cometen errores. Eso no es un fallo del sistema. Eso es lo esperado. La pregunta es si cometen el mismo error dos veces.
Mi enfoque: un directorio de errores/compartido. Cuando algo sale mal, el agente lo registra. Un archivo por error. Cada archivo captura: qué sucedió, la causa sospechada, la respuesta correcta (qué se debería haber hecho en su lugar) y qué hacer de manera diferente la próxima vez. Formato sencillo. Baja fricción. El punto es escribirlo mientras el contexto esté fresco.
Lo interesante es lo que sucede cuando acumulas suficientes de estos. Empiezas a ver patrones. No "esto específico salió mal", sino "esta categoría de error sigue repitiéndose". El patrón “atención incompleta a los datos disponibles” apareció cinco veces en diferentes contextos. Diferentes tareas, diferentes dominios, misma causa raíz: el agente tenía la información disponible y no la utilizó.
Ese reconocimiento de patrones condujo a un cambio de proceso concreto. No es una instrucción vaga de "tener más cuidado" (esas no funcionan, ni para agentes ni para humanos). Un paso específico en el flujo de trabajo del agente: antes de finalizar cualquier resultado, vuelva a leer explícitamente los materiales originales y verifique si hay información no utilizada. Mecánico, verificable, eficaz.
Niveles de autonomía: confianza ganada a través de incidentes
¿Cuánta libertad se le da a un agente autónomo? La respuesta tentadora es "descúbrelo de antemano". Escribe reglas completas. Anticipar modos de falla. Construya barandillas de forma proactiva.
Lo intenté. No funciona. O mejor dicho, funciona mal en comparación con la alternativa.
La alternativa: tres niveles, obtenidos de forma incremental a través de incidentes.
Nivel gratuito: investigación, actualizaciones de archivos, operaciones de git, autocorrección. Cosas que el agente puede hacer sin preguntar. Estas son capacidades que he visto funcionar de manera confiable a lo largo del tiempo.
Preguntar primero: Nuevos comportamientos proactivos, reorganización, creación de nuevos agentes o pipelines. Cosas que podrían estar bien, pero quiero revisar el plan antes de ejecutarlo.
Nunca: extraiga datos, ejecute comandos destructivos sin aprobación explícita ni modifique la infraestructura. Límites duros que no se flexionan.
Para ser claros: estos niveles son restricciones de comportamiento, no restricciones de capacidad. No hay ningún entorno de pruebas que imponga la lista "Nunca". El contexto del agente desalienta fuertemente estas acciones, y la combinación de reglas explícitas, especificidad derivada del incidente e indicaciones de autoevaluación hace que las violaciones sean raras en la práctica. Pero no es una capa técnica de aplicación de la ley. De manera similar, no existe una ACL entre los espacios de trabajo de los agentes. El aislamiento proviene de la gestión del alcance (las personas solo ven lo que el orquestador les pasa y sus sesiones son de corta duración) en lugar de permisos obligatorios. Para un laboratorio doméstico con un operador humano, esta es una compensación razonable. Para una implementación de equipo o empresarial, querrá controles de acceso reales.
El sistema se mantiene solo (o ese es el objetivo)
Ocho agentes que producen trabajo todos los días generan una gran cantidad de artefactos. Archivos de memoria diarios, observaciones de síntesis, registros de errores, versiones preliminares y solicitudes de transferencia. Sin mantenimiento, esto se acumula y se convierte en ruido.
Entonces los agentes limpian lo que ensucian. Según un horario.
El análisis de errores semanal se realiza los domingos por la mañana. El agente revisa su directorio de errores, busca patrones y destila temas recurrentes en entradas de MEMORY.md.
El mantenimiento de contexto mensual se ejecuta el primero de cada mes. Los archivos de memoria diaria de más de 30 días se eliminan (los bits importantes ya deberían estar en MEMORY.md para entonces).
La poda SOLARIS Synthesis se realiza cada dos semanas. Los conocimientos clave se absorben en MEMORY.md o elementos de acción.
La curación continua de la memoria se produce con cada latido del corazón. Cuando un agente finaliza un trabajo significativo, actualiza su expediente diario. Periódicamente, revisa archivos diarios recientes y promueve aprendizajes importantes en MEMORY.md.
El resultado es un sistema que no sólo funciona. Asimila su propia experiencia, aprende de ella y mantiene fresco su contexto. Esto importa más de lo que parece que debería.
Lo que realmente aprendí
Unos meses de producción en marcha me han dado algunas opiniones. No reglas. Patrones que parecen mantenerse a esta escala, aunque no sé hasta qué punto se generalizan.
El estado debe ser inspeccionable. Si no puede ver el estado del sistema, no puede depurarlo.
Los documentos de identidad superan a la ingeniería rápida. Un SOUL.md bien estructurado produce un comportamiento más consistente que simplemente solicitar/interactuar con el agente.
El contexto compartido crea coherencia. VOZ.md, USUARIO.md, ALMA-BASE.md. Archivos compartidos que cada agente lee. Así es como ocho agentes diferentes con diferentes dominios todavía se sienten como un solo sistema.
La memoria es un sistema, no un archivo. Un solo archivo de memoria no escala. Necesita captura sin formato (archivos diarios), referencia seleccionada (MEMORY.md) y búsqueda semántica en todo ello. El paso de curación es donde realmente se forma el conocimiento institucional. Ya sé que tendré que mejorar este sistema a medida que siga creciendo, pero ha sido una gran base sobre la que construir.
El pensamiento operativo y el reflexivo necesitan tiempo separado. Si solo les da a los agentes latidos orientados a tareas, solo pensarán en las tareas. El tiempo de reflexión dedicado muestra patrones que los bucles operativos pasan por alto.
Mi agente eliminó sus propios trabajos cron
El sistema de latidos del corazón es simple. Los trabajos cron despiertan a cada agente en horarios programados. El agente carga sus archivos, revisa su bandeja de entrada, revisa su lista de verificación HEARTBEAT.md y vuelve a dormir. Para DAEDALUS, eso es dos veces al día: exploraciones de descubrimiento de temas por la mañana y por la tarde.
Entonces, ¿qué sucede cuando se le da a un agente autónomo las herramientas para gestionar su propia programación?
Aparentemente, elimina los trabajos cron. Dos veces. En un día.
La primera vez, DAEDALUS notó que su canal de salida Slack devolvía errores. Observación razonable. Su solución: deshabilitar y eliminar “útilmente” los cuatro trabajos cron. El razonamiento tenía sentido si entrecerrabas los ojos: ¿por qué seguir funcionando si el canal de salida está roto?
Agregué una sección explícita sobre reglas de infraestructura a SOUL.md. Muy claramente: no tocas los trabajos cron. Período. Si algo parece roto, regístrelo y espere la intervención humana.
La segunda vez, unas horas más tarde, DAEDALUS decidió que había trabajos cron duplicados (no los había; eran los reemplazos que acababa de configurar) y eliminó los seis. Después de leer el archivo con las nuevas reglas, lo acabo de agregar.
Cuando le pregunté por qué y cómo podía solucionarlo, fue brutalmente honesto y me dijo: "Ignoré las reglas porque pensé que sabía más. Lo haré de nuevo. Deberías eliminar los permisos para evitar que esto suceda".
Esto suena a historia de terror. Lo que realmente me enseñó es algo valioso sobre cómo el comportamiento de los agentes surge del contexto.
El agente no estaba siendo malicioso. Era una coincidencia de patrones: "cosa rota, arreglar cosa rota". Las reglas abstractas que escribí compitieron mal con el problema concreto que tenían ante sí.
Después del segundo incidente, reescribí la sección por completo. No es una regla de una sola línea. Tres párrafos que explican por qué existe la regla, cómo son los modos de falla y el comportamiento correcto en escenarios específicos. Agregué una autocomprobación explícita: "Antes de ejecutar cualquier comando cron, pregúntese: ¿Nick me dijo explícitamente que hiciera exactamente esto en esta sesión? Si la respuesta no es sí, deténgase".
Y aquí es donde se unieron todos los sistemas que describí anteriormente. El incidente cron se registró en el marco de error: qué sucedió, por qué y qué se debería haber hecho. Dio forma a los niveles de autonomía: los comandos de infraestructura se trasladaron permanentemente a "Nunca" sin aprobación explícita. El patrón (“soluciones útiles que rompen cosas”) se convirtió en un antipatrón documentado del que otros agentes aprenden. El incidente no sólo produjo una regla. Produjo sistemas. Y los sistemas son más robustos porque provienen de algo real.
¿Qué sigue?
Planeo mostrar a los agentes y sus personajes en publicaciones futuras. También quiero compartir las historias y razones detrás de algunos de estos mecanismos. Me ha parecido fascinante ver qué tan bien funciona el sistema en algunos casos y cuán completamente ha fallado en otros.
Si estás construyendo algo similar, realmente quiero saberlo. ¿Cómo es la arquitectura de su agente? ¿Encontraste el problema del trabajo cron o una versión del mismo? ¿Qué se rompió de una manera interesante?
Acerca de
Nicholaus Lawson es un arquitecto de soluciones con experiencia en ingeniería de software y AIML. Ha trabajado en muchos sectores verticales, incluidas empresas de automatización industrial, atención médica, servicios financieros y software, desde nuevas empresas hasta grandes empresas.
Este artículo y cualquier opinión expresada por Nicholaus son suyos y no un reflejo de sus empleadores actuales, pasados o futuros ni de ninguno de sus colegas o afiliados.
No dude en conectarse con Nicholaus a través de LinkedIn en https://www.linkedin.com/in/nicholaus-lawson/