Qué hace realmente mi pila agéntica

Mi pila de agentes es la forma en que hago comida para perros Neotoma. También es mi sistema operativo personal. Un monorepo privado donde los agentes de IA manejan todo, desde la clasificación del correo electrónico hasta los pagos de Bitcoin y la implementación de sitios web, con Neotoma como la memoria estructurada debajo.

Cada característica que envío en Neotoma se valida aquí primero, principalmente en Cursor y secundariamente a través de agentes terminales como Claude Code, Codex y Cursor CLI. Cada vacío que encuentro en la memoria del agente aparece aquí primero. La pila es cómo llevo mi vida diaria y mi trabajo. La fricción que encuentro, además de los comentarios de los usuarios, es lo que impulsa la hoja de ruta de Neotoma.

Tengo la intención de abrir la pila. Pero el repositorio ha acumulado meses de datos personales, scripts codificados en mis cuentas y configuraciones vinculadas a mi configuración. Antes de que pueda hacerse público, necesito insertar esos datos completamente en Neotoma y refactorizar las herramientas para que sean genéricas. Ese trabajo está en curso.

Esta publicación explica qué es la pila, cómo la uso y qué revela sobre lo que debe hacer la memoria estructurada del agente.

¿Qué es la pila?

La pila es un monorepo con más de una docena de servidores MCP. Monedero Bitcoin, Instagram, Asana, HomeKit, DNSimple, Google Search Console, 1Password, un web scraper y más. Algunos son servidores MCP a los que los agentes llaman como herramientas. Otros son CLI que los agentes invocan desde la terminal. Ambos ofrecen a los agentes lo mismo: acceder a servicios externos.

Encima de los servidores MCP se encuentran reglas y habilidades. Las reglas son instrucciones de comportamiento persistentes que se encuentran en el repositorio, no en Neotoma: almacene siempre los contactos en Neotoma antes de responder, nunca revele secretos, use mayúsculas y minúsculas en los títulos, ejecute pruebas después de los cambios de código, prefiera CLI al panel para registros y configuraciones, vincule la primera mención de nombres de productos. Las habilidades son flujos de trabajo de varios pasos: clasificar mi bandeja de entrada, redactar una publicación de blog, implementar un sitio web, procesar comentarios sobre productos, extraer un pedido de Amazon del correo electrónico, pagar a un contratista en Bitcoin.

Y debajo de todo se encuentra Neotoma como la capa de memoria estructurada. Cada agente lee y escribe en él. Eso es lo que hace que la pila se acumule con el tiempo en lugar de restablecerse en cada sesión.

Cómo trabajo con él

Vivo en Cursor. Mi día es una secuencia de sesiones de agentes. Abro un nuevo agente, describo lo que quiero que se haga y el agente se ejecuta utilizando los servidores, las reglas y las habilidades de MCP en el espacio de trabajo. Algunas sesiones son rápidas: "responder a este correo electrónico". Algunos son largos: "clasifica mi bandeja de entrada, procesa los últimos comentarios de los evaluadores y luego redacta una publicación comparativa sobre el agente de memoria de Google".

Es coworking con agentes. Me siento en mi escritorio y trabajo junto a ellos todo el día. Tareas personales: programar una reparación, pagar a un contratista, gestionar eventos del calendario. Profesionales: escribir publicaciones, procesar comentarios, implementar sitios web, administrar dominios. Los agentes se encargan de la ejecución. Proporciono dirección, reviso los resultados y apruebo acciones que necesitan un ser humano al tanto.

Cada sesión de agente tiene el contexto completo del espacio de trabajo: cada servidor MCP, cada regla, cada habilidad. El agente puede leer mi Gmail, consultar mi calendario, consultar a Neotoma para conocer el contexto anterior, almacenar nuevos datos, generar imágenes, enviar código y verificar implementaciones. Mi función es cada vez más describir la intención y revisar los resultados.

Cómo encaja Neotoma

