Perché il Livello Applicativo Non è Morto
La domanda che continuo a ricevere da founder e potenziali dipendenti: esiste ancora un livello applicativo dell'IA su cui costruire, o OpenAI e Anthropic distruggeranno tutto?
C'è un particolare tipo di psicosi da IA dietro questa domanda. Alcuni hanno concluso che gli unici posti durevoli per evitare la sottoclasse permanente siano all'interno di un grande laboratorio o all'avanguardia nella robotica, nell'hardtech o simili – teoricamente tutto ciò "che i laboratori non possono toccare". Se ogni software verrà divorato, da Codex o Claude che assorbono direttamente il lavoro, o da un modello futuro che renderà superfluo tutto ciò che hai costruito, allora scappa!
Ascolta, sono un massimalista dell'IA quanto chiunque altro, e penso che abbiano ragione a metà. I laboratori stanno davvero puntando a un'enorme fetta della superficie applicativa. Ma "il livello applicativo" non è un'opportunità omogenea. L'inquadramento giusto è se ti trovi sul Yellow Brick Road o da qualche altra parte a Oz.
Il Yellow Brick Road è la nostra abbreviazione per il percorso che i laboratori stanno seguendo, dove stanno investendo risorse straordinarie. Il motivo per cui i laboratori sono più adatti a problemi come la generazione di codice, la scrittura o la creazione di immagini è che questi problemi migliorano con la capacità grezza del modello: ogni dollaro speso in pre-training e post-training migliora la qualità del prodotto. Nel frattempo, il resto di Oz è abitato da problemi più complessi, spesso verticali, che non sono semplici come dare a un utente business uno strumento orizzontale con accesso a strumenti standard e uso del computer. Il valore deriva meno dalla capacità grezza del modello sottostante (anche se è comunque importante!) e più dall'impalcatura che lo circonda, che rende l'output affidabile, conforme e operativo all'interno di un settore specifico.
Lo stiamo vedendo accadere in tempo reale mentre OpenAI e Anthropic stanno effettivamente dicendo al mercato che non possono risolvere ogni problema con un collega AI generico. Hanno annunciato massicce joint venture forward-deployed per costruire intere aziende attorno alla configurazione e personalizzazione dei loro modelli per le imprese. Non investi miliardi in quei programmi se pensi che la prossima release del modello risolverà tutto.
Quindi, se vuoi arricchirti costruendo app AI – evita il yellow brick road e costruisci da qualche altra parte a Oz. Ecco cosa abbiamo imparato, e cosa hanno imparato alcuni dei founder del nostro portfolio, su cosa funziona.
Il Yellow Brick Road
Se stai avviando un'azienda, il Yellow Brick Road è il percorso più ovvio da seguire, ma è il più pericoloso. Prendi un modello ad alte prestazioni, collega alcuni connettori standard (come G Drive, Slack, Salesforce, Notion, GitHub) e mettici sopra una sorta di livello di orchestrazione agentica. Magia!
Il problema è che questo è esattamente ciò che i laboratori stanno facendo con Cowork e Codex. Ovviamente, possiedono il modello, il che dà loro margini migliori, controllo e la capacità di esercitare potere sui prezzi su chiunque sia a valle. Ma forse, cosa più importante, possiedono anche le scelte architettoniche che definiscono per cosa i loro prodotti sono costruiti per risolvere bene. Finora sono stati deliberati riguardo al pattern di modello più chiamate di strumenti, e questo è esattamente ciò che il lavoro orizzontale a basso numero di passi sulla strada richiede. Anche se una startup potesse in qualche modo superare Codex o Claude Code, i laboratori hanno enormi bracci di distribuzione e il più grande alone di marca nell'IA.
Se sei un'azienda di app AI che esegue quel manuale con gli stessi connettori, nessun sub-agente o configurazione al di sotto, e nessuna distribuzione, probabilmente stai camminando lungo la strada che porta a nowhere.
Il Resto di Oz
Non è tutto doom e gloom per le startup. C'è un'enorme opportunità al di fuori del Yellow Brick Road, dove le startup hanno un percorso chiaro per possedere il proprio cliente e risolvere problemi complessi.
Queste aziende stanno costruendo esperienze agentiche in cui il modello è intrecciato attraverso una complessa rete di strumenti, automazioni e integrazioni (leggi: software), portando la maggior parte di queste startup ad essere verticali per impostazione predefinita. Possono concentrarsi su lavoro multi-step e multi-attore, con sub-agenti per attività specifiche di ruolo e verticale, a cui Anthropic e OpenAI non possono arrivare con piattaforme orizzontali: raccogliere contesto attraverso i sistemi, poi instradare attraverso più umani che devono approvare in fasi diverse. Spesso coinvolge uno o più sistemi legacy, tende a richiedere risultati deterministici dove l'ambiguità non è accettabile, ed è a volte legato a qualche risultato aziendale di valore. I laboratori capiscono quanto siano preziosi questi problemi: ecco perché stanno costruendo i propri negozi di configurazione in outsourcing, e perché esiste un'intera classe upmarket di aziende di reinforcement learning.
Perché il resto di Oz non sarà posseduto dal Mago
La risposta a quanto sopra sarebbe che finora è stato uno scambio piuttosto negativo scommettere contro il miglioramento dei modelli/laboratori. Probabilmente continueranno a migliorare e alla fine eroderanno il mercato servito da queste aziende del livello applicativo.
I laboratori miglioreranno sicuramente, ma sostengo che ci siano alcuni modi in cui il resto di Oz può difendersi nel tempo:
Volani di dati e apprendimento:
Molto di ciò che interiorizzi non è in nessun set di training — norme di settore non scritte, standard non documentati, la conoscenza tribale che vive nella testa dei professionisti. Niente di tutto ciò è sul web pubblico. Nessuna quantità di calcolo di training sostituisce l'essere all'interno dei flussi di lavoro in cui questa conoscenza vive effettivamente. Ci sono due volani impilati l'uno sull'altro qui: uno trasversale ai clienti — pattern che si accumulano man mano che vedi più varianti dello stesso problema — e uno all'interno del cliente — il "perché" dietro decisioni specifiche, le eccezioni non dette, le regole empiriche dell'azienda che emergono solo attraverso l'interazione reale con il sistema.
Anche se i dati dei clienti non possono essere usati tra clienti diversi, le aziende di applicazioni saranno in grado di sfruttare il riconoscimento di pattern tra i tipi di problema dei clienti, e usarlo per informare l'architettura giusta per problemi futuri. Un'azienda che ha eseguito i suoi agenti attraverso cento revisioni legali, mille cicli di sottoscrizione assicurativa o diecimila campagne SDR ha interiorizzato la forma del problema in un modo che il prossimo entrante non può replicare attivando un agente nuovo per la prima volta.
Un agente orizzontale potrebbe in linea di principio costruire la stessa infrastruttura di apprendimento. Il motivo per cui non lo fa, al di là della pura focalizzazione, è la UX: catturare questo tipo di conoscenza dipende interamente dalle superfici del flusso di lavoro che dai all'utente, e i player verticali possono modellare quelle superfici esattamente intorno a ciò che il loro flusso di lavoro deve far emergere. Gli strumenti orizzontali non possono. Set di valutazione, output etichettati e tassonomie di casi limite possono accumularsi in un volano di dati specifico per verticale che può alimentare il fine-tuning che il prossimo entrante non può generare senza una comparabile esposizione produttiva. Se ciò sia possibile dipende dai diritti sui dati, dal volume di esposizione produttiva accumulata e dalla struttura dei contratti con i clienti, ma il riconoscimento di pattern si accumula indipendentemente.
Gestione della variabilità e complessità del modello: I laboratori stanno già instradando internamente — diverse classi di modelli per richieste diverse, ensemble sotto il cofano. Quello che non possono fare è instradare tra diversi fornitori, o valutare il modello di un concorrente per un sotto-compito specifico, o usare un fine-tune open-source per il pezzo ristretto in cui è effettivamente il migliore. L'azienda del Resto di Oz sceglie il modello giusto per ogni sotto-compito nell'intero mercato dei modelli, non solo ciò che il suo laboratorio madre spedisce. Fa anche il lavoro che nessuno vuole fare — rieseguire le valutazioni sugli aggiornamenti, ricalibrare i prompt per i casi limite del cliente, implementare senza interrompere la produzione — ogni volta che un nuovo modello arriva. I laboratori non lo fanno per conto del cliente; ti vendono il loro prossimo modello e ti dicono di migrare. L'azienda del Resto di Oz assorbe la migrazione. Quello che il cliente ottiene è la migliore intelligenza disponibile in tutto il mercato, più la continuità attraverso ogni aggiornamento.
Ottimizzazione dei costi: Eseguire ogni query su Opus 4.7 è la via più veloce per margini lordi negativi. Le migliori aziende del Resto di Oz instradano attraverso livelli di modelli — modelli frontier per i compiti più difficili, mid-tier per la maggior parte, modelli personalizzati o fine-tuned più piccoli dove si sono guadagnati il diritto di usarli. Alcune ora stanno facendo post-training dei propri modelli sopra a questo, ottimizzandoli per lo stretto segmento di lavoro che interessa al loro cliente e servendoli a una frazione del costo di una chiamata API frontier. I laboratori fissano il prezzo minimo: l'intelligenza minima disponibile a $X. L'azienda del Resto di Oz vende l'inverso — il costo in dollari più basso per il livello specifico di intelligenza che il flusso di lavoro richiede effettivamente. Questo è possibile solo se sai esattamente di quale livello ogni sotto-compito ha bisogno, cosa che i laboratori strutturalmente non possono sapere in ogni verticale. Si traduce direttamente in prezzi più bassi e controllati per i risultati.
Governance: C'è un valore considerevole nel diventare il piano di controllo per come i loro clienti eseguono l'IA in quella verticale – il luogo dove permessi, audit, cosa-all'agente-è-permesso-fare e cosa-l'agente-ha-effettivamente-fatto convergono tutti. Quel piano di controllo è costruito con barriere di protezione specifiche per caso d'uso che hanno un aspetto completamente diverso tra settori e tipi di lavoro. Poiché possiedono gli strumenti, i flussi di lavoro e i dati che l'agente tocca end-to-end, possono fornire risultati deterministici in modi in cui gli strumenti orizzontali faranno fatica. Sono anche l'entità che assorbe la complessità normativa per l'acquirente finale — regole FRCP e forensi nel legale, HIPAA nella sanità, SEC e FINRA nella finanza, regolamenti assicurativi statali e così via. Un player orizzontale non può farlo credibilmente senza diventare cento diverse verticali contemporaneamente. I CIO vogliono avere un partner che dichiari contrattualmente di gestire la conformità per gli agenti che forniscono.
Tutti questi punti riconducono alla stessa cosa: focalizzazione. Potrebbe essere una verticale (assicurazioni, legale, contabilità) o una funzione svolta in profondità (vendite, supporto clienti, finanza). In ogni caso, il lavoro richiede un team concentrato su un insieme di clienti — i suoi flussi di lavoro, i suoi casi limite, le sue regolamentazioni. I laboratori non sono costruiti per questo. Devono essere ovunque, per tutti, che è come hanno costruito il Yellow Brick Road in primo luogo. Lo stesso compromesso li tiene fuori dal resto di Oz — puoi essere ovunque contemporaneamente, o puoi essere bravo in una cosa. Non entrambe.
Le vendite come esempio – consigli pratici dal CEO tecnico di 11x
Come dovresti pensarci nella pratica? Ecco alcuni consigli pratici da Prabhav Jain, CEO di 11x.
Concentrati sui risultati
Un percorso tattico per costruire un'azienda resiliente ai laboratori è semplicemente partire da un risultato specifico a cui i tuoi clienti tengono veramente. Per noi, era aiutare le aziende a generare più pipeline. Da lì, le domande diventano tattiche. Quali attività vogliamo possedere end-to-end che effettivamente guidano la pipeline? Decomponi ogni attività in compiti. Quali compiti sono agentici e quali no. Quali richiedono una complessa comprensione del dominio e quali no. I laboratori spediranno anche flussi di lavoro, ma quando il flusso di lavoro ha molti passaggi, input disordinati, stato difficile da interpretare o vincoli del mondo reale, un modello migliore da solo non ti porterà lì. Il lavoro ricade sulla buona vecchia ingegneria del software, e i laboratori non hanno alcun vantaggio rispetto a un'azienda di applicazioni focalizzata su quella superficie. Ad esempio, ecco alcuni dei compiti che gestiamo noi, alcuni agentici e altri no: prospezione di lead basata su segnali personalizzati, arricchimento dei lead, ricerca approfondita dell'account, recuperatore di contesto dal CRM, scrittore di messaggi specifici per canale, agente di qualifica dei lead e sistema di deliverability delle email. Questi non sono compiti che puoi risolvere con un unico prompt e richiedono ingegneria approfondita.
L'osservazione critica nell'analogia di Oz è che circa la metà di qualsiasi flusso di lavoro reale che non è agentico non offre alcun vantaggio ai laboratori. Non sono migliori di te nello scrivere il software deterministico sotto il livello del modello. E la metà che è agentica richiede comunque di mettere a punto, addestrare e vincolare i modelli rispetto al risultato che effettivamente desideri. La conoscenza del dominio spesso non risiede nei dati di training generali. Quelle competenze si costruiscono da zero per la verticale o funzione, e vengono fornite al modello nel momento giusto del flusso di lavoro. Quando i nostri agenti qualificano un lead in entrata al telefono, devo essere addestrato su cosa sia una buona conversazione di vendita per quel settore specifico e quella persona. Questo è lavoro da azienda di applicazioni, e si accumula.
Cosa più importante, quelle competenze diventano obsolete continuamente perché le aziende si evolvono, quindi la tua capacità di evolvere quei flussi di lavoro e contesto diventa un vantaggio competitivo. Ad esempio, quando abbiamo iniziato il nostro prodotto di outreach email su larga scala, le email scritte "dall'IA" stavano appena iniziando a entrare in gioco. Oggi, le persone hanno un senso affinato delle email scritte dall'IA rispetto a quelle umane e, cosa cruciale, questo cambia ogni pochi mesi. I nostri agenti devono adattarsi costantemente data la dinamica del mercato, ma è qui che si costruisce il fossato. Infatti, nonostante questa dinamica, i nostri tassi di risposta positiva sono aumentati di 4 volte negli ultimi mesi e abbiamo generato centinaia di milioni in pipeline per i nostri clienti.
Lavora su problemi dove la complessità è alta
I problemi complessi sono dove si sblocca il vero valore aziendale. Altrimenti, ti ritroverai a costruire un sottile strato di wrapping.
Decomponi qualsiasi problema aziendale sufficientemente complesso e il disordine emerge rapidamente. Ecco un esempio dal mondo GTM che sembra banale: non dovresti contattare un contatto in un'azienda se quell'azienda è già cliente. Ma non lo è affatto. Forse hai il dominio associato all'azienda nel tuo CRM. E le aziende con dozzine di filiali? Cosa succede se il record CRM ha il dominio della società madre? Cosa succede se un campo di corrispondenza obsoleto in Salesforce invia un messaggio a freddo al CRO di un cliente attuale? I dati del mondo reale sono disordinati. Gli umani hanno difficoltà. I modelli non superano magicamente quella soglia. Portare ordine in quel disordine richiede agenti costruiti su misura, progettati per la forma specifica del problema, non un copilota generico puntato su un CRM. Infatti, sulla base dei dati che abbiamo, ci siamo resi conto che la qualità e la freschezza dei nostri dati sono molto superiori a quelle dei nostri clienti, quindi per impostazione predefinita, ci ancoriamo ai nostri.
Le barriere di protezione non servono solo a prevenire cose brutte. Questo è ciò per cui i tuoi clienti ti pagano.
Le barriere di protezione sono gravemente sottovalutate. Anche all'interno dello stesso prodotto, ogni caso d'uso ha bisogno delle proprie. Per noi, un potenziale cliente del settore dei servizi finanziari regolamentato richiede garanzie diverse rispetto a un cliente SaaS di medie dimensioni, e quelle garanzie si ripercuotono su come l'agente è autorizzato a scrivere, chi può contattare, quali dati può toccare, cosa può dire in una chiamata e come ogni decisione viene registrata.
Un sistema unico per tutti collassa sotto quella varianza. Le barriere di protezione devono essere costruite per caso d'uso, configurate per cliente e controllate continuamente, e quel lavoro spetta direttamente all'azienda di applicazioni. Questo è il motivo per cui abbiamo FDE e strateghi di implementazione tecnica che devono mettere a punto per ogni requisito del cliente. Ad esempio, abbiamo lavorato con un'istituzione F1000 per fare outreach outbound via voce con consenso alla loro vasta base di clienti SMB. Le prime iterazioni avevano bassi tassi di risposta — abbiamo dovuto iterare rapidamente e imparare come far coinvolgere questo tipo specifico di pubblico nei primi 10 secondi della chiamata. I proprietari di piccole imprese si comportano in modo molto diverso dai grandi acquirenti B2B o dai consumatori. Ora generiamo più opportunità di vendita per loro in un giorno di quanto l'intero team di vendita per quel segmento ne facesse in un mese.
Le assicurazioni come esempio – consigli pratici dal CEO di FurtherAI
Le vendite sono un esempio. Le assicurazioni sono un altro, e fa lo stesso punto da una prospettiva diversa. Ecco come Aman Gour, CEO di FurtherAI, pensa a costruire fuori dalla strada:
Quando abbiamo iniziato a distribuire l'IA all'interno di operazioni assicurative reali, continuavamo a sentire un presupposto particolare: il modello è l'intelligenza, e il flusso di lavoro è solo un'impalcatura attorno ad esso.
Più assicuratori con cui lavoravamo, più diventavamo convinti che questo fosse al contrario.
Nelle assicurazioni, molta dell'intelligenza vive all'interno del flusso di lavoro stesso. Due assicuratori possono eseguire una sottomissione attraverso quello che sembra lo stesso percorso: sottomissione, revisione, preventivo, vincolo. Ma il percorso è la parte facile. Ciò che separa i due assicuratori è tutto ciò che c'è dentro: quali rischi vengono escalated, quali segnali di perdita contano, quale regola di appetito vince quando due sono in conflitto, quando un umano deve approvare, quali dati esterni vengono recuperati e come viene documentata la decisione finale.
Quella logica non vive in un unico motore di regole pulito. È distribuita tra SOP, revisioni dei manager, filosofia di sottoscrizione, appetito specifico dell'assicuratore e anni di esperienza operativa. Molto non è scritto in una forma che un modello può semplicemente leggere.
Questo è il motivo per cui non crediamo in un agente puro che ragiona da zero ogni volta, e non crediamo in un flusso di lavoro rigido che si rompe non appena la realtà diventa disordinata. Invece, abbiamo costruito flussi di lavoro agentici. Il flusso di lavoro ti dà ripetibilità, verificabilità e controllo dei costi. L'agente gestisce la variabilità e si riprende quando il percorso felice si interrompe. L'umano rimane in giro per le decisioni di giudizio dove la responsabilità conta.
Il primo giorno, questo automatizza il lavoro manuale. Ma nel tempo, ogni escalation diventa un segnale, ogni eccezione è un feedback e ogni correzione umana mostra dove il runbook era incompleto. Col tempo, il flusso di lavoro smette di essere uno script e inizia a diventare la memoria operativa dell'assicuratore. Questa è la parte che i laboratori troveranno difficile da raggiungere. Continueranno a spedire modelli migliori e agenti generali migliori, e fanno bene. Ma non si siedono all'interno dei flussi di lavoro produttivi di un assicuratore abbastanza a lungo per imparare perché un account è stato escalated, perché un rischio è stato rifiutato o perché un sottoscrittore ha ignorato la guida dell'appetito e aveva ragione a farlo.
Quella comprensione arriva solo dall'eseguire il flusso di lavoro, in produzione, molte migliaia di volte. Il flusso di lavoro che spedisci il primo giorno non è il fossato. Il ciclo che l'uso produttivo crea nel tempo lo è.
Per noi, questo è ciò che significa costruire fuori dalla strada.
Come decidi se sei nel resto di Oz o no?
Il test degli strumenti e dei passaggi: Quanti passaggi richiede il lavoro e quanto sono complessi gli strumenti che devi costruire per supportarlo? Confronta una ricerca AI orizzontale su Google Drive — un passaggio contro uno strumento con un risultato indulgente, l'utente legge il riassunto e richiede di nuovo se è sbagliato — con una revisione legale multi-step contro tre anni di precedenti dello studio: dozzine di passaggi attraverso molti strumenti, output che deve superare la revisione del partner e potrebbe dover essere discusso in tribunale. Entrambi sembrano "un agente che fa lavoro", ma solo uno richiede il tipo di software profondo che un team focalizzato impiega anni a costruire.
Il test del sistema: Stai costruendo un sistema attraverso il quale il cliente esegue il suo lavoro, o uno strumento che si siede sopra un sistema che hanno già? I sistemi possiedono il flusso di lavoro end-to-end — la cattura dei dati, la governance, i registri di ciò che è stato fatto — e sono ciò a cui il cliente si riferisce quando descrive come avviene il lavoro reale. Gli strumenti, d'altra parte, aggiungono solo intelligenza a un flusso di lavoro che il cliente già esegue. Il caso dello strumento genera entrate reali e i laboratori possono prenderlo perché il cliente non dipende da te come livello di orchestrazione. Un ACV alto è di solito un segnale di un sistema, poiché i sistemi sostituiscono il personale reale e vengono pagati di conseguenza, ma non è una garanzia. Chiediti se il cliente avrebbe ancora bisogno del tuo strumento se un laboratorio spedisse qualcosa che presumibilmente compete direttamente con te. Se sì, stai costruendo un sistema. Se no, sei uno strumento — anche se il tuo ACV è alto.
Il test del hedge fund / P&L: Mentre le prestazioni dei laboratori sono giudicate rispetto ai benchmark, le prestazioni del resto di Oz sono giudicate rispetto al P&L del tuo cliente. Al tuo cliente non importa che il tuo modello abbia ottenuto un buon punteggio su SWE-Bench o MMLU — a loro importa se il tuo agente ha chiuso l'affare, ha revisionato correttamente il contratto o ha coperto la polizza giusta. Se sono fissati sul risultato specifico del loro flusso di lavoro, non su un punteggio di capacità generica, sei nel resto di Oz. Se stanno pagando per capacità generica, stai vendendo loro qualcosa che possono ottenere con un posto Claude o Codex. Le migliori aziende di agenti dovranno eseguire come hedge fund — vincendo sull'alpha misurato nel P&L del cliente, non nei punteggi dei benchmark.
Entrambi possono (e lo faranno) vincere
Vedremo vincitori massicci dentro e fuori dal Yellow Brick Road. I modelli continueranno a vincere perché possiedono il modello e possiedono la distribuzione per gli strumenti orizzontali che hanno progettato.
Il resto di Oz può vincere se possiede il sistema di lavoro — la superficie dove il lavoro dell'azienda viene effettivamente eseguito e i dati che ne fluiscono vengono catturati. Queste aziende possiedono la cattura dei dati, il sistema di azione del flusso di lavoro e la governance. Man mano che flussi di lavoro più complessi maturano in una verticale, si combinano in un'esperienza centrale da cui il cliente dipende. Man mano che nuove generazioni di modelli vengono spedite dagli incumbent e dai nuovi entranti, l'azienda diventa il livello che li integra e li consegna al cliente. Il modello è fungibile al di sotto; il sistema di lavoro no.
La prossima generazione di software aziendale sarà costruita fuori dalla strada.
Se lo stai costruendo, contattami: [email protected].
