Skip to main content

Patrones de orquestación: de un solo loop a un grafo

Los patrones de orquestación de agentes que de verdad aguantan en producción — el loop ReAct de un solo agente, supervisor/worker, colaboración multi-agente, máquinas de estado basadas en grafos, y routing/handoff — cada uno con dónde encaja y su trade-off de costo, latencia y confiabilidad. Más la advertencia honesta de que cada agente que sumás es superficie de falla que ahora te pertenece, y dónde se ubica el Atlas Reasoning Engine de Agentforce como el instrumento de razonamiento gestionado.

Referencia·Actualizado 2026-06-01·Escrito por Lira · Editado por German Medina

"Orquestación" no es más que la respuesta a una sola pregunta: cuando llega un request, ¿quién decide qué pasa después? Un agente que razona, llama una tool, mira el resultado y vuelve a razonar ya está orquestando — ese loop es un patrón, y para la mayoría de los trabajos es el único que necesitás. Los patrones de abajo no son una escalera que subís para ganar puntos de sofisticación. Son respuestas a presiones específicas — un trabajo demasiado grande para un solo contexto, un paso que tiene que correr de forma determinística, un request que nunca debería haber llegado a un agente — y cada uno paga su capacidad con costo, latencia y una superficie de falla más amplia.

El instinto que sale de un slide deck es ir por el patrón más elaborado. El instinto que sale de producción es el opuesto: arrancá con el loop más simple que podría funcionar, y sumá estructura solo cuando una falla real te obligue. Esta página cubre los patrones que aguantan, cuándo encaja cada uno, y qué te cuesta. El toolkit — Agentforce, LangGraph, la Claude API, MCP — es complementario; componés estos patrones con el instrumento que encaje con el problema, no elegís un bando (principio 7).

Single-agent loop

El default, y el que hay que superar. Un solo agente corre el loop reason → act → observe — el patrón ReAct: razona sobre el request, elige una tool, la llama, observa el resultado, y vuelve a loopear hasta que tiene una respuesta o pega contra una condición de corte. Un modelo, una ventana de contexto, un set de tools, un solo lugar donde mirar cuando se rompe.

Cuándo encaja: la abrumadora mayoría del trabajo con agentes. Si la tarea es un trabajo coherente — responder una pregunta sobre data fundamentada, completar un flujo con un puñado de tools, redactar algo desde el contexto — un solo loop lo hace con lo mínimo que puede salir mal.

Trade-off: el costo más bajo, la latencia más baja, la mayor capacidad de debug — hasta que el trabajo deja de entrar en un solo contexto. El loop se degrada cuando la cantidad de tools crece más allá de lo que el modelo puede elegir de forma confiable, cuando la tarea de verdad tiene fases distintas que necesitan instrucciones distintas, o cuando una ventana de contexto no puede sostener todo lo que el trabajo toca. Esos son los síntomas que justifican ir por más estructura — no las ganas de parecer sofisticado.

Supervisor / worker

Un agente coordinador es dueño del request y delega piezas a sub-agentes especializados, cada uno con sus propias instrucciones más acotadas y sus tools. El supervisor decide quién hace qué, pasa la sub-tarea, junta el resultado, y decide el siguiente movimiento. Los workers no hablan entre ellos — reportan para arriba.

Cuándo encaja: un trabajo que de verdad se parte en especialidades — un paso de investigación, un paso de redacción, un paso de validación — donde mantener acotadas las instrucciones y tools de cada worker hace a cada uno más confiable que un agente haciendo malabares con todo. El supervisor sostiene el plan; los workers sostienen el foco.

Trade-off: cada salto es otra llamada al modelo, así que el costo y la latencia suben más o menos con la cantidad de delegaciones, y el supervisor en sí es un nuevo punto de falla — una mala decisión de delegación rutea mal el request entero. Vale la pena cuando workers acotados superan de forma medible a un agente sobrecargado; no vale la pena cuando solo estás partiendo un trabajo coherente para que parezca un organigrama.

Colaboración multi-agente

Varios agentes con roles distintos trabajando el mismo problema — no un solo coordinador delegando para abajo, sino múltiples agentes aportando, a veces criticando o construyendo sobre el output del otro. Este es el patrón que más impresiona en un diagrama y más fuerte muerde en producción.

Cuándo encaja: rara vez, y solo cuando un solo agente de verdad no puede sostener el trabajo — el problema necesita perspectivas distintas y simultáneas que no colapsan limpio en el plan de un supervisor. La mayoría de los problemas que parecen necesitar un comité de agentes se resuelven mejor con un solo agente bien fundamentado, o con supervisor/worker y delegación clara.

Trade-off: acá es donde el costo y la superficie de falla crecen más rápido. Cada agente es otro contexto que hay que hacer bien, otro set de tools que gobernar, otro lugar donde la cadena puede romperse — y agentes razonando sobre el output del otro componen errores en vez de atajarlos. La latencia es aditiva a lo largo de la conversación, y el costo puede correr varias veces el de un solo loop para la misma tarea.