Sin memoria estructurada, cada sesión de agente comienza desde cero. El agente no sabe quiénes son tus contactos, qué tareas tienes abiertas, qué comentaste ayer o qué le pagaste ya a alguien. Puede pegar contexto en cada mensaje, pero eso no pasa de unas pocas sesiones. Memoria de plataforma almacena tu vibra, no tu trabajo. RAG ayuda con el código, pero no con los hechos estructurados que impulsan los flujos de trabajo: a quién le debes dinero, qué comentarios recibiste la semana pasada, qué tareas aún están abiertas.

Mi instancia de Neotoma almacena más de 1000 contactos, 600 tareas, 140 conversaciones, 120 publicaciones de blog y 170 tipos de entidades que los agentes crearon cuando encontraron nuevos tipos de información: transacciones, reglas vigentes, notas de comentarios, eventos de calendario, disputas, facturas, habilidades, resultados de implementación. Cuando un agente inicia una nueva sesión, recupera lo que necesita. Cuando termina, almacena lo aprendido.

Aquí están los 20 tipos de entidades principales en mi instancia de Neotoma de hoy, con un ejemplo de cada una:

Ninguno de estos esquemas fue diseñado por adelantado. Los agentes crean y amplían esquemas según sea necesario a medida que encuentran nuevos tipos de información. El sistema ahora tiene 170 tipos de entidades en total, la mayoría con solo un puñado de registros. La cola larga es donde la memoria del agente se vuelve interesante: una única entidad de disputa con su historial de negociación completo, un único compromiso de hacer un seguimiento con alguien si cambia la estrategia, una única preferencia sobre cómo manejar un pago específico.

La diferencia práctica es que los agentes se basan en trabajos previos. Cuando le pido a un agente que envíe un correo electrónico a alguien, primero busca el contacto en Neotoma. Cuando le pido que procese comentarios, recupera entidades de comentarios existentes y vincula otras nuevas. Cuando le pido que le pague a un contratista en Bitcoin, conoce la regla vigente (siempre pague a esta persona en BTC) e incluye el enlace de la transacción en la confirmación porque otra regla vigente así lo indica.

Almacenamiento y recuperación de cerca

Neotoma MCP expone herramientas a las que los agentes llaman directamente. Así es como se ve en la práctica el almacenamiento y la recuperación reales.

Cuando un agente necesita persistir en un turno de conversación con entidades extraídas, llama a "store" con una única carga útil:

tienda({
  "entidades": [
    {
      "entity_type": "conversación",
      "title": "Clasificación de correos electrónicos el 9 de marzo"
    },
    {
      "entity_type": "agente_message",
      "rol": "usuario",
      "content": "clasificar mi bandeja de entrada",
      "llave en mano": "conv-42:1"
    },
    {
      "entity_type": "contacto",
      "full_name": "Alex Chen",
      "correo electrónico": "alex@ejemplo.com",
      "fuente": "llamada de comentarios del probador"
    },
    {
      "tipo_entidad": "tarea",
      "title": "Seguimiento de los comentarios de Alex",
      "estado": "pendiente",
      "prioridad": "media"
    }
  ],
  "relaciones": [
    {
      "relationship_type": "PARTE_DE",
      "índice_fuente": 1,
      "índice_destino": 0
    },
    {
      "relationship_type": "REFERS_TO",
      "índice_fuente": 1,
      "índice_destino": 2
    },
    {
      "relationship_type": "REFERS_TO",
      "índice_fuente": 1,
      "índice_destino": 3
    }
  ],
  "idempotency_key": "conv-42-turno-1-triage"
})

Una llamada almacena la conversación, el mensaje, un nuevo contacto y una tarea, todos vinculados por relaciones escritas. El agente no necesitaba una definición de esquema para "contacto" o "tarea" de antemano. Neotoma acepta campos arbitrarios e infiere estructura.

Cuando un agente necesita contexto antes de responder, consulta por identificador:

recuperar_entidad_por_identificador({
  "identificador": "Alex Chen"
})

Esto devuelve el registro de contacto con correo electrónico, conversaciones anteriores y la procedencia de cada campo. Si el agente necesita un contexto más amplio, consulta por tipo:

recuperar_entidades({
  "entity_type": "feedback_note",
  "buscar": "versión del desarrollador",
  "límite": 10
})

