OpenAI acaba de lanzar AgentKit en DevDay y los demos se ven limpios: constructores visuales de flujos, interfaces de chat embebidas, frameworks de evaluación. Ramp pasó de lienzo en blanco a un agente comprador en horas en vez de meses. LY Corporation construyó un flujo multi-agente en menos de dos horas.

Pero esto es lo que el post de lanzamiento no te dice: la mayoría de esos demos van a topar con una pared antes de llegar a producción.

Qué envió AgentKit realmente

AgentKit son tres cosas empaquetadas juntas:

Agent Builderte da un canvas visual para componer la lógica del agente. Nodos de arrastrar y soltar, configuración de evaluación en línea, versionado completo. Puedes ver todo el flujo en lugar de depurar código de orquestación a las 2 AM.

ChatKitse encarga de las partes molestas de la UI de chat: respuestas en streaming, gestión de hilos, indicadores de escritura. Emébelo en tu producto, personaliza el tema, y listo.

Evals + RFTte permite medir el rendimiento del agente con datasets, calificación de trazas y optimización automática de prompts. Fine-tuning por refuerzo en o4-mini y GPT-5 (beta privada) para que los modelos llamen las herramientas correctas en el momento correcto.

Es un avance real en la velocidad de desarrollo de agentes. Flujos que antes tomaban meses ahora se construyen en horas.

La pared de autenticación y autorización

El problema es este: AgentKit hace fácil construiragentes. No resuelve cómo esos agentes realmente se autentican y autorizanen producción.

AgentKit viene con soporte nativo de MCP (Model Context Protocol). MCP estandariza cómo los agentes se conectan a herramientas y fuentes de datos. Dropbox, Google Drive, SharePoint, Microsoft Teams, todos disponibles a través del Connector Registry.

Pero MCP fue diseñado para escenarios locales de un solo usuario. TU Claude Desktop personal conectándose a TU sistema de archivos personal. Un usuario, una máquina, sin complejidad de auth.

El 99% de los servidores MCP hoy siguen construidos así, incluso los hospedados. Funcionan bien en demos, pero estos setups representan riesgos de seguridad graves para flujos desatendidos como Claude Code Routines. Se rompen en producción cuando necesitas:

  • Autenticación: flujos OAuth seguros para que los agentes accedan a APIs de terceros en nombre de los usuarios
  • Autorización: permisos por usuario que garantizan que los agentes solo accedan a lo que cada usuario tiene permitido ver
  • Gestión de tokens: lógica de refresco a nivel producción, almacenamiento seguro y validación de scopes
  • Registros de auditoría: logs que muestran qué acción de AI ocurrió en nombre de qué usuario y con qué permisos

Esto es lo que mata al 70% de los proyectos de AI antes de llegar a producción. No la lógica del agente. La capa de auth.

Qué requiere realmente la auth de agentes lista para producción

La diferencia entre “funciona en un demo” y “llega a producción” se reduce a unos cuantos problemas difíciles:

Flujos OAuth que no sean un dolor. Tu agente necesita acceder a Gmail, Slack, Salesforce, herramientas que requieren OAuth. Construir y mantener integraciones OAuth para docenas de servicios es meses de trabajo. Luego necesitas manejar el refresco de tokens, cambios de scopes, versionado de APIs y casos extremos que solo aparecen a escala.

Autorización por usuario, no bot tokens. La mayoría de los demos de agentes usan una sola API key o bot token con acceso de administrador. Está bien para un prototipo. En producción, necesitas que cada acción del agente se mapee a un usuario específico con los permisos adecuados. Tu equipo legal preguntará: “¿Qué usuario autorizó esta acción? ¿Cuáles eran sus permisos? ¿Podemos demostrarlo en una auditoría?”

Gestión de tokens que no filtre credenciales. Almacenar tokens OAuth de forma segura, refrescarlos antes de que expiren, manejar la revocación: todo esto es trabajo pesado e indiferenciado. Hazlo mal y estás violando requisitos de cumplimiento. Hazlo bien y construiste algo que cada otro equipo de AI también necesita construir.

Infraestructura de producción. Monitorear qué acciones del agente tuvieron éxito o fallaron. Rate limiting para no saturar las APIs. Logging para depuración. Hooks de evaluación para medir el rendimiento. Nada de esto es glamoroso, pero todo es obligatorio para despliegues en producción.

Cómo lo resuelve Arcade.dev

Exactamente para esto fue construido Arcade.dev: darle a los agentes de AI acceso seguro y autenticado a herramientas empresariales reales.

Integraciones OAuth preconfiguradaspara Gmail, Slack, Notion, Stripe, Salesforce y más de 100 servicios. Construidas y mantenidas por el equipo que desplegó auth a escala (Okta, Stormpath). No escribes código OAuth. Configuras los scopes y dejas que Arcade.dev se encargue del resto.

Autorización por usuario por defecto. Cada acción del agente ocurre como el usuario final, con sus permisos, a través de su conexión autorizada. Sin bot tokens compartidos ni hacks de acceso administrador.

Gestión de tokens a nivel producción. Lógica de refresco, almacenamiento seguro, validación de scopes, manejo de errores. Tu código de agente nunca toca credenciales en crudo.

Observabilidad y evaluación. Monitoreo, logging, rate limiting y hooks de evaluación integrados. Todo lo que necesitas para operar agentes a escala.

La arquitectura es directa: construyes tus flujos de agente (en AgentKit, LangGraph, CrewAI, lo que sea) y Arcade provee la capa de herramientas autenticadas por debajo. Ya sea que estés construyendo un agente comprador o un asistente para flujos de guardia de SRE, tu agente llama arcade.send_email() y Arcade maneja el flujo OAuth, el refresco de tokens y la autorización del usuario.

Por qué esto importa ahora

AgentKit acaba de hacer mucho más fácil construirflujos de agente. Eso va a generar una ola de equipos topando con la pared de autenticación en las próximas semanas.

Lo verás cuando intentes conectar tu agente a la cuenta de Gmail de un usuario. O cuando tu equipo de cumplimiento pregunte cómo estás manejando el almacenamiento de tokens OAuth. O cuando te des cuenta de que tu demo funciona perfecto con tus propias API keys pero se rompe cuando intentas desplegarlo para múltiples usuarios.

La buena noticia: este es un problema resuelto. No necesitas construir tu propia infraestructura OAuth. No necesitas mantener integraciones para docenas de servicios. No necesitas resolver la autorización por usuario desde cero.

Arcade.dev maneja la capa de auth para que puedas enfocarte en construir flujos de agente.

*La próxima semana enviamos soporte MCP para Arcade.devque hace aún más fácil conectar frameworks de agentes como AgentKit a herramientas autenticadas.* Únete a nuestro Discord para actualizaciones o regístrate en Arcade.dev *para quedar en nuestra lista de correo.*

Si ya estás construyendo agentes y ya topaste con problemas de auth, aquí estamos. Empieza con nuestra guía de inicio rápido o contáctanos directamente, ayudamos a equipos a lanzar agentes a producción todos los días.