Workday headless: agentes externos y datos de RR.HH.

En pocas palabras: Workday headless es la apertura de su plataforma a agentes externos como Claude Code o Cursor: desde el 13 de octubre de 2026, el servidor MCP (275 herramientas de lectura, 54 de escritura), el acceso SQL y el runtime están disponibles en general, siempre con los permisos del usuario.

Workday headless es el modelo que Workday anunció el 13 de octubre de 2026: servidor MCP, SQL sobre datos en vivo y runtime de agentes ya son GA, y agentes externos de Claude Code o Cursor trabajan con datos de RR.HH. y finanzas bajo los permisos del usuario.

Workday headless es la posibilidad de operar la Trusted Agent Platform de Workday sin pasar por su interfaz: un agente externo se conecta por MCP (Model Context Protocol) o por SQL, inicia sesión con las credenciales de un usuario y hereda sus permisos, aprobaciones y auditoría. Workday lo presentó en Workday Rising, en Las Vegas, según The New Stack.

¿Qué es Agent-Ready Tools, el servidor MCP de Workday?

Agent-Ready Tools es el servidor MCP de Workday y viene dentro de Workday Extend AI. El usuario inicia sesión con sus propias credenciales y, según Workday, un agente que actúa por él no puede llegar a nada que su cuenta no vea. Monroy dijo en la reunión de prensa previa al evento que hoy el servidor tiene 275 herramientas de lectura y 54 que escriben o borran datos.

Alrededor de ese servidor, la cobertura de The New Stack describe otras piezas que también están disponibles en general:

• Live Data Query. Es parte de Workday Data Cloud y deja que herramientas de BI y agentes corran SQL sobre los datos en vivo. Monroy lo describió como acceso JDBC al grafo de objetos de Workday, y cada consulta devuelve solo lo que el usuario puede ver.
• Agent Harness. Es el runtime compartido de los agentes de Workday, de clientes y de partners. Le pasa a cada agente la identidad del usuario, su posición en la organización y sus derechos de acceso, limita lo que puede hacer y elige qué modelo atiende cada tarea según costo y rendimiento.
• Developer Agent. Genera agentes y apps de Workday a partir de un prompt en lenguaje natural, desde Claude Code, Codex, Cursor o el Workday Developer Site.
• Custom Agents. Sirve para desplegar sobre Agent Harness agentes hechos con LangChain o con el Agent Development Kit (ADK) de Google. Ojo: al 13/10/2026, el soporte de ADK está limitado a design partners.

Los clientes pueden correr sus agentes con modelos de Anthropic, Google, Meta, Mistral, Nvidia y OpenAI.

Workday informa que los clientes construyeron más de 500 agentes y más de 6.000 apps con Developer Agent y Agent-Ready Tools en cuatro meses. Son datos de la empresa, sin auditoría externa. Lo que más miraría yo son las 54 herramientas de escritura: leer un dato de más es un problema, pero mover a un empleado de equipo es una acción con consecuencias.

¿Cómo evita Workday headless que un agente externo vea datos que no debería?

Workday sostiene que el agente corre bajo los permisos, las aprobaciones y la auditoría del usuario, sin importar quién lo construyó. Agent Harness le pasa la identidad y los derechos de acceso, y limita sus acciones. Monroy lo resumió así: “ningún agente tiene una puerta lateral” (traducción nuestra del original en inglés). Cubrimos ese tema en detalle en la apuesta de Meta con sus agentes empresariales.

Para mostrarlo, Monroy hizo una demo que llamó “headless, the lawless way”. Un agente conectado a un servidor MCP propio, una configuración que según él Workday ve seguido en sus clientes, devolvió requisiciones de empleo que el usuario no debía ver y movió a un empleado equivocado de equipo sin aprobación. Apuntado a una copia de los datos en Snowflake, el mismo agente entregó el sueldo del CTO cuando se lo pidieron. Con el servidor MCP de Workday y Data Cloud, y el usuario logueado, las mismas consultas devolvieron solo lo permitido.

Tomalo con pinzas: es una demo de Workday, armada para mostrar su producto, y de hecho tenía que salir bien. Además, SAP, Microsoft y otros proveedores sostienen que también tienen control de acceso en sus sistemas, y Salesforce, ServiceNow y Microsoft dicen que los agentes externos respetan sus modelos de permisos. ¿Alguien probó la promesa de Workday de forma independiente? Todavía no hay evidencia en las fuentes.

