Workday se vuelve headless para los agentes de IA: las reglas de negocio viajarán con cada petición

“Headless no puede significar sin ley.” Gabe Monroy, director de tecnología de Workday, resumió todo el anuncio en una frase en Workday Rising, el 13 de octubre.

Un software headless expone sus funciones sin sus propias pantallas, para que otras aplicaciones lo manejen. Para un sistema de registro que guarda nóminas, puestos, aprobaciones y el libro mayor, volverse headless para los agentes de IA es un paso importante. Workday lo dio en dos direcciones a la vez.

Agentes que entran

La Trusted Agent Platform de Workday tiene disponibilidad general (GA) en sus piezas centrales:

• Agent Harness, que ejecuta todos los agentes creados por Workday, por clientes o por socios, aporta el rol, la línea jerárquica, los permisos y las políticas de quien hace la petición, gobierna cada acción y envía el trabajo a los modelos según costo y rendimiento;
• Agent-Ready Tools, las herramientas MCP de Workday, en GA en Workday Extend AI, que permiten a cualquier agente compatible con MCP leer datos de Workday y ejecutar acciones;
• Workday Data Cloud, incluido Live Data Query, que permite a usuarios y agentes lanzar SQL sobre datos vivos de Workday en lugar de informes a medida o copias desactualizadas;
• Developer Agent y Custom Agents en Extend AI, para crear agentes que se ejecutan en el harness.

Entre los modelos disponibles están Claude, Gemini, Llama, Mistral, GPT y NVIDIA Nemotron. El soporte de LangChain está en GA; el de Google ADK todavía busca socios de diseño. Dos servicios del harness aún no han llegado: Agent Context Service está previsto en acceso anticipado a finales de 2026 y Grounded Reasoning en acceso anticipado a principios de 2027.

Workday que sale

El segundo anuncio va en sentido contrario. Sana, el motor de experiencia y orquestación de agentes de Workday, llega a Claude, Gemini Enterprise, Microsoft Copilot, Teams y Slack. El autoservicio con Sana ya está en GA en Gemini Enterprise, Copilot, Teams y Slack; la experiencia completa de Sana en esas plataformas está prevista para finales de 2026. Sana en Claude Cowork está en acceso anticipado, y se espera un MCP de Sana para Microsoft Copilot en acceso anticipado a finales de 2026. Anthropic y Workday anunciaron además una alianza en torno a esta conexión.

La postura de Workday sobre esa salida es clara: “Las herramientas y plataformas de IA de terceros nunca obtienen acceso directo a los datos de Workday.” Un empleado puede iniciar una petición en Copilot o en Claude; Sana la envía a los agentes de Workday, comprueba políticas y aprobaciones y “guarda el plan elegido en Workday con una pista de auditoría completa”.

Dónde se toma cada decisión en el diseño de Workday

Interfaz

• Claude
• Copilot
• Teams
• Slack
• Agentes del cliente

Puertas de entrada intercambiables

Razonamiento y orquestación

• Cualquier modelo compatible
• Sana
• Agent Harness

Planifica el trabajo, elige el modelo

Autorización

• Identidad de quien pide
• Permisos de Workday
• Cadenas de aprobación

Se decide en Workday, en cada petición

Ejecución y registro

• Transacción de negocio
• Pista de auditoría

Nunca sale del sistema de registro

Por qué la arquitectura importa más que las funciones

Los equipos empresariales han construido asistentes de RR. HH. y finanzas sobre todo copiando datos hacia fuera: informes a un data warehouse, extracciones a un índice vectorial, una cuenta de servicio con amplios permisos de lectura. Cada copia necesita su propio modelo de acceso, y la cuenta de servicio ve más de lo que debería ver cualquier empleado. Describimos el costo de ese patrón en un agente de RR. HH. sin una segunda copia de Workday.

El diseño de Workday lo invierte. El agente va a los datos con la identidad de quien pide, y la autorización se decide donde ya viven las reglas de negocio. Es el mismo principio que aplica SAP al mantener los agentes de Joule dentro del sistema transaccional: los controles que ya funcionan se heredan, no se reconstruyen. La diferencia es que Workday lo ofrece ahora a agentes que no construyó y a interfaces que no controla.

Lo que el anuncio no resuelve

“Todos los agentes, ya los cree Workday, un cliente o un socio, trabajan con los mismos permisos, aprobaciones y pistas de auditoría de Workday”, según el comunicado. Eso se cumple cuando el agente pasa por Agent-Ready Tools o Live Data Query con la identidad de quien pide. No cubre automáticamente lo que ocurre al otro lado de la llamada:

• Lo que sale. Los resultados que recibe un agente externo quedan en su contexto, en sus logs y quizá en su memoria, bajo las reglas de retención de la otra plataforma, no las de Workday.
• Con qué identidad. Un agente que llama a Workday con una identidad de integración amplia, y no con la del empleado, obtiene los permisos de la integración. La plataforma admite el patrón correcto; la integración tiene que usarlo.
• Dos pistas de auditoría. Workday registra la transacción; el asistente donde empezó la petición registra la conversación. Reconstruir un incidente exige ambas, unidas por algo que los dos lados registren.
• Licencias. Agent-Ready Tools, Custom Agents y Developer Agent están en GA en Workday Extend AI. Compruebe qué tiene su tenant antes de diseñar sobre ellos.

Qué hacer con esto

Para quien planifica agentes de RR. HH. o finanzas, la elección práctica ha cambiado. Antes de montar otra extracción, pregúntese si el agente puede llamar a las herramientas de Workday con la identidad del empleado. Documente qué puertas de entrada pueden iniciar qué transacciones. Y trate los logs y la memoria del asistente externo como parte del patrimonio de datos de RR. HH., porque después de la primera llamada lo son.