05 — IA y Sistemas Multiagente
Una infraestructura multiagente en funcionamiento
La infraestructura que hace posible el resto del trabajo.
Un sistema de operaciones multiagente, bidireccional y construido a medida, corre de forma continua en hardware dedicado. Fue diseñado y construido desde cero — no ensamblado a partir de frameworks de código abierto.
Este es el centro de gravedad del trabajo actual. Todo lo demás en este sitio se entrega a través de él o se coordina por él.
Una infraestructura de operaciones multiagente corre de forma continua en un servidor dedicado. Es bidireccional y siempre activa: los agentes mantienen memoria persistente y un runtime persistente, de modo que no arrancan en frío cada vez que recurro a ellos. El sistema fue diseñado y construido desde cero — no ensamblado a partir de frameworks de agentes de código abierto — porque los requisitos eran específicos y la coordinación tenía que ser mía y controlable de principio a fin.
Hay clases de agentes distintas, cada una con un rol definido. Un cerebro de orquestación central interpreta la intención y enruta el trabajo. Los embajadores traducen esa intención al protocolo propio de cada proveedor y sistema. Los auditores verifican lo que otros agentes producen. Los mensajeros mueven la información entre capas sin pérdida. Los investigadores reúnen contexto y lo devuelven. Los ejecutores senior hacen trabajo de plena capacidad, hasta dieciséis a la vez; por debajo de ellos, subagentes más acotados se despliegan en abanico — más de trescientos en paralelo cuando la carga lo exige.
Comando la flota desde varias superficies. Desde la estación de trabajo a través de VSCode y la CLI de Linux; desde dispositivos móviles en tiempo real; sobre conexiones bidireccionales a nivel de socket que se mantienen abiertas en lugar de hacer polling; y mediante llamadas de voz en tiempo real con instancias en ejecución. El sentido de la amplitud no es la novedad — es que la misma infraestructura es alcanzable desde dondequiera que esté el trabajo.
instancias ejecutoras senior, de plena capacidad, corriendo en simultáneo
subagentes más acotados en paralelo cuando la carga lo exige
proveedores de LLM orquestados a la vez — Anthropic, OpenAI, Google, xAI, Moonshot
siempre activo, en hardware dedicado, con memoria y runtime persistentes
Las cifras a las que realmente corre.
Infraestructura / estado estable
- Instancias ejecutoras senior
- hasta 16 en simultáneo
- Subagentes
- 300+ en paralelo
- Proveedores de LLM
- 5, orquestados de forma simultánea
- Transporte
- a nivel de socket, bidireccional, baja latencia
- Superficies de comando
- estación de trabajo · móvil · voz
- Host de runtime
- servidor Dell dedicado, siempre activo
- Estado operativo
- persistente — los agentes nunca arrancan en frío
- Agente a agente
- mediado por protocolo, auditado
- Interfaces de contexto
- function calling · MCP · RAG
- Origen
- construido desde cero — no un ensamblaje de frameworks
Un cerebro, varias clases, muchos trabajadores.
La intención entra por el centro. Se descompone, se enruta a la clase apta para la tarea, se ejecuta y se verifica — luego el resultado vuelve al centro, que sostiene el único panorama completo.
Esquema. Los roles de las clases son fijos; el número de instancias escala con la carga.
De qué se responsabiliza cada capa.
El cerebro central sostiene el problema completo.
Un cerebro de orquestación se sitúa en el centro. Interpreta la intención, descompone una misión en tareas, enruta esas tareas a los agentes más aptos para ellas y sostiene el contexto global que ningún trabajador puede ver por sí solo.
También resuelve los conflictos entre agentes y mantiene el estado operativo a lo largo de toda la ejecución. Cuando dos caminos discrepan, la decisión se toma aquí, con el panorama completo — no en el borde, por un trabajador que solo conoce su propia porción.
- Interpreta la intención y la descompone en tareas discretas
- Enruta el trabajo a la clase de agente apta para cada tarea
- Sostiene el contexto global y resuelve conflictos
- Mantiene el estado operativo a lo largo de toda la ejecución
Traducción y transporte entre capas.
Los embajadores traducen la intención al protocolo propio de cada proveedor, CLI y sistema. Una tarea expresada una vez en el centro llega a cada endpoint en la forma que ese endpoint realmente espera, de modo que la capa de orquestación no queda acoplada a la interfaz de ningún proveedor concreto.
Los mensajeros mueven la información entre capas sin pérdida. Su tarea es la fidelidad: lo que una capa produjo es lo que la siguiente capa recibe, intacto, en lugar de degradarse por paráfrasis repetidas.
- Los embajadores hablan de forma nativa el protocolo de cada proveedor, CLI y sistema
- Los mensajeros preservan la fidelidad al mover información entre capas
- Juntos mantienen el núcleo neutral respecto al proveedor
El trabajo de otros agentes se verifica antes de contar.
Los auditores inspeccionan, validan y verifican el trabajo que otros agentes producen — en cuanto a corrección, seguridad y coherencia con el resto del sistema. Son una clase separada a propósito: el agente que hace el trabajo no es el agente que lo confirma.
Es el mismo principio de la revisión de código y la separación de funciones, aplicado dentro de la flota. La salida no se acepta porque un agente afirme que está lista; se acepta porque un agente distinto la verificó contra el requisito.
- Inspeccionan y validan la salida de otros agentes
- Verifican corrección, seguridad y coherencia
- Separación de funciones — quien hace nunca es quien verifica
Contexto reunido antes, inteligencia devuelta durante.
Los investigadores reúnen contexto, indagan en preguntas abiertas y devuelven inteligencia al sistema. Cuando una misión necesita información que la flota aún no posee, esta clase va a buscarla en lugar de adivinarla.
Su salida fluye de vuelta al cerebro de orquestación y hacia la memoria de trabajo, de modo que un hecho establecido una vez queda disponible para todo agente que lo necesite después.
- Reúnen contexto e indagan en preguntas abiertas
- Devuelven hallazgos a la memoria de trabajo compartida
- Convierten incógnitas en entradas que el resto de la flota puede usar
La capacidad inactiva se vuelve capacidad de preparación
Cuando no hay tarea, la flota estudia.
Cuando no hay tarea asignada, los agentes no se quedan inactivos. Entran en un bucle autodirigido de estudio y entrenamiento cruzado: trabajan material, comparan enfoques y se enseñan entre clases.
Ese aprendizaje no se deja como transcripción. Los agentes implementadores toman lo estudiado, afinan el modelo estudiado con ello e inyectan el conocimiento resultante de vuelta al sistema para la operación futura. La flota que maneja el trabajo de mañana está medible y notoriamente más preparada que la que terminó el de hoy.
- Estudio autodirigido y entrenamiento cruzado durante las ventanas inactivas
- Los agentes implementadores afinan el modelo estudiado con lo aprendido
- El conocimiento se reincorpora para la operación futura, no solo se registra
Neutral respecto al proveedor, y capaz de modificar pesos directamente.
Enrutamiento de proveedores
- Anthropic
- OpenAI
- xAI
- Moonshot
Una tarea, el modelo que le encaja. Sin atadura a un proveedor.
Fine-tuning · LoRA · una línea de investigación
No atado a un proveedor — y no limitado al prompting.
La infraestructura orquesta varios proveedores de LLM a la vez — Anthropic, OpenAI, Google, xAI, Moonshot — y enruta cada tarea al modelo que mejor le encaja. No está atada a un único proveedor. Donde resulta útil, bajo por debajo del prompt: fine-tuning, LoRA y modificación avanzada de pesos y sesgos sobre modelos de pesos abiertos.
También hay una investigación activa que solo describiré a alto nivel. Usa modelos pequeños de pesos abiertos en el rango de cuatro a veinte mil millones de parámetros, con un proceso propietario que activa solo una parte mínima — en memoria — de modelos mucho más grandes, en el rango de cien a seiscientos mil millones, y la integra en los modelos pequeños. El método se reserva; la dirección tiene un gran potencial, y eso es todo lo que diré aquí.
- Cinco proveedores orquestados de forma simultánea, enrutados por tarea
- Fine-tuning, LoRA, modificación de pesos/sesgos sobre modelos de pesos abiertos
- Investigación de modelos pequeños (~4–20B) que integra la activación selectiva de otros más grandes (~100–600B) — método reservado
Esta es la infraestructura que hace posible el resto del trabajo.
Qué puede alcanzar, y cómo se mantiene sólida.
Function calling
Los agentes actúan mediante interfaces de herramientas tipadas — leer, escribir, consultar, ejecutar — en lugar de emitir prosa que yo tenga que interpretar a mano.
MCP
El Model Context Protocol conecta a los agentes con herramientas y fuentes de datos mediante un contrato común, de modo que una capacidad añadida una vez queda disponible para toda la flota.
RAG
La recuperación alimenta a los agentes con el contexto específico que una tarea necesita desde un almacén de memoria de trabajo, en lugar de depender de aquello con lo que un modelo resultó entrenado.
Memoria persistente
El estado, las decisiones previas y el contexto acumulado sobreviven entre sesiones. La infraestructura recuerda; nada hay que volver a explicar cada mañana.
Observabilidad
Qué hizo cada agente, por qué y contra qué entradas queda registrado — de modo que el comportamiento pueda inspeccionarse después, no solo confiarse en el momento.
Autoauditoría de seguridad
Autoauditoría continua y autorizada con BlackArch Linux en servidores locales y en la nube. Hasta la fecha: ninguna brecha abierta ni fuga de información.
Cómo un objetivo se convierte en trabajo coordinado.
Una solicitud no va directa a un trabajador. Se lee como un único objetivo, se divide en tareas ordenadas, se enruta por clase, se ejecuta, se verifica y se devuelve al centro. Cada etapa tiene un responsable definido.
De la recepción a la devolución
- 01 Recepción La intención llega desde una superficie de comando y se lee como un único objetivo, todavía no como un plan.
- 02 Descomponer El cerebro de orquestación divide el objetivo en tareas discretas y ordenadas, con dependencias explícitas.
- 03 Enrutar Cada tarea se asigna a la clase de agente apta para ella — un ejecutor senior, o un despliegue de subagentes.
- 04 Ejecutar El trabajo corre en paralelo donde el grafo de dependencias lo permite, contra interfaces de herramientas tipadas.
- 05 Auditar Un agente separado verifica cada resultado en cuanto a corrección, seguridad y coherencia antes de que cuente.
- 06 Devolver La salida verificada fluye de vuelta al centro, que es el único que sostiene el panorama completo de la ejecución.
Las conexiones permanecen abiertas en ambas direcciones.
El enlace entre una superficie de comando y una instancia en ejecución es a nivel de socket y bidireccional. Permanece abierto en lugar de hacer polling, de modo que puedo empujar hacia una instancia y ella puede empujar de vuelta — a mitad de tarea, no solo al completar.
Socket bidireccional
Una línea, mantenida abierta, usada en ambos sentidos.
A nivel de socket · bidireccional · baja latencia
No es pedir y esperar. Es una línea mantenida abierta.
La mayoría de la automatización le habla a un modelo formulando una pregunta y esperando una respuesta. Esto no. El transporte es un socket persistente en ambas direcciones: envío instrucción o contexto hacia una instancia viva, y la instancia envía progreso, preguntas y resultados de vuelta por la misma línea abierta.
Como la conexión se mantiene en lugar de restablecerse por cada mensaje, la latencia se mantiene baja y un intercambio puede ser continuo. Un agente puede preguntarme algo a mitad de tarea y actuar según la respuesta sin desmontar y reconstruir el canal.
- Socket persistente — sin sobrecarga de reconexión por mensaje
- Ambos extremos pueden iniciar — empujar hacia adentro, empujar de vuelta
- Intercambio continuo a mitad de tarea, no pedir y esperar
Alcanzable desde dondequiera que esté el trabajo.
La misma infraestructura responde a tres superficies. La amplitud no es por novedad — significa que la flota es alcanzable desde la estación de trabajo, desde un teléfono y por voz, sin un sistema separado para cada una.
Las tres superficies viajan por el mismo transporte bidireccional hacia un único núcleo.
Inactivo, estudiar, afinar, inyectar — y repetir.
La preparación de la flota no queda fija en el despliegue. Entre tareas activas estudia, consolida lo estudiado en un cambio del modelo e inyecta el resultado de vuelta. El bucle es lo que hace que la flota de mañana esté más preparada que la de hoy.
- Tarea activa La flota ejecuta contra una misión. La intención se descompone, se enruta, se ejecuta en paralelo, se audita y se devuelve. El estado persistente se actualiza a medida que avanza la ejecución.
- Ventana inactiva Estudio autodirigido y entrenamiento cruzado. Sin tarea asignada, los agentes trabajan material, comparan enfoques y se enseñan entre clases en lugar de quedarse inactivos.
- Consolidación El material estudiado se convierte en un cambio del modelo. Los agentes implementadores afinan el modelo de pesos abiertos estudiado con lo aprendido — LoRA y modificación directa de pesos y sesgos donde resulta útil.
- Inyección El conocimiento se reincorpora para la operación futura. El resultado se inyecta en el sistema, no se deja como transcripción, de modo que la siguiente ejecución empieza más preparada de lo que terminó la anterior.
Qué sabe la flota, y cómo lo alcanza.
Un agente no depende de aquello con lo que un modelo resultó entrenado. El contexto se recupera para la tarea en curso, el estado persiste entre sesiones y cada acción corre a través de un contrato tipado. Nada hay que volver a explicar cada mañana.
Interfaces de contexto
- Almacén de memoria de trabajo
- contexto ámbito-tarea, recuperado bajo demanda
- Recuperación
- RAG — el contexto específico que una tarea necesita, no la conjetura de entrenamiento de un modelo
- Estado persistente
- las decisiones y el contexto acumulado sobreviven entre sesiones
- Contrato de herramientas
- MCP — una capacidad añadida una vez es alcanzable en toda la flota
- Interfaz de acción
- function calling — lectura / escritura / consulta / ejecución tipadas
- Procedencia
- queda registrado qué hizo cada agente, por qué y contra qué entradas
La infraestructura se verifica a sí misma.
La misma flota que hace el trabajo se somete a una auditoría de seguridad orientada hacia adentro. Corre de forma continua, con autorización, contra mis propios servidores — locales y en la nube — usando el conjunto de herramientas BlackArch.
Alcance autorizado
La autoauditoría corre contra mis propios servidores locales y en la nube, de forma continua y con autorización explícita. Es un ejercicio orientado hacia adentro, no hacia afuera.
Conjunto de herramientas BlackArch
BlackArch Linux aporta las herramientas con que corre la auditoría — los mismos instrumentos usados para sondear un sistema se vuelven sobre la infraestructura que sostiene la flota.
Resultado vigente
Hasta la fecha la auditoría no reporta ninguna brecha abierta ni fuga de información. Es una verificación recurrente, así que el resultado es un estado actual y no un certificado de una sola vez.
Open to the right work
Si tu problema necesita una capa de operaciones así de deliberada, esa es la conversación.
If you are holding a problem that doesn't fit inside one field, that is the conversation I want.