Notion API cambia passo: agenti esterni, Workers e il nodo dei crediti

La Notion API cambia passo. Il 13 maggio Notion ha lanciato la sua Developer Platform con Workers, un’API per agenti esterni e una CLI che tratta Claude Code, Cursor e Codex come partecipanti nativi del workspace. La posta in gioco è più alta di quanto sembri: Notion punta a conquistare il control plane degli agenti, e sul calendario c’è una sola data da cerchiare, l’11 agosto.

Notion API e Developer Platform: cosa è arrivato

Sei primitive in un’unica release. I Workers sono un runtime gestito Node/TypeScript, in beta pubblica e riservato ai piani Business ed Enterprise. External Agents è in Alpha, con integrazioni partner già pronte per Claude Code, Cursor, Codex e Decagon. Per creare agenti personalizzati c’è una External Agent API, accessibile tramite lista d’attesa per la beta privata. La CLI si chiama ntn, è disponibile su tutti i piani e si installa con curl -fsSL https://ntn.dev | bash. Completano il pacchetto la sincronizzazione dei database basata su Workers, con Zendesk / Salesforce / Postgres, e i trigger webhook, che portano qualsiasi app dentro un Worker e poi in Notion. Fonte: annuncio della Developer Platform di Notion.

Ci sono altri due segnali da non sottovalutare. Il Notion Agent SDK (Alpha, lista d’attesa) consente di integrare i Notion Custom Agents in MS Teams, Discord, Amplitude e Hex. Anche la governance è già prevista: fiducia progressiva nelle azioni degli agenti, Workers isolati in sandbox, autenticazione e permessi per ogni deploy.

La lettura per chi deve decidere

Il vero titolo non è «Notion lancia un SDK», ma «Notion si candida a diventare il workspace degli agenti». Quando Claude Code, Cursor, Codex e Decagon arrivano nella barra laterale come agenti partner, l’IDE smette di essere il livello di orchestrazione. Quella posizione, ora, è contesa.

La demo descritta nelle note di rilascio del 13 maggio rende il flusso molto chiaro: Decagon riceve un ticket di assistenza, passa il bug a un agente di coding e rimanda la correzione al team per l’approvazione. Oggi questo ciclo si distribuisce tra tre app e un thread Slack. Notion vuole ricondurlo a un’unica interfaccia.

Chi controlla il workspace controlla anche la tassa d’integrazione. Notion ora la riscuote dai fornitori di agenti, non da quelli di CRM. È questo il cambio di paradigma.

C’è però una tesi opposta: la maggior parte degli stack operativi dispone già di un’interfaccia predefinita, che sia il CRM, lo strumento di project management o un pannello amministrativo su misura. La questione è se l’impostazione di Notion — basata su database, nativa per gli agenti e pensata prima di tutto per il browser — riuscirà a sfruttare l’inerzia dei team che già lavorano sulla piattaforma. Per chi non vive in Notion non cambia nulla. Per gli altri cambia il calcolo build-or-buy per ogni tool interno che stavano per costruire.

Notion Workers e lo scoglio dei crediti dell’11 agosto

I Workers sono gratuiti durante la beta pubblica. Dall’11 agosto 2026 utilizzeranno i crediti Notion, ma il costo dei crediti non è stato comunicato. È insieme l’opportunità asimmetrica e la trappola.

L’opportunità è questa: oggi si può sviluppare sui Workers senza costi. Se entro il 10 agosto metti in produzione tre sincronizzazioni e due tool per agenti, assorbi a costo zero la spesa d’integrazione. Se aspetti, dovrai migrare quando Notion avrà già pubblicato la sua tariffa, dentro un modello a crediti che non avevi previsto nella roadmap.

Facciamo i conti. Una sincronizzazione ogni 5 minuti produce 8,640 esecuzioni al mese. Tre sincronizzazioni arrivano a 25,920 esecuzioni mensili. Su Notion, dopo il 10 agosto, il costo resta una variabile aperta. Se la tariffa sarà inferiore a $1 per milione, avrà il costo di un normale strato di integrazione e converrà spostare tutto ciò che interagisce con i dati Notion. Se sarà di $5+ per milione, Cloudflare manterrà la fascia di mercato più attenta ai costi e i Workers di Notion resteranno confinati ai carichi che usano dati Notion.

La trappola: non spostare carichi già deterministici ed economici nello stack esistente. Ha senso migrare soltanto quelli che traggono vantaggio dalla vicinanza ai dati Notion: job di sincronizzazione che leggono Notion, tool per agenti che vi scrivono e webhook che distribuiscono eventi nei database Notion. Tutto il resto può rimanere dov’è.