Esto devuelve las diez notas de comentarios más relevantes sobre la versión del desarrollador, cada una con su instantánea completa y su historial de observaciones.

Para las reglas permanentes, el agente las recupera una vez al inicio de un flujo de trabajo:

recuperar_entidades({
  "entity_type": "regla_permanente"
})

Mi instancia devuelve reglas como "pagar siempre a Carlos en Bitcoin" y "proporcionar mensajes redactados en bloques de rebajas". El agente los aplica automáticamente durante el resto de la sesión.

Cuando los flujos de trabajo tocan archivos (recibos, capturas de pantalla, documentos), el agente los almacena junto con entidades en la misma llamada usando file_path:

tienda({
  "entidades": [
    {
      "tipo_entidad": "transacción",
      "proveedor": "Amazon",
      "monto": 47,99,
      "moneda": "EUR"
    }
  ],
  "file_path": "/ruta/al/recibo.pdf",
  "idempotency_key": "amazon-order-marzo-9"
})

La ruta de almacenamiento no estructurada de Neotoma maneja el archivo desde allí. Los bytes sin formato tienen dirección de contenido (SHA-256), por lo que el mismo archivo nunca se almacena dos veces. El agente pasa el archivo tal como está a través de file_path (entornos locales como Cursor) o file_content (base64, para entornos basados ​​en web); no interpreta ni extrae datos antes de almacenarlos. De forma predeterminada, Neotoma ejecuta automáticamente la interpretación de IA en el archivo almacenado, extrayendo entidades estructuradas y vinculándolas a la fuente con una relación EMBEDS. Volver a almacenar el mismo archivo con interpret: true activa la reinterpretación sin crear un duplicado. El recibo se convierte en datos estructurados consultables y se conserva el PDF original para determinar su procedencia. La interpretación también se puede diferir ("interpretar: falso") para el procesamiento por lotes o la gestión de cuotas y luego ejecutarse más tarde con una configuración diferente.

Flujos de trabajo en la práctica

Algunos flujos de trabajo muestran el patrón.

Triaje de correo electrónico. El agente lee correos electrónicos no leídos a través de Gmail MCP, verifica en Neotoma los registros de contactos existentes y el contexto anterior con cada remitente, redacta respuestas usando mis reglas de estilo de comunicación, almacena nuevos contactos y tareas, y archiva mensajes procesados. Una sola ejecución de clasificación puede almacenar cinco contactos nuevos, tres tareas y una docena de turnos de conversación.

Redacción de publicaciones de blog. La habilidad en sí vive en Neotoma como una entidad estructurada. El agente lo recupera con retrieve_entity_snapshot. Luego consulta las publicaciones existentes para calibrar el estilo, escribe el borrador, almacena la entidad de la publicación con todos los metadatos, genera imágenes destacadas, crea una copia compartida para Twitter y LinkedIn, regenera el caché del sitio web a partir de la exportación de Neotoma y lo implementa. Esta publicación fue escrita de esa manera.

Pagos en Bitcoin. Le pago a un contratista en Bitcoin usando un servidor MCP de billetera BTC. Neotoma almacena la regla vigente, el registro de contacto y el historial de transacciones. El agente recupera los tres, ejecuta el pago, almacena la nueva transacción con el enlace de la cadena y confirma.

Procesamiento de comentarios. Cuando los evaluadores brindan comentarios sobre la versión del desarrollador de Neotoma, los agentes extraen entidades de comentarios estructurados, las vinculan al registro de contacto del evaluador, clasifican los comentarios por categoría y los evalúan según las restricciones de la etapa de lanzamiento. Los comentarios anteriores se pueden recuperar por evaluador, por grupo o por fecha.

Implementación del sitio web. La habilidad de implementación sincroniza las ediciones de rebajas locales con Neotoma, exporta el conjunto de datos completo del sitio web, regenera el caché, envía el repositorio del sitio web y monitorea las Acciones de GitHub hasta que la compilación se realice correctamente. Si la compilación falla, el agente lee los registros, soluciona el problema y vuelve a ejecutar.

