API de Notion: agentes externos y créditos desde el 11 de agosto

Notion estrenó su Developer Platform el 13 de mayo con Workers, una External Agent API y una CLI que integra a Claude Code, Cursor y Codex como participantes nativos del espacio de trabajo. La API de Notion apunta mucho más alto de lo que parece: quiere convertirse en el plano de control de los agentes. Y hay una fecha que conviene marcar en el calendario: el 11 de agosto.

Qué trae la plataforma y la API de Notion

El lanzamiento reúne seis piezas fundamentales. Workers ofrece un entorno alojado para Node/TypeScript, está en beta pública y solo se incluye en los planes Business y Enterprise. External Agents llega en Alpha, con integraciones listas para usar con Claude Code, Cursor, Codex y Decagon. La External Agent API permite crear agentes personalizados y mantiene una lista de espera para su beta privada. La CLI se llama ntn, está disponible en todos los planes y se instala con curl -fsSL https://ntn.dev | bash. También hay sincronización de bases de datos mediante Workers para Zendesk, Salesforce y Postgres, además de activadores webhook capaces de llevar eventos desde cualquier aplicación hasta Notion a través de un Worker. Fuente: anuncio de la Developer Platform de Notion.

Hay otras dos señales importantes. El Notion Agent SDK (Alpha, con lista de espera) permite insertar Notion Custom Agents en MS Teams, Discord, Amplitude y Hex. La gobernanza también viene incluida: confianza progresiva para las acciones de los agentes, Workers aislados y autenticación y permisos específicos para cada despliegue.

La lectura operativa

El verdadero titular no es «Notion lanza un SDK», sino «Notion se declara el espacio de trabajo de los agentes». Cuando Claude Code, Cursor, Codex y Decagon aparecen en la barra lateral como agentes asociados, el IDE deja de ser la capa de orquestación indiscutible. Esa posición ya está en disputa.

La demostración de las notas de la versión del 13 de mayo deja claro el circuito: Decagon recibe una solicitud de soporte, entrega el error a un agente de programación y devuelve la corrección a un equipo para su aprobación. Hoy ese proceso se reparte entre tres aplicaciones y un hilo de Slack. Notion quiere concentrarlo en una sola interfaz.

Quien controla el espacio de trabajo también controla la carga de las integraciones. Ahora Notion pretende cobrársela a los proveedores de agentes, no a los proveedores de CRM. Ese es el cambio de fondo.

El argumento contrario es que la mayoría de los equipos de operaciones ya tiene una interfaz predeterminada: su CRM, su herramienta de gestión de proyectos o un panel administrativo propio. La incógnita es si la propuesta de Notion —centrada en bases de datos y agentes, y diseñada primero para el navegador— podrá aprovechar la inercia de los equipos que ya trabajan allí. Para quienes no usan Notion como centro de trabajo, nada cambia. Para quienes sí lo hacen, cambia el cálculo entre desarrollar o comprar cada herramienta interna que estaban a punto de montar.

El cambio a créditos del 11 de agosto

Workers será gratuito durante la beta pública. A partir del 11 de agosto de 2026, su uso consumirá créditos de Notion. La tarifa por crédito todavía no se ha revelado. Ahí están tanto la oportunidad asimétrica como la trampa.

La oportunidad: hoy se puede desarrollar sobre Workers sin pagar. Si antes del 10 de agosto se ponen en producción tres sincronizaciones y dos herramientas para agentes, el costo de integración habrá sido cero. Esperar significa tener que migrar para evitar la tarifa que publique Notion, con un modelo de precios por créditos que no estaba contemplado en la hoja de ruta.

Veamos las cifras. Una sincronización cada 5 minutos genera 8,640 ejecuciones al mes. Tres sincronizaciones suman 25,920 ejecuciones mensuales. En Notion, después del 10 de agosto, el costo sigue siendo una incógnita. Si la tarifa queda por debajo de $1 por millón, será una capa de integración muy barata y tendrá sentido trasladar todo lo que toque datos de Notion. Si llega a $5+ por millón, Cloudflare conservará la parte del mercado más sensible al precio y Notion Workers quedará reservado para tareas centradas exclusivamente en datos de Notion.

La trampa: no conviene trasladar cargas que ya son deterministas y baratas en la infraestructura actual. Solo deberían moverse las que ganan valor por estar junto a los datos de Notion: sincronizaciones que leen de Notion, herramientas de agentes que escriben en Notion y webhooks que distribuyen información hacia bases de datos de Notion. Todo lo demás puede quedarse donde está.

