Saltar al contenido
ES

Soluciones · Orquestación

Orquestación de agentes y procesos duraderos

Profundización

Un agente aislado puede resolver una tarea. Un sistema orquestado conserva el trabajo hasta el resultado.

En una página

Sistemas que coordinan agentes, software, herramientas y personas durante procesos que deben conservar estado, esperar, recuperarse y continuar hasta un resultado comprobable.

  1. 01El trabajo importante suele durar más que una respuesta. Un agente puede resumir un documento, consultar una base de datos, preparar una propuesta o invocar una herramienta.
  2. 02Una arquitectura multiagente aporta valor cuando la especialización compensa la coordinación. La coordinación multiagente resulta útil cuando la especialización, el paralelismo o la revisión independiente compensan su coste.
  3. 04Diseñar el nivel de autonomía por acción. «Autónomo» no debería ser una propiedad global del sistema.

El trabajo importante suele durar más que una respuesta

Un agente puede resumir un documento, consultar una base de datos, preparar una propuesta o invocar una herramienta. Pero muchos procesos no terminan en ese paso.

El trabajo continúa cuando hay que:

  • reunir información adicional;
  • decidir entre varios recorridos;
  • consultar sistemas diferentes;
  • esperar una autorización o un evento;
  • ejecutar una acción;
  • responder a un fallo;
  • reanudar más tarde;
  • comprobar el efecto en otro sistema;
  • conservar aquello que sigue pendiente.

Construimos arquitecturas que coordinan ese recorrido y mantienen una responsabilidad única por el caso completo.

Una arquitectura multiagente aporta valor cuando la especialización compensa la coordinación

La coordinación multiagente resulta útil cuando la especialización, el paralelismo o la revisión independiente compensan su coste.

Una operación necesita además:

  • una representación del objetivo;
  • un estado persistente;
  • herramientas con contratos y permisos;
  • software determinista para reglas y transacciones;
  • políticas de autoridad;
  • memoria con procedencia y retención;
  • eventos, plazos y recuperación;
  • intervención humana diseñada;
  • evaluación del recorrido;
  • una señal de resultado.

Los agentes ocupan un lugar dentro de esa arquitectura. No sustituyen el resto.

Repartir responsabilidad sin fragmentar el resultado

Agentes

Interpretan contexto, formulan hipótesis, descomponen trabajo o eligen entre acciones permitidas. Su libertad se limita por herramientas, políticas y criterios de escalado.

Software determinista

Aplica reglas, cálculos, validaciones y transacciones que deben ser reproducibles. También protege invariantes que no deben depender de la respuesta de un modelo.

Herramientas

Conectan el razonamiento con datos y acciones reales. Cada herramienta declara entradas, salidas, efectos, identidad, errores y permisos.

Workflows duraderos

Persisten el proceso, reciben eventos, esperan, reintentan, compensan y reanudan. Mantienen la continuidad que una sesión de agente no puede garantizar.

Personas

Aportan contexto, criterio, negociación y autoridad. Pueden validar una inferencia, decidir un compromiso, aprobar, corregir, detener o rediseñar una regla.

Orquestación

Conserva el objetivo y coordina las transiciones. Determina quién tiene la siguiente responsabilidad y evita que un componente declare terminado el trabajo únicamente porque completó su parte.

Diseñar el nivel de autonomía por acción

«Autónomo» no debería ser una propiedad global del sistema.

Una misma operación puede contener acciones con niveles distintos:

  • consultar sin autorización;
  • preparar una propuesta;
  • recomendar un recorrido;
  • ejecutar cambios reversibles dentro de límites;
  • solicitar autorización para una acción sensible;
  • prohibir determinadas herramientas o efectos;
  • detenerse ante información contradictoria;
  • escalar una excepción no prevista.

Esta granularidad permite ampliar alcance allí donde la evidencia lo justifica y mantener control donde el coste de error lo exige.

Mantener estado durante el tiempo real del proceso

Un proceso puede durar segundos, semanas o meses. El diseño debe representar el tiempo como parte del trabajo:

  • eventos que todavía no han ocurrido;
  • información prometida y no recibida;
  • autorizaciones pendientes;
  • plazos y caducidades;
  • dependencias entre tareas;
  • reintentos permitidos;
  • acciones que no pueden repetirse;
  • cambios de versión durante el proceso;
  • responsables que cambian;
  • preguntas que continúan abiertas.

Persistir el estado evita que una persona o un agente tenga que reconstruir la historia cada vez que el proceso se reanuda.