Hacia agentes que corren sin mí

Cada flujo de trabajo comienza cuando abro un agente de Cursor y escribo una instrucción. Estoy al tanto de cada tarea. Eso está bien para la etapa actual, pero no es el estado final.

Estoy configurando procesos automatizados para que los agentes puedan manejar los flujos de trabajo sin mi participación directa. Las piezas ya están ahí: las habilidades definen los pasos completos del flujo de trabajo, Neotoma almacena el contexto y las reglas, los servidores MCP proporcionan el alcance. Lo que falta es la orquestación que activa los flujos de trabajo según lo programado o en respuesta a eventos, y una interfaz de aprobación liviana para que pueda revisar y autorizar acciones sin tener que sentarme frente a mi computadora portátil.

La arquitectura en capas de Neotoma está diseñada exactamente para esto. Separa tres preocupaciones:

1. Capa de verdad (Neotoma). Determinista, impulsada por reductores y basada en eventos. Todos los agentes leen de él. Las actualizaciones de estado fluyen únicamente a través de eventos de dominio procesados ​​por reductores. Ningún agente muta la verdad directamente.
2. Capa de estrategia. Lee el estado mundial actual de Neotoma. Evalúa prioridades, limitaciones, riesgos, compromisos y tiempo. Emite decisiones y comandos. Cognición pura: estado dentro, decisiones fuera. Sin efectos secundarios.
3. Capa de ejecución. Toma comandos de la capa de estrategia. Realiza efectos secundarios a través de adaptadores externos (API de correo electrónico, servicios de pago, calendario, mensajería). Emite eventos de dominio que describen lo sucedido. Esos eventos regresan a través de los reductores para actualizar el estado. Efecto puro: comandos que entran, eventos que salen.

El circuito está cerrado:

Señales entrantes (correo electrónico, WhatsApp, calendario, datos financieros)
  -> Normalización -> Estado de neotoma (registro de eventos + reductores)
  -> Marca de estrategia (evaluar prioridades, decisiones de salida)
  -> Agentes de ejecución (realizan efectos secundarios, emiten eventos)
  -> Reductores -> Estado actualizado
  -> Siguiente marca

Hoy soy la capa estratégica. Miro el estado, decido qué hacer y le digo a un agente que ejecute. La arquitectura hace que esa función sea reemplazable por software. Un motor de estrategia lee Neotoma, evalúa lo que necesita atención en función de reglas y prioridades vigentes y emite comandos a los agentes de ejecución. Esos agentes llaman a los servidores MCP, almacenan los resultados y el ciclo se repite.

La invariante crítica es que ninguna capa escribe directamente en el almacén de datos subyacente de Neotoma. Las actualizaciones solo fluyen a través de reductores y eventos de dominio. Eso hace que el sistema sea auditable y reversible. Si un agente autónomo toma una mala decisión, puedo rastrear el evento que la causó, revertir la actualización del estado y corregir la regla que la provocó.

El objetivo es reducir mi tiempo diario frente al ordenador. No eliminarlo. Pase de la ejecución práctica a la revisión y aprobación. Quiero despertarme con un resumen de lo que mis agentes manejaron durante la noche: correos electrónicos clasificados, publicaciones redactadas, implementaciones verificadas, pagos en cola. Quiero aprobar un pago de Bitcoin desde mi Apple Watch. Quiero revisar un correo electrónico borrador en mi teléfono mientras camino y tocar para enviar. Los agentes manejan el 80% que es repetible. Yo manejo el 20% que necesita juicio.

Aquí es donde la cuestión del hardware se vuelve interesante. Los teléfonos y relojes actuales no están diseñados para este patrón de interacción. Necesita un dispositivo optimizado para gestos breves de revisión y aprobación, no para escribir o navegar.

De los dispositivos que existen hoy en día, el Apple Watch se siente más cercano al factor de forma correcto: siempre en su muñeca, visible, capaz de interacciones simples de tocar para aprobar. Pero la capa de software aún no ha llegado a ese punto. No hay forma de canalizar resúmenes de agentes y solicitudes de aprobación al reloj de una manera que parezca nativa.

