Flujo fijo, agente único o sistema multiagente: cómo elegir el patrón para una tarea

Antes de elegir arquitectura, describe la tarea

La primera decisión no es cuántos agentes construir, sino qué trabajo se quiere automatizar y cómo se reconocerá un resultado correcto. Si el objetivo, las entradas y la secuencia de pasos pueden describirse con precisión, quizá baste un programa convencional. Si algunas decisiones dependen del contenido de cada caso, puede ser útil delegar parte de la selección al modelo. Si hay responsabilidades distintas que necesitan trabajar con cierto grado de independencia, podría estudiarse una composición de agentes. Son posibilidades de diseño, no una escala en la que cada opción sea necesariamente más avanzada o mejor.

Para comparar alternativas, redacta una ficha breve de la tarea. Incluye el objetivo, las entradas esperadas, los pasos conocidos, las variaciones que aparecen en la práctica, el resultado observable y las consecuencias de un error. Añade también qué acciones puede realizar el sistema y cuáles requieren autorización o revisión humana. Esta descripción evita confundir una tarea con muchos pasos con una tarea que necesita autonomía: una secuencia larga pero estable puede ser perfectamente programable.

Las fuentes disponibles ofrecen orientación para decidir entre un agente único y varios agentes, presentan patrones de diseño y comparan agentes con flujos de trabajo. No proporcionan, en los fragmentos disponibles, mediciones comparables de rendimiento, costes o tasas de error para estos tres enfoques. Por ello, la matriz y los ejemplos de esta guía son un marco de análisis práctico, no una afirmación de que un patrón produzca mejores resultados de forma general.

Patrón 1: flujo determinista

En un flujo determinista, el programa fija la secuencia de operaciones y las condiciones que hacen avanzar, repetir o detener cada etapa. Puede incluir llamadas a un modelo, por ejemplo para clasificar un texto o extraer campos, sin convertir por ello el conjunto en un agente autónomo. La distinción útil es quién decide el siguiente paso: en el flujo, esa decisión se especifica principalmente en el código o en una configuración explícita.

Este patrón suele ser adecuado cuando la tarea tiene entradas conocidas, reglas relativamente estables, pocas ramas relevantes y una salida que puede validarse con comprobaciones concretas. Un proceso de recepción de facturas podría extraer datos, validar campos obligatorios, cotejar importes y enviar a revisión los casos que incumplen una regla. La secuencia puede contener excepciones, pero el equipo las representa mediante condiciones explícitas, en vez de pedir al modelo que invente la ruta de trabajo en cada ejecución.

La ventaja de este enfoque, como criterio de diseño, es que el equipo puede inspeccionar el orden previsto y vincular cada decisión a una regla o etapa. No garantiza por sí solo que los componentes funcionen correctamente: una extracción puede ser errónea y una regla puede estar mal definida. La limitación es que la variación no prevista requiere cambiar las reglas, añadir ramas o enviar el caso a una persona. Si las excepciones se multiplican, mantener el flujo puede volverse difícil; eso no demuestra automáticamente que haga falta un agente, pero sí invita a revisar el diseño.

Las herramientas en un flujo pueden limitarse a las invocaciones que el código prevé. Los permisos y los datos accesibles dependen de cómo se implemente y configure el sistema; no se deducen del nombre del patrón. La memoria persistente tampoco es una propiedad necesaria del flujo. Puede conservarse el estado requerido para completar una ejecución, pero conviene diferenciar ese estado temporal de una memoria reutilizada entre tareas.

Patrón 2: agente único con herramientas

En un patrón de agente único, el modelo participa en la elección de los pasos siguientes a partir del objetivo, el contexto disponible y las herramientas que se le ofrecen. El programa sigue definiendo el marco: qué objetivo se comunica, qué herramientas están disponibles, qué límites se aplican y cuándo se detiene o solicita ayuda. La autonomía no equivale a permiso ilimitado; la selección dinámica de una acción debe ocurrir dentro de condiciones establecidas por el sistema.

Este patrón puede ser candidato cuando los casos varían de manera relevante y una secuencia rígida resulta poco natural, pero las capacidades necesarias caben en un conjunto acotado de herramientas. Pensemos en solicitudes internas de soporte: una persona pregunta por un problema que puede requerir consultar documentación, comprobar el estado de un servicio y redactar una respuesta. El agente podría decidir cuál de esas consultas necesita según el caso. Si la acción tiene consecuencias importantes, el sistema puede limitarse a preparar una recomendación para que una persona la apruebe.

