Modelos externos como agentes, la memoria de SynaBun como bus

Claude Code ya tiene agentes. Puedes lanzar subagentes dentro de una sesión. Investigan, ejecutan comandos, leen archivos y te informan. Funciona.

Pero todos esos agentes son Claude.

El mismo modelo. La misma suscripción. El mismo presupuesto de contexto. Cada agente que lanzas consume de la misma reserva de tokens. Si necesitas cinco agentes investigando cinco partes distintas de una base de código, son cinco consumos en paralelo sobre el mismo plan de Claude. En sesiones intensas, eso se acumula rápido.

¿Y si los agentes no tuvieran que ser Claude?

La idea

Usa Claude Code como orquestador. El cerebro que planifica, delega y sintetiza. Pero deja que lance agentes que se ejecutan en modelos externos: Codex, Gemini, modelos locales de Ollama, lo que esté disponible y salga barato para la tarea.

Esos agentes no necesitan ser brillantes. Necesitan ser minuciosos. Recorre este directorio. Lee estos archivos. Busca este patrón. Resume este módulo. Encuentra cada lugar donde se llama a esta función. Es trabajo pesado y rutinario. No requiere el modelo más caro que tengas a mano.

Lo decisivo es cómo vuelven los hallazgos.

En lugar de pasar texto en bruto por una comunicación frágil entre modelos, cada agente guarda sus hallazgos directamente en la memoria de SynaBun con la herramienta remember. Recibe a cambio un ID de memoria. Ese ID es lo único que le envía a Claude.

La fase de planificación de Claude no necesita interpretar la salida de otro modelo. Llama a recall con los ID, obtiene hallazgos estructurados del sistema de memoria y arma su plan a partir de un contexto indexado, consultable y persistente.

El sistema de memoria se convierte en el bus.

Por qué funciona esta arquitectura

El problema habitual de los workflows multimodelo es el traspaso. El modelo A produce una salida. Tienes que hacer llegar esa salida al modelo B. Así que pasas texto, analizas JSON, construyes API wrapper o lo metes todo en un archivo compartido. Cada enfoque es frágil a su manera.

La memoria de SynaBun esquiva ese problema porque ya está diseñada para ser la capa de contexto compartido entre distintas sesiones de IA.

Cuando un agente externo llama a remember, no se limita a volcar texto. Crea una entrada de memoria categorizada, etiquetada, clasificada por importancia y con búsqueda semántica, con un UUID estable. Esa entrada vive en el almacén vectorial de SynaBun. Sobrevive a la sesión. Se puede recuperar por contenido, por etiqueta, por proyecto, por categoría. No es un artefacto temporal. Es conocimiento indexado.

Así que el traspaso queda así:

1. Claude identifica lo que necesita investigar
2. Claude lanza un agente externo (Codex, Gemini, un modelo local) con una tarea clara
3. El agente hace su trabajo con las herramientas a las que tenga acceso
4. El agente llama a remember con sus hallazgos: contenido estructurado, etiquetas relevantes, archivos relacionados y el nivel de importancia adecuado
5. El agente le devuelve el ID de memoria a Claude
6. Claude llama a recall o lee la memoria directamente por su ID
7. La fase de planificación de Claude usa hallazgos reales e indexados en lugar de volcados en bruto

Sin análisis intermedio. Sin negociar formatos de texto. Sin un «aquí tienes mi salida como una cadena gigante, suerte». Solo un UUID que apunta a memoria estructurada.

Qué necesita el agente externo

No mucho. De eso se trata.

El agente externo necesita acceso al servidor MCP de SynaBun. En concreto, necesita la herramienta remember. Si además tiene recall, puede comprobar qué encontraron los agentes anteriores antes de duplicar trabajo. Pero el conjunto mínimo de herramientas necesario es solo remember.

El agente no necesita entender todas las herramientas disponibles en SynaBun. No necesita el navegador, el whiteboard, el sistema de loop ni las herramientas de Discord. Necesita hacer su tarea de investigación y guardar el resultado en una sola llamada estructurada.

Eso hace que la integración sea ligera. Puede participar cualquier modelo capaz de usar herramientas MCP, o cualquier wrapper que traduzca llamadas a herramientas a MCP.

Codex ya es compatible con MCP. Los modelos locales ya se conectan al MCP de SynaBun a través de OpenCode. La infraestructura ya existe.

Qué recibe Claude

Esta es la parte que cambia la fase de planificación.

Hoy, cuando Claude Code lanza un subagente, toda la salida del agente vuelve a la conversación como un bloque de texto. Claude tiene que analizarlo, extraer lo útil y mantenerlo todo en contexto mientras planifica. Si lanzas cinco agentes, recibes cinco bloques que compiten por el espacio de la ventana de contexto.

Con agentes indexados en memoria, Claude recibe cinco UUID. Diminutos. Baratos. Sin presión sobre el contexto.

Cuando Claude entra en la fase de planificación, trae exactamente lo que necesita:

• recall con un ID de memoria concreto para obtener todos los hallazgos de un agente
• recall con una consulta semántica para buscar en los hallazgos de todos los agentes
• recall con un filtro de etiqueta para obtener los hallazgos sobre un subsistema concreto
• recall con un filtro de proyecto para obtener todo lo relevante para el trabajo actual