Esa podría ser un área con la que podría experimentar en algún momento, creando una aplicación complementaria liviana que conecte el estado de Neotoma con una interfaz a nivel de muñeca. Ya sea que la superficie adecuada termine siendo una aplicación de reloj, un dispositivo de inteligencia artificial dedicado o algo que aún no existe, el modelo de interacción es claro: los agentes hacen el trabajo, la memoria estructurada mantiene el estado y el ser humano proporciona dirección al ritmo de la intención en lugar del ritmo de ejecución.

Abrir la pila

La pila es privada hoy porque contiene mi vida: contactos, finanzas, datos de salud, comunicaciones personales, reglas vigentes sobre cómo administro mi hogar. Antes de poder abrirlo, necesito desenredar todo eso.

El camino es sencillo. Los datos personales pasan de lleno a Neotoma, que ya es la fuente de verdad de la mayor parte de ellos. Los scripts que hacen referencia a mis cuentas y rutas específicas se refactorizan para leer desde la configuración. Los contenedores del servidor MCP se vuelven genéricos. Las habilidades pierden sus supuestos codificados.

Lo que queda es una pila agente reutilizable: una plantilla monorepo con andamiaje de servidor MCP, un marco de reglas y habilidades, integración de Neotoma para memoria estructurada y flujos de trabajo de ejemplo que cualquiera puede adaptar. La arquitectura es la parte interesante. Mis datos personales no.

No tengo un cronograma para esto. La refactorización ocurre junto con el uso diario. Cada vez que toco un guión, lo hago más genérico. Cada vez que muevo datos a Neotoma, los elimino del repositorio. La pila se vuelve más portátil con cada sesión.

Lo que esto prueba sobre Neotoma

Construí esta pila antes de que existiera Neotoma. La primera versión usaba archivos planos y tablas Parquet. Funcionó hasta que dejó de hacerlo.

Los modos de falla eran específicos: un agente almacenaría un contacto como "Sarah Kim" en una sesión y "S. Kim" en otra, creando duplicados sin forma de fusionarlos. No había procedencia, por lo que no podía decir qué agente escribió un campo ni cuándo.

Las consultas se limitaron a coincidencias exactas en columnas individuales, por lo que preguntar "¿qué comentarios recibí la semana pasada?" significaba escanear cada archivo manualmente. En ocasiones, los registros se sobrescribían mal o se eliminaban por completo, sin ningún registro de eventos del que recuperarse. Y nada vinculado entre tipos, por lo que saber que una tarea relacionada con un contacto relacionado con una transacción me obligaba a mantener ese gráfico en mi cabeza.

Neotoma reemplazó esa capa. Les dio a los agentes una memoria estructurada, consultable y consciente de las relaciones que funciona en todos los flujos de trabajo. La pila ahora tiene 170 tipos de entidades en Neotoma, no porque haya diseñado 170 esquemas por adelantado, sino porque los agentes crean tipos de entidades a medida que encuentran nuevos tipos de información. Una nota de retroalimentación es diferente de una transacción y de una regla permanente, y el sistema las maneja todas.

Este es el dogfooding que mantiene a Neotoma honesto. Cuando la recuperación es lenta, lo siento en cada sesión del agente. Cuando falla la resolución de la entidad, obtengo contactos duplicados. Cuando el almacenamiento no es confiable, los flujos de trabajo se interrumpen. Cada error y cada brecha aparece en mi trabajo diario antes que en el de cualquier otra persona.

El problema de la memoria es universal. Todos los desarrolladores que creen flujos de trabajo agentes se toparán con el mismo muro: agentes que no pueden recordar, no pueden consultar y no pueden desarrollar trabajos anteriores. La recuperación por sí sola no es suficiente; la estructura y la procedencia son las que hacen que la memoria sea confiable. Esta pila es una prueba de que la memoria estructurada cambia lo que los agentes pueden hacer. Neotoma es la forma en que lo pongo a disposición de todos.

La versión para desarrolladores está abierta para pruebas. Si está creando flujos de trabajo agentes y desea una memoria estructurada debajo, ahí es por donde comenzar.