Un escenario hipotético, no uno que Workday haya descrito, para ver el riesgo real: armás un agente en Cursor, lo conectás a un MCP casero con una cuenta de servicio, lo probás con datos de tu equipo, anda bárbaro, lo compartís con toda el área y a la semana alguien pregunta por salarios y el agente responde, porque la cuenta de servicio ve todo y nadie le puso un filtro por usuario.

¿Por qué Workday dice que un data lake no sirve para construir agentes?

Para Monroy, un lake externo es “el lugar equivocado para construir agentes” que necesitan acceso gobernado a Workday. Su argumento, citado por The New Stack: “podés exportar tus datos, pero no podés exportar las reglas que los gobiernan” (traducción nuestra). Rehacer esas reglas en el lake implica mantener una segunda copia del modelo de seguridad de Workday, y el día que se desfasa, dijo, todo queda mal.

Los lakes siguen teniendo sentido para analítica y para cruzar datos de Workday con el resto de la empresa, y el propio Monroy lo admite. Ya lo cubrimos antes en empresas que operan casi sin empleados gracias a la IA.

El ejemplo de Snowflake es incómodo para Workday. Cuando la empresa presentó Data Cloud en 2025, el discurso incluía compartir datos sin copiarlos con Databricks, Salesforce y Snowflake. Snowflake pasó su integración con Workday Data Cloud a disponibilidad general el 7 de octubre, y Databricks puso su conector con Unity Catalog en beta pública un día después. Según Databricks, el administrador de Workday registra un Integration System User (ISU) con acceso de lectura a las tablas compartidas, y después los permisos de Unity Catalog (catálogo, esquema, tabla) deciden quién consulta.

Mi lectura: el argumento tiene mérito para agentes que ejecutan acciones, pero también conviene a Workday, que quiere que el tráfico pase por su runtime.

¿Con qué identidad actúa un agente en Workday headless: la del usuario o una propia?

En Workday, el agente actúa con la identidad del usuario que inició sesión. Según la documentación de Workday, además puede tener hasta dos Agent System Users (ASU): uno para actuar en nombre del usuario y otro “ambient”, cada uno con su cliente OAuth 2.0. Workday crea el ambient automáticamente cuando el cliente activa una habilidad ambient. Otros proveedores eligen caminos distintos.

Enfoque	Quién lo dice	Identidad del agente	Qué ve el agente
MCP de Workday con Agent Harness	Workday (documentación)	Usuario logueado y hasta 2 ASU por agente, cada uno con OAuth 2.0	Lo que ve el usuario
Salesforce (en preparación)	Salesforce Ben, fuente secundaria	Credenciales propias por OAuth, en vez de la identidad del usuario	Los permisos asignados al agente
MCP de terceros hacia Workday	Unified.to y Cequence	ISU con grupos de seguridad	Lo que permitan esos grupos, sin importar quién le habla
Copia en Databricks	Databricks	ISU con lectura sobre tablas compartidas	Lo que definan los permisos de Unity Catalog

Separemos quién dice qué. Lo de Workday es documentación de Workday. Lo de Salesforce viene de Salesforce Ben, no de un anuncio de la empresa. Y la afirmación de que toda vía MCP hacia Workday, “oficial o no”, arranca con un ISU es de Unified.to, que vende justamente una integración de ese tipo.

¿Qué límites tiene el headless de Workday y qué viene después?

El límite lo puso Gerrit Kazmaier, presidente de producto y tecnología de Workday: construir directo sobre las herramientas y APIs de Workday solo sirve para “un conjunto pequeño de casos” que no necesitan lógica de dominio de RR.HH. o finanzas. Para todo lo demás, el camino es una integración entre IA: Claude le pasa pedidos a Sana, el orquestador de agentes de Workday, que llama a los agentes de dominio de la propia empresa. Tema relacionado: el movimiento similar de Salesforce hacia lo headless.

Kazmaier también dijo que prefiere que los clientes usen la interfaz de Workday, pero que headless será “igual de bueno”. Y la nota de The New Stack marca lo evidente: la versión de headless que Workday espera que use la mayoría tiene su runtime en el medio de cada llamada. Es una apertura, sí, con peaje.

En la hoja de ruta, con acceso anticipado a principios de 2027, hay dos piezas:

• Agent Context Service. Precarga solo los datos de Workday que necesita la tarea, lo que según Workday acelera al agente y limita su exposición a registros sensibles.
• Grounded Reasoning. Chequea una acción planeada contra las políticas del cliente, las reglas de proceso y los registros de Workday antes de ejecutarla.

El mercado va para el mismo lado. Salesforce lanzó Headless 360 en abril, ServiceNow hizo disponible Action Fabric MCP en mayo con Anthropic como socio de lanzamiento, y Microsoft tiene un servidor MCP para Dynamics 365 ERP.