El agente que planifica no se ahoga en salida en bruto. Consulta una base de conocimiento indexada que construyeron en paralelo modelos más baratos dedicados a una investigación acotada.

Es una forma de planificar radicalmente distinta.

Los números

No se trata solo de elegancia arquitectónica. Se trata de costo.

Claude Opus es caro. Vale la pena para la planificación, la síntesis, el razonamiento arquitectónico y las decisiones finales de implementación. Y se podría decir que es excesivo para «lee todos los archivos de este directorio y dime qué exporta cada uno».

Si puedes delegar la investigación y la indexación en modelos más baratos (Codex para entender el código, modelos locales para recorrer archivos, modelos en la nube más ligeros para la búsqueda de patrones) y enviarle a Claude solo los hallazgos estructurados para la costosa fase de planificación, el costo por sesión cambia de forma notable.

Pagas precios de Opus por trabajo de nivel Opus: síntesis, criterio, planificación. Pagas precios básicos por trabajo básico: leer, recorrer, resumir, catalogar.

El sistema de memoria es la capa que hace posible esta división sin perder coherencia.

Cómo se ve en la práctica

Imagina que vas a empezar una refactorización grande. Necesitas entender el estado actual de cinco subsistemas antes de poder planificar los cambios.

Sin este patrón: Claude lee los cinco subsistemas uno tras otro, gasta tokens caros en leer archivos y resumirlos, comprime el contexto sobre la marcha y puede perder detalles del primer subsistema cuando termina el quinto.

Con este patrón:

1. Claude examina la tarea e identifica cinco preguntas de investigación
2. Claude lanza cinco agentes: por ejemplo, Codex para los módulos del backend, un modelo local para los archivos de configuración y Gemini para la API pública
3. Cada agente investiga su subsistema y llama a remember con hallazgos estructurados (qué hace el módulo, sus dependencias, su API pública, los problemas conocidos, los patrones relevantes)
4. Cada agente devuelve un ID de memoria
5. Claude entra a la planificación con cinco IDs de memoria
6. Claude ejecuta recall sobre cada uno, obtiene hallazgos limpios y estructurados, y arma un plan de refactorización a partir de un contexto completo e indexado

La investigación se hizo en paralelo con modelos más baratos. La planificación se hace en Claude, con acceso total a resultados indexados y consultables. Sin desbordar el contexto. Sin detalles perdidos. Sin releer archivos que Claude ya pagó por escanear.

Lo que todavía falta

Esto todavía no existe como una función lista para usar. Las piezas están en su lugar, pero falta construir la capa de orquestación.

Lo que falta hoy:

• Claude Code no lanza de forma nativa agentes que no sean Claude. Hoy el sistema de subagentes es exclusivo de Claude. Lanzar un modelo externo como agente requiere un wrapper, un webhook o un orquestador externo que Claude pueda activar.
• La calidad en el uso de herramientas varía. No todos los modelos llaman a las herramientas MCP con limpieza. Codex es sólido. Los modelos locales a través de OpenCode están mejorando. Pero a algunos modelos todavía les cuestan las llamadas estructuradas a herramientas, así que la llamada a remember puede necesitar salvaguardas o lógica de reintentos.
• La calidad de la memoria depende del agente. Un modelo más barato puede guardar hallazgos incompletos o mal estructurados. La memoria es tan buena como lo que escribe el agente. Probablemente haga falta un paso de validación o un contrato de esquema que defina qué es un «buen hallazgo».
• El costo de coordinar. Decidir qué agente recibe qué tarea, y con qué modelo, es en sí un problema de planificación. Dividir de más es peor que usar Claude de forma secuencial si el costo de coordinación supera el ahorro.

Nada de esto es un bloqueo. Son problemas de ingeniería bien delimitados.

Hacia dónde va esto

La dirección está clara, aunque la implementación completa no llegue mañana.

SynaBun ya es la capa de memoria compartida entre Claude Code, Codex, OpenCode y los modelos locales. Las herramientas remember y recall ya funcionan en todos ellos. El sistema de categorías, las etiquetas, la clasificación por importancia, la búsqueda semántica y el alcance por proyecto ya están construidos.

La pieza que falta es la orquestación: que Claude Code pueda decir «ejecuta esta tarea en Codex, dale la conexión MCP de SynaBun y tráeme el ID de la memoria». Eso es una función, no un problema de investigación.

Cuando exista esa orquestación, cambia la economía del desarrollo asistido por IA. Dejas de pagar precios premium por investigación en volumen. Empiezas a pagarlos solo por el trabajo que de verdad necesita razonamiento premium.

Y el sistema de memoria deja de ser solo una capa de persistencia. Se convierte en el protocolo de comunicación entre modelos.

La mejor forma de usar un modelo caro no es ponerlo a hacer todo. Es convertirlo en el cerebro que dirige a modelos más baratos y sintetiza su trabajo.

La memoria de SynaBun es la capa que hace limpio ese traspaso: estructurada, indexada, consultable y persistente. No es una tubería. No es un volcado de archivos. Es una base de conocimiento compartida en la que cualquier agente puede escribir y que el agente planificador puede consultar.

Modelos externos como agentes de investigación. La memoria de SynaBun como bus. Claude como arquitecto.

Ese es el desarrollo multimodelo que queremos construir.