Recuperarse sin ocultar lo ocurrido

Los fallos forman parte de la operación: una API no responde, un evento llega dos veces, un modelo devuelve una salida inválida, una autorización caduca o una acción se completa técnicamente sin producir el efecto esperado.

Diseñamos rutas para:

  • validar antes de actuar;
  • reintentar solo cuando sea seguro;
  • evitar duplicados;
  • compensar cuando existe una acción inversa;
  • conservar un estado consistente;
  • escalar con contexto;
  • dejar el caso explícitamente abierto cuando no puede resolverse;
  • explicar qué ocurrió y qué queda por hacer.

La recuperación preserva la evidencia del fallo y la convierte en información para operar y mejorar.

Human in the loop sin convertir a la persona en una cola de errores

La intervención humana debe responder a una razón concreta:

  • falta una información que solo una persona puede aportar;
  • una inferencia necesita validación de dominio;
  • existe un compromiso entre objetivos;
  • la acción requiere autoridad;
  • la situación es nueva o de alto impacto;
  • el sistema necesita corrección o detención.

El caso debe llegar con contexto, alternativa, evidencia y consecuencias. También deben medirse el tiempo de espera, la tasa de corrección y la recurrencia de la misma derivación. Si una persona resuelve siempre la misma excepción, quizá el sistema debería aprender una regla; si aprueba siempre sin revisar, quizá el control está mal diseñado.

Memoria con propósito y política de olvido

Conservar contexto es esencial, pero almacenar todo indefinidamente no lo es.

La arquitectura debe distinguir:

  • hechos del caso;
  • decisiones y autorizaciones;
  • contexto transitorio;
  • conocimiento validado reutilizable;
  • hipótesis pendientes;
  • información sensible;
  • datos sujetos a caducidad o eliminación.

Cada memoria necesita propósito, procedencia, acceso, versión y retención. La capacidad de olvidar de forma controlada es parte de una memoria responsable.

Evaluar el recorrido completo

Una evaluación de agente puede medir si eligió una herramienta o produjo una respuesta correcta. Una evaluación operacional debe añadir:

  • ¿se completó el resultado?;
  • ¿el estado permaneció consistente?;
  • ¿se recuperó después de un fallo?;
  • ¿la acción fue idempotente?;
  • ¿la persona recibió una derivación útil?;
  • ¿el sistema se abstuvo cuando debía?;
  • ¿puede explicarse por qué siguió ese recorrido?;
  • ¿el coste y el tiempo son razonables?;
  • ¿qué consecuencias aparecieron después?;
  • ¿qué parte debería optimizarse o rediseñarse?

El objeto de evaluación no es únicamente el modelo. Es la operación completa.

Dónde puede aplicarse

Operaciones empresariales

Solicitudes y procesos que atraviesan ERP, documentos, aprobaciones, incidencias y sistemas auxiliares.

Investigación y conocimiento

Agentes especializados que buscan, comparan, estructuran, cuestionan y revisan evidencia manteniendo preguntas y procedencia.

Reporting y producción de contenidos

Coordinación de datos, verificación, estructura, redacción, revisión, voz, subtítulos y publicación.

Proyectos complejos y desarrollo de software

Trabajo distribuido entre personas y agentes, con decisiones, dependencias, revisiones y ejecución reanudable.

SuperPythagoras es nuestra línea de trabajo para este caso: trata a personas y bots como participantes del mismo sistema de trabajo y les da roles, contratos de entrega, traspasos ordenados y revisión. SecondOpinion añade una perspectiva independiente sobre cada cambio con consecuencias, formulada por quien no lo escribió, y deja evidencia de qué se construyó y por qué.

Operaciones físicas de laboratorio

Coordinación entre percepción, estimación de estado, planificación, control, seguridad y verificación en máquinas y entornos definidos.

Orquestar para poder optimizar

Cuando el sistema conserva estados, decisiones, tiempos, excepciones y resultados, puede aprenderse dónde está la complejidad real.

La optimización puede modificar:

  • el reparto entre reglas, modelos, agentes y personas;
  • el orden y paralelismo de tareas;
  • los umbrales de autorización o escalado;
  • la selección de herramientas o modelos;
  • la información preparada para una decisión;
  • los plazos, prioridades y asignaciones;
  • la forma de recuperar un fallo;
  • el nivel de autonomía de una acción.

La orquestación es la estructura que permite observar el trabajo como un sistema y mejorarlo conservando la responsabilidad por el resultado completo.

