AI Workers proporciona el ciclo de vida completo de una fuerza de trabajo sintética. Los administradores definen las identidades de los workers, cada una con una persona visible, un rol, un system prompt que da forma al tono y a la especialización, y parámetros de generación como el presupuesto de tokens y la temperatura. Cada worker dispone de una cola de trabajo, un hilo de conversación duradero y un conjunto de asistentes conectados a través de los cuales se le puede contactar o mediante los cuales él contacta con el exterior. Los workers consultan datos operativos en vivo, ejecutan escrituras y cambios de estado, realizan tareas programadas sin supervisión, vigilan las excepciones, extraen información estructurada de documentos y actúan como revisores y aprobadores dentro de los procesos de negocio.

Detrás de cada worker existen dos vías de respuesta que se eligen de forma automática. Cuando hay un asistente externo conectado y accesible, la plataforma le envía la solicitud y recibe la respuesta a través de una callback firmada y autenticada. Cuando no hay ningún asistente externo disponible, un modelo integrado se ejecuta directamente contra el mismo conjunto de herramientas gobernadas, de modo que un worker nunca queda mudo ni responde con un contexto obsoleto. Ambas vías se apoyan en un mismo registro compartido de herramientas empresariales, lo que garantiza que un worker se comporte de forma idéntica tanto si el razonamiento lo realiza un asistente externo como si lo hace el modelo integrado. La conversación, la gestión de la cola, la configuración de los workers, los ajustes del proveedor de modelos y el registro de asistentes conectados se gestionan desde una única superficie de administración de IA.

En el centro se sitúa el AI Worker: una identidad persistente con un nombre, un rol y memoria de todo lo que se le ha pedido. Un worker se define menos por el código que por tres elementos que lo rodean. El primero es un rol, que porta los permisos del worker y es la única autoridad sobre lo que puede ver y hacer; un worker jamás puede rebasar el límite que describe su rol, y modificar ese rol cambia su alcance de inmediato. El segundo es la cola de trabajo, un backlog ordenado de tareas que pertenecen al worker, cada una con una prioridad, una programación opcional, un ciclo de vida que va de en cola a en curso hasta un desenlace resuelto, y un resultado registrado. El tercero es la conversación, un registro de solo adición de los turnos de usuario, worker y sistema que aporta continuidad a cada intercambio y una pista de auditoría completa.

En torno a estos elementos se sitúan dos conceptos de apoyo. Un proveedor de modelos describe qué motor de razonamiento impulsa a un worker, resuelto en el momento de uso, de modo que un worker concreto puede anular el valor por defecto de la organización sin ningún cambio en el propio worker. Los asistentes conectados describen las herramientas externas a las que se puede encaminar un worker, cada una con su propio endpoint, sus credenciales y su estado de salud. Las relaciones son deliberadamente sencillas: un rol da forma a muchos workers, un worker posee una cola y una conversación y puede tener varios asistentes conectados, y un proveedor puede impulsar a muchos workers. Nada de esto pertenece a un cliente ni a un libro contable; se trata de configuración y persona, alojadas en el núcleo de la plataforma para que la identidad y el permiso se gobiernen en un único lugar.

La interacción cotidiana es conversacional. Un usuario abre el panel del worker, selecciona un worker por nombre y rol, y escribe una solicitud. El mensaje se registra y se confirma al instante, y a continuación se despacha sin bloquear la interfaz. Si responde un asistente conectado, su respuesta llega a través de la callback y sustituye el indicador de pendiente; si no lo hace ninguno, el modelo integrado compone la respuesta directamente, invocando cuantas herramientas gobernadas requiera la solicitud y devolviendo un texto fundamentado y respaldado por datos. El panel se mantiene actualizado mediante un sondeo adaptativo que se acelera durante los intercambios activos y se relaja cuando el hilo está en calma.

El segundo flujo es autónomo. Un usuario programa una tarea y el elemento se incorpora a la cola del worker con una prioridad y, cuando se define, una hora de ejecución futura. El planificador recoge los elementos en cola, los ejecuta a través del modelo contra el conjunto de herramientas en vivo con un número acotado de pasos de razonamiento, y registra el desenlace. Una tarea que se completa sin incidencias se marca como tal; aquella en la que todas las acciones tuvieron éxito pero algunas fueron denegadas o dieron error se expone con honestidad como un resultado parcial, con un aviso claro para revisión humana; y una que fracasa por completo se registra como fallida. El tercer flujo es entrante: los asistentes externos se conectan al propio endpoint de protocolo de la plataforma y operan las mismas herramientas gobernadas bajo la aplicación de alcances, de modo que las capacidades de un worker están disponibles dentro de las herramientas que las personas ya utilizan en otros entornos.

