Una tarea del mundo real conlleva un objetivo verificable, restricciones que definen qué se considera aceptable y un estado externo susceptible de cambiar mientras el sistema está en ejecución. Un objetivo sin mecanismo de verificación se convierte en una conversación interminable, ya que nada dentro del sistema puede confirmar que la tarea ha concluido.
El alcance se limita al bucle más pequeño capaz de actuar, verificar y detenerse.
Un objetivo se vuelve operativo únicamente cuando cuenta con una señal de finalización que un programa puede evaluar; por ejemplo, la escritura de un archivo, la actualización de un estado o la cumplimentación de un conjunto de campos. Las restricciones acotan el rango de resultados aceptables, como una fecha límite, un presupuesto de llamadas a la API, un formato obligatorio o una política que bloquee determinadas acciones.
El estado externo comprende cualquier dependencia ajena a la llamada al modelo, como una fila de base de datos, una cola de tickets, una página web o un evento de calendario. Cuando el estado externo varía, un plan que inicialmente era correcto puede dejar de serlo sin que se produzca ningún fallo en el código.
Regla Si no es posible definir una comprobación determinista de finalización, trate la tarea como un proceso abierto e incorpore un límite de ejecución (presupuesto de parada) junto con una fase de revisión humana.
La arquitectura mínima consiste en un bucle que desplaza los datos a través de etapas fijas y registra los cambios producidos en cada una de ellas. El bucle parte de una entrada, lee y actualiza el estado, invoca a un modelo para proponer la siguiente acción, ejecuta llamadas a herramientas que modifican el estado externo y, finalmente, evalúa una condición de parada antes de reiniciar el ciclo.
Interactúe con el diagrama del flujo de trabajo (pipeline) y realice un seguimiento de los datos que entran en cada paso y de los resultados que dicho paso devuelve.
Una vez establecido el bucle, es posible localizar cada fallo. Un fallo en la recuperación de información se manifiesta como entradas faltantes en la llamada al modelo; un error de herramienta aparece como una excepción o una respuesta distinta a 200; y un error en la condición de parada se evidencia mediante iteraciones repetidas sin avance en el estado.
Una tarea de elaboración de informes de investigación suele finalizar cuando el documento cumple con los requisitos de formato y citación y supera una verificación (por ejemplo, comprobar que cada afirmación cuente con una URL de origen en el archivo de notas). Las herramientas empleadas suelen incluir funciones de búsqueda, análisis de documentos y escritura de archivos, mientras que el control de costes se centra habitualmente en limitar la navegación y el crecimiento del contexto.
Una tarea de clasificación de tickets concluye cuando cada ticket ha sido etiquetado, asignado y comentado con una breve justificación, y el sistema de gestión de tickets confirma la actualización. Las herramientas suelen incluir una API de tickets, un verificador de políticas y, en ocasiones, consultas a una base de conocimientos interna; por su parte, la fiabilidad se centra en evitar actualizaciones incorrectas.
Compare ambas tareas seleccionando las restricciones, las herramientas y las señales de finalización, y observe cómo varía la condición de parada.