La flexibilidad trae una carga de evaluación distinta. No basta con comprobar una ruta única; hay que observar qué acciones eligió el agente, qué información usó, cuándo se detuvo y si solicitó revisión en casos ambiguos. Una respuesta final correcta por casualidad no demuestra que la secuencia intermedia fuera adecuada. Conviene registrar decisiones relevantes de forma proporcionada y revisar tanto los casos resueltos como los que el sistema rechazó o escaló.

Las herramientas son parte central del límite operativo: describen acciones disponibles, pero su alcance efectivo depende de su implementación, autenticación y controles. No debe suponerse que una instrucción en lenguaje natural sustituye a controles técnicos de acceso. La memoria puede ser nula, limitada a la interacción actual o persistente, según el producto y el diseño. Para una evaluación inicial, es preferible declarar explícitamente qué contexto se conserva y comprobar si es necesario, en lugar de asumir que más memoria mejora el resultado.

Patrón 3: sistema multiagente

Un sistema multiagente reúne varios componentes con funciones diferenciadas que interactúan para completar una tarea. La forma de coordinación puede variar: un componente puede asignar trabajo, los componentes pueden intercambiar resultados o el sistema puede organizar una secuencia de funciones especializadas. El rótulo, por sí solo, no aclara quién decide el flujo, qué información se comparte ni cómo se resuelven desacuerdos. Esas propiedades deben especificarse para poder evaluar el diseño.

La pregunta para justificar varios agentes no es si el problema parece grande, sino si separar responsabilidades aporta una ventaja verificable frente a una sola unidad de trabajo o un flujo explícito. Podría investigarse esta opción si hay tareas distinguibles, contextos que conviene mantener separados o actividades que necesitan producir resultados independientes antes de una síntesis. Pero la división introduce coordinación, transferencia de contexto y más puntos donde pueden surgir inconsistencias. Sin medición en el caso concreto, no se debe afirmar que esa separación mejore la calidad o reduzca el tiempo.

Volvamos a la factura. Un diseño hipotético podría separar la extracción documental, la comprobación de políticas y la preparación de una revisión para una persona. Antes de construirlo, habría que preguntar si esas responsabilidades son realmente independientes, si cada una puede evaluarse por separado y si el resultado combinado es mejor o más fácil de inspeccionar que una ruta fija o un único agente con las mismas herramientas. Si la respuesta es no, los componentes adicionales pueden ser coste sin beneficio demostrado.

La visibilidad de las interacciones importa: hay que poder reconstruir qué componente recibió qué información, qué resultado produjo y cómo se utilizó después. Esto facilita investigar fallos, aunque no elimina la posibilidad de que los haya. Permisos, herramientas y memoria se asignan según la implementación; la arquitectura no los resuelve automáticamente. Una separación funcional puede permitir delimitar responsabilidades, pero solo si los accesos y los intercambios de datos se diseñan y verifican de forma explícita.

Comparación aplicada y matriz de decisión

Para comparar patrones con justicia, fija primero la misma tarea, el mismo conjunto de casos y el mismo criterio de éxito. En el ejemplo de facturas, eso significa usar documentos representativos, las mismas reglas contables y una definición común de qué cuenta como extracción correcta, derivación apropiada y registro aceptable. No sería una comparación útil si un patrón recibe más contexto, herramientas o intervención humana que otro sin documentarlo.

La tabla siguiente no asigna puntuaciones universales. Resume preguntas que el equipo puede responder con evidencia de su proceso, pruebas y mediciones. Por ejemplo, “variabilidad alta” debería significar que aparecen diferencias observables que cambian los pasos necesarios, no simplemente que el equipo no conoce aún el proceso. Del mismo modo, “fácil de comprobar” requiere una prueba o criterio de aceptación, no solo una impresión subjetiva.

Herramientas, permisos, memoria y supervisión

Estos elementos no se determinan de forma automática por escoger uno u otro patrón. El patrón cambia dónde se toman decisiones y cuántos componentes participan; el alcance real depende de las herramientas conectadas, de cómo se controla el acceso, de los datos que se entregan y de la lógica de revisión. Por eso, una arquitectura no debe describirse como “segura” o “controlada” únicamente porque sea un flujo o porque esté formada por varios agentes.

Para las herramientas, documenta cada acción disponible, su efecto y quién puede invocarla. Diferencia las operaciones de lectura de las que modifican datos, envían mensajes o generan otros efectos. En un flujo, puede ser el propio programa quien invoque cada herramienta en un punto previsto. En un agente, el modelo puede seleccionar una herramienta entre las permitidas. En un sistema multiagente, hay que aclarar qué componentes tienen acceso a cuál y cómo se valida que una salida transferida no desencadene una acción no autorizada.