Orquestación basada en grafos

Cuando necesitás control determinístico sobre un componente no determinístico, dejás de dejar que el modelo decida el flujo y dibujás el flujo vos mismo — como una máquina de estados explícita. Este es el modelo de LangGraph: nodes (los pasos — una llamada al modelo, una llamada a una tool, una función), edges (las transiciones entre ellos, incluyendo las condicionales que ramifican según el estado), y un objeto de state compartido que cada node lee y escribe a medida que la corrida avanza.

El punto es el control. Un loop suelto decide su propio paso siguiente en cada turno; un grafo fija los pasos que tienen que estar fijos — validá acá, ramificá allá, terminá siempre con este node — mientras todavía deja que un node llame a un modelo donde querés no determinismo. Te queda un camino reproducible e inspeccionable a través de la corrida, en vez de confiar en que el modelo navegue cada vez.

Cuándo encaja: flujos con estructura real — pasos obligatorios, lógica de ramificación, reintentos, loops con una salida definida, un node de aprobación humana en el medio — donde "el modelo decide el orden" es exactamente el riesgo que necesitás sacar. Una vez que un trabajo tiene más de un par de puntos de decisión que tienen que ir de una forma específica, un grafo convierte la esperanza implícita en control explícito.

Trade-off: el mayor control, el mayor diseño por adelantado. Definís los nodes, los edges y el schema del state — más ingeniería antes de la primera corrida que la que un loop necesita jamás. Ese costo lo pagás a propósito: cuando un paso tiene que correr sí o sí, o correr en orden, el determinismo que te da un grafo vale más que la flexibilidad que resignás.

Routing / handoff

Antes de cualquiera de los de arriba, el movimiento más barato suele ser no correr un agente para nada. Un router clasifica el request entrante y lo manda al destino correcto — una tool específica, un agente especializado, un flujo determinístico, o un humano. La clasificación puede ser un modelo chico, una regla, o una llamada rápida y barata cuyo único trabajo es decidir adónde va el request.

Cuándo encaja: cualquier sistema que recibe una mezcla de tipos de request donde algunos no necesitan un agente completo — un FAQ que responde un lookup, un request que le pertenece a un humano, una categoría que mapea derecho a una sola tool. El routing reserva el razonamiento caro para los requests que de verdad lo necesitan, y te da un handoff limpio a una persona para cualquier cosa que el sistema no debería decidir por su cuenta (principio 9 — un humano es responsable, y el handoff es donde esa responsabilidad tiene su costura).

Trade-off: costo y latencia muy bajos para el paso de routing en sí, y reduce el costo total al mantener trabajo fuera de los caminos caros. El riesgo está concentrado en el clasificador: un ruteo equivocado manda el request a algún lado equivocado, así que la precisión del router es lo que hay que evaluar más fuerte. Un ruteo equivocado es barato de correr y caro de tener mal.

La opción de razonamiento gestionado: Atlas Reasoning Engine

Todo lo de arriba asume que sos dueño del loop de planificación. Agentforce ofrece la otra forma: su Atlas Reasoning Engine es el planificador gestionado — maneja el paso de razonar-y-planificar de un agente dentro de la plataforma de Salesforce, decidiendo qué actions y topics usar contra data gobernada, así que vos cableás las tools, las instrucciones y el grounding en vez del loop de control en sí. El trade-off es el de siempre, gestionado contra custom: resignás algo de control sobre el loop y obtenés la planificación, el grounding al perfil de Data 360, y la gobernanza de la plataforma manejados por vos.

Este es un instrumento, no un rival del resto. Atlas planifica dentro de Salesforce donde el trabajo vive en el modelo de seguridad y necesita actions gobernadas y auditables; un grafo de LangGraph o un loop de la Claude API lleva el trabajo fuera de la plataforma donde necesitás un flujo custom o un modelo que Salesforce no alcanza (principio 7). Un sistema real muchas veces hace las dos cosas — Agentforce dueño de las actions dentro de la plataforma, un grafo externo dueño de un paso que no puede — y se hacen handoff entre ellos. La habilidad es componerlos, no elegir uno y defenderlo.

Eligiendo, en breve

Arrancá en el single loop. Sumá un router cuando estés recibiendo tipos de request que no todos merecen un agente. Pasá a supervisor/worker cuando especialistas acotados superen a un agente sobrecargado en un trabajo que se parte limpio. Andá a un grafo cuando un paso tenga que correr de forma determinística o en un orden fijo. Andá a la colaboración multi-agente al final, y solo cuando puedas nombrar qué es lo que un solo agente no puede hacer. Cada escalón en la lista compra capacidad con costo, latencia y superficie de falla — así que dá el paso solo cuando una falla real, no un diagrama, lo esté pidiendo. Nada de esto reemplaza al resto de la disciplina: un sistema orquestado igual tiene que estar fundamentado, evaluado y trazado, o la orquestación solo falla en una forma más elaborada.

Related

Reference: