¿Qué es un agentic OS? Cómo trabajan juntos varios agentes

Si ya armaste un agente capaz de llamar tools, prácticamente tienes todo lo que necesitas para entender un «sistema multiagente», lo demás es sobre todo vocabulario y un poco de cableado. El hype alrededor del «agentic OS» hace que suene como un sistema operativo nuevo que te descargas. No lo es. Es una forma ordenada de correr varios agentes enfocados a la vez, con un pedazo de código que decide quién hace qué y una pequeña libreta compartida que todos consultan. Al terminar esta guía vas a poder leer cualquier diagrama multiagente, armar uno bien pequeño tú mismo y, igual de importante, reconocer cuándo un solo agente es la opción más inteligente y barata. Los ejemplos son en TypeScript y Claude de Anthropic, y el modelo mental es el que está detrás de Agent Orchestra y ThinkTank AI, pero las ideas aplican a cualquier stack.

01 · Las cinco palabras que de verdad necesitas

Quítale el marketing y un agentic OS se arma con cinco ideas sencillas.

• Agente. Un loop: le mandas un prompt a un modelo, dejas que decida llamar una tool, le devuelves el resultado de la tool y repites hasta que responde. Eso es todo. Un agente es un modelo más un objetivo más las tools que tiene permitido usar.
• Soul / persona. El carácter fijo de un agente, su system prompt. El «soul» dice quién es este agente y cómo se comporta: «Eres un revisor de seguridad escéptico. Nunca apruebas código que no puedas explicar. Marcas de inmediato los secretos en texto plano.» Mismo modelo, otro soul, un comportamiento por completo distinto.
• Profile. La configuración alrededor del soul: qué modelo corre, su temperatura, qué tools y API keys puede usar, su presupuesto de tokens y de tiempo. El soul es la personalidad; el profile son los permisos y los controles. Mantenerlos separados es justo lo que te deja darle a un «investigador» acceso a la web pero ninguna key de la base de datos.
• Orquestador (director). El código jefe que decide qué agente corre, en qué orden y qué ve cada uno. Casi siempre no es un modelo astuto, es código común y corriente (o un agente de planificación ligero) repartiendo tareas. Piénsalo como una cocina: el orquestador es el chef cantando las comandas, no el que pica las cebollas.
• Estado compartido. La libreta pequeña que todo agente puede leer y donde el orquestador escribe: la tarea original, los hallazgos hasta ahora, un veredicto. Mantenlo pequeño y explícito. Un estado mutable compartido enorme es la causa número uno de que estos sistemas se echen a perder.

Un término más con el que te vas a topar todo el tiempo:

• Hand-off. Cuando un agente termina y le pasa su resultado al siguiente. Un hand-off limpio es un mensaje tipado, «este es mi hallazgo, este es mi nivel de confianza», no toda la conversación cruda volcada en el siguiente prompt.

02 · Cómo encajan de verdad

Aquí está la idea completa de un tirón. El orquestador recibe una tarea y la escribe en el estado compartido. Elige un agente según su profile y su soul, lo corre, y el agente lee lo que necesita del estado compartido, hace su trabajo con sus tools y devuelve un resultado tipado. El orquestador escribe ese resultado en el estado compartido y decide qué sigue: otro agente, un reintento o «ya terminamos». Ningún agente le habla directo a otro, se comunican a través del orquestador y de la libreta compartida. Esa sola regla mantiene el sistema fácil de depurar.

Una buena imagen es la de una redacción pequeña. El editor (orquestador) asigna una nota. Un reportero (soul de investigador, profile con acceso a la web) reúne datos. Un verificador (soul de crítico, sin acceso a la web para que no se deje reconvencer por pereza) los pone en duda. Un redactor (soul de escritura) convierte los datos verificados en prosa. El editor lee cada hand-off, guarda lo bueno en el estado compartido y decide cuándo sale la nota. Nadie en el equipo necesita las libretas completas de los demás, solo hand-offs limpios.

03 · Un agentic OS bien pequeño que puedes correr

Armemos la cosa más pequeña que merece ese nombre: un orquestador, dos souls, profiles separados y un objeto de estado compartido. Dejaremos el «llamado al modelo» como un stub para que corra sin keys, y luego te muestro dónde entra Claude.

// agentic-os-mini.ts — dos agentes + un orquestador + estado compartido
type Profile = { model: string; temperature: number; tools: string[] };
type Agent = { name: string; soul: string; profile: Profile };

type SharedState = {
  task: string;
  draft?: string;
  review?: { ok: boolean; note: string };
};

// Dos agentes: misma familia de modelo, distinto SOUL y distinto PROFILE.
const writer: Agent = {
  name: "writer",
  soul: "Escribes una respuesta nítida de 2 oraciones. Sin relleno.",
  profile: { model: "claude-sonnet", temperature: 0.4, tools: [] },
};

const reviewer: Agent = {
  name: "reviewer",
  soul: "Eres escéptico. Apruebas solo si la respuesta es correcta y específica.",
  // Fíjate en el profile distinto: menor temperatura, sin tools extra.
  profile: { model: "claude-sonnet", temperature: 0.0, tools: [] },
};

// Stub del llamado real al modelo. Cámbialo por el SDK de Anthropic.
async function runAgent(agent: Agent, input: string): Promise<string> {
  console.log("[run] " + agent.name + " (" + agent.profile.model + ")");
  if (agent.name === "writer") return "El caching baja el costo reusando tokens del prompt.";
  return JSON.stringify({ ok: true, note: "Correcta y específica. Sale." });
}

// El ORQUESTADOR: código común que reparte el trabajo + es dueño del estado.
async function orchestrate(task: string): Promise<SharedState> {
  const state: SharedState = { task };

  // Hand-off 1: orquestador -> writer
  state.draft = await runAgent(writer, state.task);

  // Hand-off 2: salida del writer -> reviewer (un mensaje TIPADO, no el chat crudo)
  const raw = await runAgent(reviewer, "TAREA: " + state.task + "\nBORRADOR: " + state.draft);
  state.review = JSON.parse(raw);

  // El orquestador decide qué sigue según el veredicto.
  if (!state.review.ok) console.log("[loop] reviewer rechazó — reintentaría el writer");
  else console.log("[done] " + state.draft);

  return state;
}

orchestrate("Explica el prompt caching en una línea.").then((s) =>
  console.log("estado final:", s)
);

Córrelo:

npx tsx agentic-os-mini.ts

Salida esperada:

[run] writer (claude-sonnet)
[run] reviewer (claude-sonnet)
[done] El caching baja el costo reusando tokens del prompt.
estado final: {
  task: 'Explica el prompt caching en una línea.',
  draft: 'El caching baja el costo reusando tokens del prompt.',
  review: { ok: true, note: 'Correcta y específica. Sale.' }
}

Eso es un agentic OS real en miniatura. Dos souls, dos profiles, un orquestador dueño del estado compartido y hand-offs limpios y tipados. Para volverlo real, reemplaza el cuerpo de runAgent por un llamado a Claude de Anthropic: arma un arreglo de messages donde el soul del agente sea el system prompt y el input sea el turno del usuario, y luego lee el texto que regresa. Todo lo demás, el ruteo, el estado, los hand-offs, se queda exactamente igual.

04 · Casos de uso reales: investigar, revisar, construir

Tres patrones cubren casi todo lo que la gente de verdad busca en un montaje multiagente.

Investigar

Un agente busca y reúne, un segundo sintetiza y un tercero verifica. La ganancia es que el verificador tiene otro soul y un profile sin acceso a la web, así que no puede volver a buscar por pereza la misma fuente y convencerse solo otra vez. Esta es la redacción de la sección 02, y es justo la forma que hay detrás del análisis multiperspectiva de ThinkTank AI.

Revisar

Un «proponente» escribe código o un plan; un «crítico» con soul escéptico trata de tumbarlo; el orquestador solo deja pasar cuando el crítico da el visto bueno o se llega a un tope de turnos. El valor está en la separación: el crítico nunca vio el razonamiento del proponente, así que ataca la conclusión con la mente fresca en vez de asentir sin más.

Construir

Divide el trabajo en etapas, un planificador esboza, un programador implementa un paso, un tester lo corre, y el orquestador avanza el pipeline solo cuando cada etapa pasa. Agent Orchestra está hecho justo para esto: pasar un build de varios pasos entre agentes especializados sin perder el hilo.

05 · Cuándo un solo agente sobra (casi siempre)

Aquí va la parte anti-hype. La opción honesta por defecto es un solo agente con buenas tools. Un agente único que puede buscar, leer, escribir y llamar tu API resuelve la inmensa mayoría del trabajo real, y es muchísimo más fácil de registrar, asegurar y entender. Cada agente extra suma una frontera de contexto, un prompt que mantener y una forma nueva de que el sistema se contradiga o se quede en loop.

Aplica la prueba de decirlo en voz alta: si no puedes nombrar el segundo rol en una sola oración, «el crítico que detecta el error que se le escapó al planificador», todavía no estás listo para separar. Un rol que no puedes nombrar es un rol que el modelo no puede interpretar, y acabas de sumar costo y latencia por una corazonada.

Pasa a varios agentes solo cuando el trabajo se divida limpio por una de estas líneas: contexto de verdad distinto (un rol necesita todo el historial, otro apenas una rebanada angosta), tools o permisos distintos (un investigador con acceso a la web no debería tener también las keys de tu base de datos), o razonamiento de verdad independiente (un crítico que no debe quedar condicionado por el enfoque del proponente). Si nada de eso aplica, no tienes un problema multiagente, tienes un solo agente cuyo prompt hay que afinar.

Así que un agentic OS no es magia ni es un install, son cinco ideas sencillas conectadas con disciplina: agentes enfocados, cada uno con su soul y su profile, un orquestador aburrido dueño de un estado compartido pequeño y hand-offs limpios y tipados entre ellos. Empieza con un agente. Cuando el trabajo de verdad se divida en roles que puedas nombrar, agrega un segundo, mantén el estado pequeño, ponle topes a los loops y dale a cada profile solo las keys que necesita. Haz eso y tendrás un sistema fácil de depurar, barato de correr y seguro por construcción, que es justo de lo que se trata.