Dónde continúa esta explicación

Esta página explica las operaciones duraderas desde el problema del cliente: qué trabajo debe conservarse, durante cuánto tiempo, con qué autoridad y hasta qué resultado.

La capacidad técnica —agentes, herramientas tipadas, grafos y recorridos, memoria acotada, workflows duraderos, sistemas multiagente, enrutamiento de modelos, presupuestos, criterios de parada y evaluación de recorridos— vive en Agentes y orquestación.

El marco general de la operación completa vive en Inteligencia operacional.

Qué debe conservar el sistema

  1. 01ObjetivoQué resultado completo se persigue y qué condiciones permiten declararlo completado, parcial o no resuelto.
  2. 02EstadoQué se sabe, qué se decidió, qué se ejecutó, qué está pendiente y quién tiene la siguiente responsabilidad.
  3. 03FuncionesQué corresponde a reglas, software, modelos, agentes, optimización, herramientas y personas.
  4. 04AutoridadQué acciones están permitidas, cuáles requieren autorización y quién puede corregir o detener.
  5. 05Tiempo y eventosCómo se gestionan esperas, plazos, eventos externos, reintentos y reanudaciones.
  6. 06Memoria y procedenciaQué contexto debe conservarse, de dónde procede y qué información debe olvidarse o caducar.
  7. 07Resultado y mejoraQué señal demuestra el efecto y qué trazas permiten evaluar y optimizar el recorrido.

Resultado

Una arquitectura operacional que mantiene una visión única del caso y coordina razonamiento, ejecución, esperas, personas y comprobación.

El nivel de autonomía puede variar por acción y evolucionar con la evidencia: desde preparar trabajo y recomendar hasta ejecutar dentro de políticas y límites definidos.

Cuándo un agente aislado deja de ser suficiente

  1. 01cuando el trabajo debe continuar después de la conversación
  2. 02cuando intervienen varias aplicaciones, agentes o equipos
  3. 03cuando algunas acciones son irreversibles o necesitan autorización
  4. 04cuando el proceso espera eventos o información durante horas o días
  5. 05cuando un fallo exige recuperar el estado y no repetir efectos
  6. 06cuando el contexto debe mantenerse sin reenviarlo manualmente
  7. 07cuando el sistema debe explicar por qué eligió un recorrido
  8. 08cuando el resultado debe verificarse en un sistema distinto del que ejecutó la acción

El sistema por dentro

Madurez · Evaluación
Cómo se organiza
El proceso se modela como un conjunto de estados, transiciones, herramientas, políticas y roles. Los agentes interpretan y eligen dentro de límites; el software determinista ejecuta reglas y transacciones; el workflow persiste, espera y recupera; y las personas intervienen con funciones y autoridad explícitas.
Qué puede examinarse
Puede examinarse una ejecución completa, el estado antes y después de cada transición, las herramientas disponibles, las políticas de autorización, la memoria conservada, una intervención humana, un fallo con recuperación y la señal utilizada para cerrar el caso.
Cómo se comprueba
Evaluamos recorridos completos y no solo respuestas: finalización, consistencia del estado, recuperabilidad, idempotencia, calidad de decisiones, porcentaje y utilidad de escalados, tiempos de espera, coste, trazabilidad y efecto comprobado. También simulamos herramientas indisponibles, eventos duplicados, contexto contradictorio y cambios de modelo.

Condiciones y límites

La orquestación no corrige una definición ambigua del resultado ni una política organizativa inexistente. Los agentes siguen dependiendo de la calidad de sus herramientas, contexto y evaluación. Las acciones de alto impacto necesitan permisos, límites y capacidad de intervención proporcionados al riesgo.

La capacidad cobra valor dentro de un problema concreto.

Compartidnos el contexto y pensaremos juntos cómo combinar información, tecnología, software, personas y evaluación alrededor del resultado que importa.

Buscar · Escribe para buscar. Esc para cerrar.

Resultados de búsqueda →

Preguntar al bot

Este es Ask 3.14, un asistente automático. Responde únicamente con el contenido público de esta web —soluciones, capacidades, sistemas, preguntas, lecturas y trabajo de laboratorio—, muestra los contenidos que ha usado y distingue aquello que la web todavía no permite establecer. No es una persona del equipo ni conoce vuestro caso; para hablar con alguien, escribid al equipo.

Asistente automático limitado al contenido público de 3.14; puede abstenerse. Para hablar con una persona, escribid al equipo.

Escribir al equipo →