Lo que hace fiable al módulo es que la capacidad y la autoridad nunca se separan. Los permisos se aplican en el momento en que se ejecuta una herramienta, y no simplemente cuando se pone una tarea en cola, de modo que un cambio de rol o la suspensión de un worker surte efecto en la acción inmediatamente siguiente. Cada herramienta declara un alcance, y ese alcance se corresponde con un par de permisos concreto que se comprueba contra el rol del worker antes de que la herramienta haga nada; un worker que carezca del derecho devuelve un resultado limpio de permiso denegado en lugar de actuar. Si los permisos de un worker no pueden cargarse por cualquier motivo, el sistema resuelve denegándolo todo, fallando de forma segura por construcción.

La postura de seguridad está estratificada en consonancia. El acceso interactivo se ejecuta bajo sesiones autenticadas con comprobaciones de capacidad en cada ruta. El despacho saliente hacia los asistentes externos se firma con un código de autenticación de mensaje basado en clave, de modo que los destinatarios puedan verificar el origen, y cada despacho lleva el contexto del worker, un fragmento acotado del historial de conversación y una dirección de callback de un solo uso. Las callbacks entrantes se autentican con un bearer token que se coteja contra un hash almacenado, están limitadas en frecuencia por worker, acotadas en tamaño y son idempotentes, de modo que una entrega reintentada nunca duplica una respuesta. Los intercambios obsoletos caducan mediante un temporizador, los asistentes inaccesibles se monitorizan en cuanto a su salud y se retiran de forma automática, y cada creación de mensaje se registra en la auditoría con la identidad que actúa y la dirección de origen. El resultado es autonomía con rastro documental: los workers actúan con rapidez, pero siempre dentro de un límite que puede inspeccionarse a posteriori.

AI Workers es el tejido conectivo de Nashua 360, y no una isla. A través del registro compartido de herramientas, un worker accede directamente a Business Relations para leer y mantener empresas, contactos y ubicaciones; a Accounting and Control para interrogar las facturas de deudores y acreedores y el panorama financiero más amplio; a Catalog Management para buscar en el catálogo estratificado de productos y servicios; y a Test Management y al módulo central System para obtener metadatos y diagnósticos de la plataforma. Cada uno de estos accesos está controlado por la misma correspondencia de rol a alcance, de modo que un worker creado para finanzas ve el libro contable pero no el catálogo, a menos que su rol indique lo contrario.

Dado que el módulo reside en el núcleo de la plataforma, junto a los roles y al registro de módulos, hereda íntegramente el modelo de identidad y autorización del conjunto en lugar de reinventarlo. El rol de un worker se expresa en la misma gramática de permisos que la de un usuario humano, lo que significa que la gobernanza, la revisión y el diseño de mínimo privilegio son una única disciplina, tanto para las personas como para los workers sintéticos. Cualquier capacidad nueva añadida a un módulo pasa a estar disponible para los workers en el momento en que se registra su herramienta, de modo que la superficie conversacional y autónoma crece al ritmo del resto de Nashua 360 sin necesidad de trabajos de integración a medida.

Dentro del módulo, los workers son los actores, y su alcance es amplio. Responden a preguntas consultando datos de módulos en vivo y devolviendo resúmenes fundamentados, de modo que un usuario puede pedir un saldo pendiente de un acreedor o la actividad reciente de un cliente y recibir una respuesta extraída del estado actual del libro contable y de los registros de relaciones, en lugar de un informe almacenado. Ejecutan acciones bajo petición o según lo programado, creando y actualizando registros, generando elementos de trabajo e impulsando procesos de varios pasos a través de un bucle de razonamiento acotado. Vigilan las anomalías y las excepciones y, cuando una tarea programada termina con acciones denegadas o fallidas, emiten una notificación de advertencia y un mensaje de sistema claro en lugar de dejar pasar un resultado parcial en silencio.

Procesan documentos y entradas no estructuradas, extrayendo campos estructurados para su uso posterior, y apoyan la toma de decisiones reuniendo y explicando los datos que hay detrás de una elección. Y lo que es crucial: un worker puede actuar como nodo de aprobación o revisión dentro de un workflow: al encaminarse una solicitud bajo su propia identidad con permisos, evalúa el elemento frente a su rol y sus instrucciones, registra su determinación en el rastro de la conversación y, o bien hace avanzar el proceso, o bien lo devuelve para la atención de una persona. Dado que todo lo que hace un worker se ejecuta a través de las mismas herramientas gobernadas, las mismas comprobaciones de permisos y el mismo registro de auditoría que cualquier otro actor del conjunto, un AI Worker es un colega genuino dentro del proceso, responsable y acotado, y no una automatización opaca que corre al margen de él.