Para memoria y contexto, especifica qué se conserva durante una ejecución y qué, si acaso, se reutiliza en otra. Registra el motivo de esa conservación y comprueba su efecto con casos de prueba. La memoria adicional puede ayudar a mantener información necesaria, pero también puede introducir contexto obsoleto o irrelevante; esta posibilidad debe tratarse como un riesgo de diseño que se prueba, no como un resultado inevitable.

La supervisión humana debe tener una función concreta. Puede confirmar acciones, resolver excepciones, verificar resultados o detener el proceso. Una revisión que llega demasiado tarde quizá no evite el efecto que se quería controlar; una revisión de cada paso puede volver innecesaria la automatización. Define los puntos según el impacto del error y mide cuántos casos se revisan, cuánto trabajo requiere la revisión y qué desacuerdos aparecen.

Evaluación inicial: medir antes de aumentar la autonomía

Un piloto útil no empieza con una demostración preparada para que todo salga bien. Empieza con un conjunto de casos que refleje el uso previsto: casos frecuentes, límites conocidos, documentos incompletos, entradas ambiguas y excepciones que exigen detenerse. Conserva una referencia del proceso actual para comparar resultados y registra las condiciones de cada prueba. Si se cambian las instrucciones, herramientas o reglas, anota el cambio para no atribuir a la arquitectura un efecto que podría proceder de otra modificación.

Evalúa por separado el resultado y el camino. Entre las preguntas de resultado están: ¿se extrajeron los datos correctos?, ¿se eligió la ruta autorizada?, ¿se detectó la necesidad de revisión?, ¿se evitó completar una acción con información insuficiente? Entre las preguntas de proceso están: ¿qué decisiones intermedias hubo?, ¿qué herramientas se usaron?, ¿se consultó información pertinente?, ¿se detuvo el sistema cuando debía? Para agentes y sistemas multiagente, estos registros ayudan a entender si una respuesta aceptable se obtuvo mediante una ruta adecuada.

Define de antemano los criterios para continuar, acotar o detener la prueba. Si los errores más graves se producen al elegir una acción, puede ser necesario restringir herramientas o devolver esa decisión al código. Si los casos no pueden evaluarse de forma consistente, primero hay que mejorar la definición de éxito. Si la revisión humana corrige frecuentemente el mismo tipo de resultado, el sistema podría necesitar una regla explícita, mejores entradas o una etapa de validación, no necesariamente más agentes.

Cuándo no usar un agente o cuándo reducir la autonomía

No usar un agente puede ser la decisión adecuada si una rutina conocida puede resolverse con código convencional, si las reglas son verificables y estables, o si no existe una forma fiable de comprobar el resultado. También puede ser preferible mantener una persona en el circuito cuando el coste de equivocarse es alto y las acciones no se pueden revertir con facilidad. En esos casos, la automatización puede limitarse a preparar datos, resumir información o proponer una ruta sin ejecutarla.

Vuelve a un flujo fijo, o acota el agente a una etapa, si la selección de acciones no aporta una ventaja que puedas medir, si el agente utiliza herramientas innecesarias, si las excepciones se pueden representar ahora con reglas claras o si resulta difícil reconstruir cómo se tomó una decisión. Ante discrepancias entre componentes de un sistema multiagente, considera si la separación realmente ayuda: una ruta explícita con validaciones puede ser más fácil de probar para ese caso, aunque el equipo debe comprobarlo.

Si se evalúa una composición de agentes, empieza con funciones separadas que tengan entradas, salidas y criterios de aceptación definidos. No dividas por intuición una tarea en muchos papeles abstractos. Comprueba primero una versión sencilla, observa dónde falla y amplía únicamente cuando haya un problema identificado que la separación pueda abordar. El consejo de comenzar por el patrón más simple aparece también en una de las fuentes secundarias aportadas; aquí se presenta como una heurística de diseño que conviene contrastar en el caso de uso, no como una ley universal.

Lista final para documentar la elección

Una decisión arquitectónica resulta más útil cuando puede revisarse después de observar el sistema en condiciones reales. Documenta qué problema se intenta resolver, qué alternativas se compararon y qué evidencia inclinó la decisión. No hace falta asumir que la elección será permanente: al cambiar la variabilidad de los casos, las consecuencias de error o las herramientas disponibles, puede cambiar también el patrón proporcionado.

Para profundizar en la comparación entre agente único y varios agentes, consulta la guía de Microsoft Learn indicada en las fuentes. Para comparar agentes y flujos de trabajo, puede consultarse la documentación de UiPath, teniendo en cuenta que es documentación de proveedor. Las páginas de patrones de diseño de Microsoft Learn y Google Cloud ofrecen orientación arquitectónica; sus recomendaciones deben evaluarse frente a las necesidades y restricciones del equipo. Estas referencias no sustituyen las pruebas propias ni demuestran por sí mismas resultados de rendimiento para una tarea concreta.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.