Automazione Notion: cosa metterei in produzione questa settimana

Per prima cosa, installerei la Notion CLI. curl -fsSL https://ntn.dev | bash, autenticazione e il gioco è fatto. È gratuita e non richiede alcun piano della piattaforma. Panoramica della CLI.

Poi realizzerei un Worker capace di ripagarsi da solo: un tool deterministico che i Custom Agents chiameranno 50+ volte alla settimana. Lookup-customer-by-email, push-task-to-Linear, generate-weekly-report. Consuma pochi token, non richiede ragionamento da parte di un LLM e gira nella sandbox. Guida ai tool.

Aggiungerei una sincronizzazione che finora non valeva il lavoro necessario per costruirla: portare una tabella Postgres, i pagamenti Stripe o lo stato delle PR GitHub in un database Notion. I Workers gestiscono pianificazione e credenziali. Se il pensiero ricorrente era «vorrei mettere i dati X in Notion così il team può vederli», questo è il momento di farlo, finché non costa nulla.

Mi iscriverei alla lista d’attesa della External Agent API. Se gli agenti sono già stati costruiti su Cloudflare Agents SDK, Mastra o LangGraph, questa è l’API con cui inserirli nel workspace come partecipanti a pieno titolo. Non aspetterei la GA.

Eviterei invece di ricostruire i Custom Agents. Non trasferirei in Notion Workers agenti che girano già su un vero runtime di esecuzione durevole. I Workers sono adatti ai tool, non all’orchestrazione.

Cosa NON sostituisce per chi usa Cloudflare

I workflow durevoli. Notion Workers non offre esecuzione durevole per più ore, sicura in caso di replay e con cache dei singoli passaggi. Se usi già Cloudflare Workflows, Inngest o Temporal, continua a usarli.

Vectorize ed embedding. Notion non espone ai Workers alcuna primitiva vettoriale. Memoria e RAG restano nel tuo stack.

Endpoint API pubblici. I Notion Workers sono tool invocati dall’interno di Notion, non servizi HTTP raggiungibili dal web pubblico.

Pianificazioni cron inferiori a 5 minuti. Per i cicli ravvicinati, Cloudflare Cron Triggers e this.schedule() dell’Agents SDK restano la scelta migliore.

Il modello dell’agente in ibernazione. I Custom Agents di Notion gestiscono bene i workflow eseguiti in un’unica soluzione; sono meno adatti agli agenti persistenti con storage dedicato per ogni istanza che si realizzano sui Durable Objects. Il modello descritto nello stack Claude per le piccole imprese — sei agenti specializzati, ciascuno con memoria e pianificazione proprie — oggi non trova una collocazione naturale nella sandbox dei Workers.

La conclusione corretta è questa: i Notion Workers sostituiscono Zapier, lo strato di collegamento basato su AWS Lambda e le 200 righe di Node che avresti scritto solo per offrire un tool deterministico a un Custom Agent. Non sostituiscono il backend dell’applicazione. Vale anche qui la stessa considerazione multi-provider di cui ho scritto a proposito dell’acquisizione di Stainless: mantieni portabile l’orchestrazione e considera Notion un’interfaccia, non il runtime.

Cosa monitorare nei prossimi 30 giorni

La GA della External Agent API. Oggi l’accesso è bloccato dalla lista d’attesa della beta privata. Quando si aprirà, ogni realtà che lavora con Mastra e LangGraph pubblicherà un adattatore per Notion nella stessa settimana.

La comunicazione del costo dei crediti prima dell’11 agosto. I due scenari sono concreti e incompatibili: meno di $1 per milione renderebbe Workers la scelta naturale come strato di collegamento; $5+ per milione ne limiterebbe l’adozione ai team già vincolati a Notion.

L’espansione degli agenti partner. Chi si aggiungerà a Claude Code, Cursor, Codex e Decagon? Da tenere d’occhio Replit Agent, Devin, Lovable e qualsiasi adattatore per Managed Agents nell’ecosistema Anthropic. Ogni nuovo partner toglie a chi gestisce le operazioni un motivo per uscire dall’interfaccia Notion.

La GA del Notion Agent SDK. Qui il rapporto si inverte: gli agenti Notion girano all’interno degli altri strumenti. È la strategia difensiva per i dati Notion, non per il workspace. Se entrambi arriveranno nel Q3, Notion non competerà più per il controllo dell’interfaccia, ma per quello dell’agente stesso.