Qué pondría en producción esta semana

Primero, instalar la CLI. curl -fsSL https://ntn.dev | bash, autenticarse y listo. Es gratuita y no exige un plan específico de la plataforma. Guía de la CLI.

Después, crear un Worker que justifique por sí solo su existencia: una herramienta determinista que los Custom Agents utilicen 50+ veces por semana. Por ejemplo, lookup-customer-by-email, push-task-to-Linear o generate-weekly-report. Consume pocos tokens, no necesita razonamiento de un LLM y se ejecuta dentro del entorno aislado. Guía de herramientas.

También pondría en marcha una sincronización que antes no justificaba el esfuerzo: enviar una tabla de Postgres, los pagos de Stripe o el estado de los PR de GitHub a una base de datos de Notion. Workers se ocupa de la programación y las credenciales. Si la idea de «llevar los datos de X a Notion para que el equipo pueda verlos» lleva tiempo pendiente, esta es la semana para hacerlo gratis.

Conviene entrar en la lista de espera de la External Agent API. Quienes ya hayan creado agentes con Cloudflare Agents SDK, Mastra o LangGraph podrán usar esta API para incorporarlos al espacio de trabajo como participantes. No hace falta esperar a la GA.

Lo que sí evitaría es reconstruir los Custom Agents. No hay que trasladar a Notion Workers agentes que ya funcionan sobre un entorno real de ejecución duradera. Workers sirve para crear herramientas, no como motor de orquestación.

Qué NO sustituye cuando se usa Cloudflare

Flujos de trabajo duraderos. Notion Workers no ofrece ejecución duradera de varias horas, segura ante repeticiones y con pasos almacenados en caché. Si la infraestructura ya utiliza Cloudflare Workflows, Inngest o Temporal, debe seguir allí.

Vectorize y embeddings. Notion no expone a Workers ninguna primitiva vectorial. La memoria y el RAG siguen viviendo en la infraestructura propia.

Endpoints de API públicos. Notion Workers son herramientas invocadas desde Notion, no servicios HTTP a los que accede la web pública.

Tareas cron con intervalos inferiores a 5 minutos. Cloudflare Cron Triggers junto con this.schedule() del Agents SDK siguen siendo la mejor opción para ciclos cortos.

El patrón de agentes en hibernación. Notion Custom Agents funcionan bien para ejecuciones puntuales de un flujo, pero no rinden igual con agentes persistentes, con almacenamiento por instancia, como los que se construyen sobre Durable Objects. El patrón que describí en la arquitectura de Claude para pequeñas empresas —seis agentes especializados, cada uno con su propia memoria y programación— no encaja bien hoy en el entorno aislado de Workers.

La interpretación correcta es esta: Notion Workers sustituye a Zapier, a la capa de integración montada con AWS Lambda y a las 200 líneas de Node que habría que escribir para darle una herramienta determinista a un Custom Agent. No sustituye el backend de la aplicación. Aquí también se aplica la misma cautela sobre múltiples proveedores que planteé al analizar la adquisición de Stainless: la orquestación debe seguir siendo portátil y Notion debe tratarse como una interfaz, no como el entorno de ejecución.

Qué conviene vigilar durante los próximos 30 días

La GA de la External Agent API. La lista de espera de la beta privada es hoy el filtro de acceso. Cuando se abra, todos los equipos que trabajan con Mastra y LangGraph lanzarán esa misma semana un adaptador para Notion.

El anuncio de la tarifa por créditos antes del 11 de agosto. Hay dos escenarios reales y excluyentes: menos de $1 por millón convertiría a Workers en la capa de integración evidente; $5+ por millón limitaría su adopción a los equipos que ya dependen de Notion.

La expansión de los agentes asociados. ¿Quién se sumará a Claude Code, Cursor, Codex y Decagon? Habrá que seguir a Replit Agent, Devin, Lovable y cualquier adaptador de Managed Agents del ecosistema de Anthropic. Cada nuevo socio elimina una razón más para que los equipos de operaciones abandonen la interfaz de Notion.

La GA del Notion Agent SDK. Aquí se invierte el modelo: Notion Agents se ejecutan dentro de las demás herramientas. Es la apuesta de Notion por defender la ventaja de sus datos, no la del espacio de trabajo. Si ambos productos llegan en Q3, Notion ya no competirá por la interfaz, sino por el propio agente.