Oracle abre AI Agent Studio a Codex y Claude Code: el agente entra al gobierno de Fusion

El 14 de julio de 2026, Oracle presentó una experiencia de construcción nativa para crear y ejecutar aplicaciones agentic dentro de Oracle Fusion Cloud Applications. La parte que merece atención de los builders no es solo otro canvas empresarial: la compañía también anunció una AI Studio Skill para que equipos de desarrollo trabajen desde VS Code, Git, CLIs, OpenAI Codex y Claude Code sin salir del marco de gobierno de Fusion.

Dos caminos para el mismo perímetro

Oracle separa la creación según quién construye. Los usuarios de negocio pueden empezar con lenguaje natural en Agentic Applications Builder. Los desarrolladores y partners pueden usar la AI Studio Skill con sus herramientas habituales y entregar el resultado en el entorno de Fusion.

La diferencia importa porque evita una fractura común: el prototipo nace en una herramienta visual, pero el sistema real termina reescrito en otro stack para añadir control de versiones, permisos y despliegue. En el anuncio, ambos caminos apuntan a aplicaciones agentic que ejecutan trabajo dentro de Fusion y heredan controles de seguridad, gobierno y auditabilidad.

La documentación de AI Agent Studio describe una integración directa con los almacenes de conocimiento, herramientas y APIs de Fusion. Es decir, el agente no se limita a conversar sobre procesos: puede entrar en el flujo donde ya viven los datos y las acciones empresariales.

Qué cambia para un equipo de builders

La AI Studio Skill no convierte Codex o Claude Code en administradores omnipotentes de un ERP. Su valor está en ofrecer una ruta de trabajo conocida —código, Git, revisión y automatización— mientras el sistema empresarial conserva el perímetro de autorización.

Antes de probarla, conviene separar tres capas:

1. Construcción: repositorio, instrucciones, skill y pruebas que usa el equipo.
2. Contexto: qué APIs, conocimientos y procesos de Fusion puede consultar el agente.
3. Ejecución: qué acciones requieren aprobación, qué identidad las firma y qué queda en el registro de auditoría.

Si las tres capas quedan mezcladas en un prompt, el piloto será difícil de revisar. Si quedan como contratos visibles, es más fácil comparar un agente de lectura con uno que actualiza datos o inicia un proceso.

El trade-off: integración profunda contra portabilidad

El beneficio principal es la cercanía con los datos y procesos de Fusion. El costo es el acoplamiento: una skill diseñada para el marco de Oracle no es automáticamente portable a otro ERP o a una aplicación independiente. Eso no es un defecto si el problema ya vive en Fusion, pero sí cambia la decisión de arquitectura.

También hay que evitar una interpretación peligrosa de “builder para todos”. Que un usuario pueda describir un agente no significa que deba recibir permisos para publicar cambios. Las aprobaciones, los entornos de prueba y la revisión de los resultados siguen siendo necesarios, especialmente para nómina, compras, finanzas y recursos humanos.

Un piloto sensato empieza con una tarea de bajo riesgo: preparar un resumen de incidencias, clasificar solicitudes o proponer un siguiente paso con enlaces a la evidencia. Mide exactitud, correcciones humanas, tiempo de ejecución y acciones que el agente intentó realizar. Solo después prueba una escritura reversible en un entorno no productivo.