¿Qué está confirmado y qué no?

Confirmado por Workday

• Servidor MCP, Live Data Query, Agent Harness, Developer Agent y Custom Agents están disponibles en general desde el 13/10/2026.
• Las cifras de 275 herramientas de lectura, 54 de escritura, más de 500 agentes y más de 6.000 apps son de Workday.

Pendiente o sin verificar

• Agent Context Service y Grounded Reasoning: acceso anticipado a principios de 2027.
• Custom Agents con ADK de Google: al 13/10/2026, solo design partners.
• La demo de permisos: no hay réplica independiente en las fuentes.
• El cambio de Salesforce a credenciales propias para agentes: lo informa Salesforce Ben, sin confirmación en las fuentes de esta nota.

¿Cómo verificar los permisos de un agente antes de producción?

Una propuesta editorial nuestra, que no sale de Workday ni probamos: antes de conectar un agente a datos de RR.HH. o finanzas, corré el mismo prompt con dos usuarios de permisos distintos y comparé las respuestas.

• Pedí un dato que el usuario acotado no debería ver. Un salario o una requisición ajena sirven. Si aparece, cortá ahí.
• Revisá el tipo de cuenta. Usuario, ASU o ISU, y qué grupos de seguridad tiene asignados.
• Probá una herramienta de escritura. Confirmá que pasa por aprobaciones y que la auditoría registra la identidad correcta.

Errores comunes

• Creer que “headless” significa sin controles. Según Workday cambia la puerta de entrada, no las reglas. Corrección: verificá igual qué cuenta usa el agente.
• Conectar con una cuenta de servicio genérica. Un agente que trabaja con un ISU ve lo que permitan sus grupos de seguridad, sin importar quién lo use. Corrección: acotá esos grupos o usá una vía con identidad de usuario.
• Construir agentes que actúan sobre una copia en el lake. Monroy recomienda el lake para analítica, no para acciones. Corrección: separá reporting de agentes operativos.
• Tomar la demo como prueba. Es del fabricante. Corrección: replicala con tus datos y tus roles.

Preguntas Frecuentes

¿Qué significa que Workday sea headless?

Significa que agentes y herramientas externas pueden operar sobre Workday sin usar su interfaz, por MCP o SQL. Workday anunció el 13 de octubre de 2026 que su Trusted Agent Platform es headless. El agente corre bajo los permisos, aprobaciones y auditoría del usuario.

¿Qué puede hacer un agente con el servidor MCP de Workday?

Puede usar 275 herramientas de lectura y 54 de escritura o borrado, según Monroy. Todo se ejecuta con la cuenta del usuario que inició sesión. Para cruzar datos, Live Data Query agrega SQL sobre los datos en vivo. Te puede servir nuestra cobertura de agentes que generan su propia interfaz dinámica.

¿Puede un agente externo ver datos de RR.HH. que el usuario no puede ver?

Con el servidor MCP de Workday, según la empresa, no. El agente solo accede a lo que la cuenta del usuario puede ver. Si la conexión usa un ISU o una copia en un lake, el agente ve lo que permitan esos permisos, sin importar quién le habla.

¿Se puede usar Claude Code o Cursor con Workday?

Sí. Developer Agent genera agentes y apps de Workday desde un prompt en Claude Code, Codex, Cursor o el Workday Developer Site, y está disponible en general. Los agentes resultantes corren bajo los permisos del usuario.

¿Qué diferencia hay entre conectar un agente por MCP o a una copia en Snowflake?

Con el MCP de Workday, el agente hereda permisos, aprobaciones y auditoría del usuario. En una copia, esas reglas hay que reconstruirlas en el lake. Según Monroy, en la demo el agente apuntado a Snowflake devolvió el sueldo del CTO.

Conclusión

Workday abrió el acceso a sus datos de RR.HH. y finanzas a agentes externos con una condición: que pasen por sus permisos, aprobaciones y auditoría. Para un equipo de TI, el cambio práctico es decidir con qué identidad entra cada agente: usuario, ASU o ISU. Esa decisión define qué puede ver y hacer.

Mi recomendación: si vas a probar el servidor MCP, empezá con casos de lectura y un par de usuarios de prueba con roles distintos, y dejá las herramientas de escritura para después de revisar la auditoría. Y recordá que las cifras y la demo son de Workday. Hasta que haya pruebas independientes, la verificación con tus propios roles es lo que cuenta.

Fuentes

• The New Stack – Workday goes headless, opening its HR and finance data to outside AI agents (13/10/2026)