La qualità di un sistema di intelligenza artificiale non dipende soltanto dal modello scelto. Conta ciò che il modello vede quando deve produrre una risposta o decidere l’azione successiva: istruzioni, documenti, dati, strumenti, memoria, stato del processo e risultati delle operazioni già compiute. Progettare e governare questo insieme dinamico di informazioni è il compito del Context Engineering.
Per alcuni anni buona parte dell’attenzione si è concentrata sul Prompt Engineering. Era una conseguenza naturale del modo in cui venivano utilizzati i primi modelli generativi: una persona formulava una richiesta, il modello riceveva un testo e produceva una risposta. Migliorare l’istruzione, aggiungere esempi e precisare il formato dell’output potevano modificare sensibilmente il risultato.
Le applicazioni AI attuali hanno però superato quello schema. Interrogano archivi aziendali, richiamano API, usano strumenti, conservano memoria e svolgono attività articolate in più passaggi. Un agente può iniziare il lavoro con una richiesta dell’utente, consultare una base documentale, eseguire una query, analizzare il risultato, aggiornare un piano e scegliere un altro strumento. Prima di ciascuna inferenza bisogna decidere quali elementi rendere disponibili al modello e quali lasciare fuori.
Il prompt rimane importante, ma è diventato soltanto una parte del problema.
Dalla formulazione delle istruzioni alla costruzione del contesto
L’espressione Context Engineering si è diffusa rapidamente nel giugno 2025. In un post su X, Tobi Lütke, CEO di Shopify, la propose come definizione più appropriata della capacità di fornire a un LLM tutto ciò che rende plausibilmente risolvibile un compito. Il 25 giugno Andrej Karpathy, ricercatore e divulgatore, membro del gruppo fondatore di OpenAI e già direttore dell’AI di Tesla, rilanciò l’espressione, descrivendola come il lavoro necessario per riempire la finestra di contesto con le informazioni giuste per il passaggio successivo. Dal maggio 2026 Karpathy lavora nuovamente nella ricerca di frontiera, questa volta in Anthropic. La sequenza è stata ricostruita all’epoca da Simon Willison, che osservò come la nuova espressione potesse descrivere meglio la complessità delle applicazioni LLM rispetto all’immagine, ormai riduttiva, di qualcuno che perfeziona una domanda in una chat.
Il fenomeno non nasce naturalmente con il nome. Retrieval-Augmented Generation, function calling, memoria, cronologia delle conversazioni e system prompt esistevano già. Il nuovo termine segnala piuttosto che queste tecniche non possono più essere progettate separatamente. Concorrono tutte alla costruzione dello stato informativo sul quale il modello deve ragionare in un determinato momento.
Nel luglio 2025 LangChain, un ecosistema software usato per sviluppare applicazioni e agenti basati su LLM. ha organizzato le principali strategie in quattro famiglie: scrivere il contesto e conservarlo all’esterno della finestra del modello; selezionare quello pertinente; comprimerlo per trattenere soltanto ciò che serve; isolarlo, distribuendolo tra stati, ambienti o agenti differenti. Nel settembre dello stesso anno Anthropic ne ha data una formulazione ancora più precisa: il Context Engineering è la selezione e il mantenimento dell’insieme ottimale di token disponibili al modello durante l’inferenza.
La parola decisiva è “ottimale”, non “massimo”. Una finestra di contesto molto ampia permette di fornire più informazioni, ma non rende tutte quelle informazioni pertinenti, coerenti o ugualmente utilizzabili.
Che cosa vede realmente un modello
In un’applicazione enterprise, il contesto può essere composto da elementi di natura molto diversa:
- le istruzioni di sistema e quelle specifiche del compito;
- la richiesta dell’utente e la cronologia dell’interazione;
- esempi del comportamento o del formato atteso;
- documenti recuperati mediante ricerca semantica, lessicale o ibrida;
- record provenienti da database e applicazioni aziendali;
- metadati, tassonomie e relazioni di un knowledge graph;
- descrizioni degli strumenti e relativi parametri;
- risultati ottenuti dagli strumenti;
- stato del workflow e piano delle attività;
- memoria relativa all’utente, al processo o a precedenti esecuzioni;
- identità, autorizzazioni, policy e vincoli applicabili;
- risultati intermedi prodotti da altri agenti.
Non tutti questi elementi devono essere caricati insieme. Una descrizione di centinaia di strumenti, per esempio, può occupare una parte considerevole della finestra e rendere più difficile la scelta dello strumento appropriato. Un risultato grezzo di una query può contenere decine di migliaia di token, quando al modello servono soltanto poche anomalie. Una lunga cronologia può conservare decisioni superate o informazioni successivamente corrette.
Il Context Engineering governa quindi l’intero ciclo: individuare le fonti, recuperare i contenuti, verificarne la pertinenza, trasformarli in una rappresentazione utilizzabile, stabilirne l’ordine, controllarne la provenienza e decidere quando sintetizzarli, sostituirli o rimuoverli.
Questa attività si ripete a ogni fase dell’esecuzione. Il contesto di un agente non è un pacchetto preparato una volta per tutte, ma una working memory che cambia con il procedere del lavoro.
Perché più contesto non significa necessariamente più qualità
La crescita delle finestre supportate dai modelli potrebbe far pensare che il problema sia destinato a risolversi semplicemente caricando tutto. Le evidenze disponibili invitano alla cautela.
Lo studio “Lost in the Middle”, pubblicato su Transactions of the Association for Computational Linguistics, ha mostrato che le prestazioni possono degradare quando l’informazione rilevante si trova nel mezzo di un contesto lungo. I risultati migliori tendevano a comparire quando l’informazione era collocata all’inizio o alla fine. Studi successivi hanno individuato progressi nei modelli più recenti, ma anche la persistenza di bias legati alla posizione e alla distanza tra informazioni che devono essere combinate.
La capacità dichiarata della finestra indica quanti token un modello può ricevere, non garantisce che riesca a utilizzare ogni informazione con la stessa precisione. All’aumentare del contesto crescono inoltre il costo dell’inferenza e, normalmente, la latenza. Si aggiungono problemi applicativi: dati irrilevanti possono distrarre il modello; istruzioni incompatibili possono entrare in conflitto; un errore prodotto in un passaggio può essere reinserito nel contesto e condizionare quelli successivi.
Anthropic suggerisce per questo di cercare il più piccolo insieme di token ad alta rilevanza capace di produrre il comportamento desiderato. Microsoft Research affronta lo stesso problema collegando potatura del contesto, retrieval ibrido e compressione alla qualità ottenuta per unità di costo e alla prevedibilità della latenza.
Il contesto diventa quindi una risorsa soggetta a un budget: non soltanto un limite quantitativo, ma una capacità di attenzione da impiegare dove produce valore.
Prompt Engineering, RAG e memoria non scompaiono
Presentare il Context Engineering come il successore del Prompt Engineering produce un titolo efficace, ma descrive male la relazione fra i due. Il Prompt Engineering continua a occuparsi della formulazione e dell’organizzazione delle istruzioni: ruolo, obiettivo, vincoli, esempi e formato del risultato. Sono tutti elementi del contesto e devono continuare a essere progettati.
Il RAG risolve invece una parte differente del problema: recupera da fonti esterne informazioni che il modello non possiede, che sono cambiate dopo l’addestramento o che appartengono al patrimonio privato dell’organizzazione. Anche il retrieval, però, non esaurisce il Context Engineering. Occorre decidere quale strategia di ricerca utilizzare, come suddividere e indicizzare i contenuti, come combinarne i risultati, come effettuare il reranking, quanti passaggi presentare al modello e in quale forma.
La memoria permette di conservare informazioni oltre la singola chiamata o sessione. Anche in questo caso, memorizzare non basta. Bisogna stabilire che cosa meriti di essere ricordato, per quanto tempo, con quale provenienza, chi possa utilizzarlo e quando recuperarlo. Una memoria corretta ma non pertinente può peggiorare una risposta quanto un documento recuperato male.
MCP, infine, standardizza il modo in cui applicazioni e agenti possono collegarsi a strumenti e sorgenti. È un’interfaccia per rendere disponibili capacità e informazioni, non un motore che decide automaticamente quali debbano entrare nel contesto. La selezione degli strumenti e il trattamento dei risultati restano problemi progettuali.
Il Context Engineering non elimina queste discipline: le mette in relazione.
Dove finisce il contesto e comincia l’agent harness
L’espressione agent harness indica l’infrastruttura software che “avvolge” il modello e ne trasforma le risposte in un’esecuzione controllata. Il termine non ha ancora una definizione standard, ma nell’uso corrente comprende il ciclo che richiama il modello, registra lo stato, presenta gli strumenti disponibili, esegue le chiamate, applica autorizzazioni e guardrail, gestisce errori e retry, conserva checkpoint e determina quando il lavoro è terminato.
Una formula diffusa lo sintetizza così: agente uguale modello più harness. Il modello fornisce la capacità di interpretare e decidere; l’harness gli permette di interagire con sistemi esterni e mantiene il processo entro confini operativi. OpenAI descrive il proprio Agents SDK come uno strato che gestisce turni, strumenti, guardrail, handoff e sessioni; Anthropic usa il termine harness parlando delle architetture che sostengono attività autonome di lunga durata.
Il Context Engineering è dunque una funzione dell’harness, non un suo sinonimo. Il context manager decide quale working set presentare al modello. Il resto dell’harness esegue e controlla ciò che accade prima e dopo quella decisione.
Un esempio chiarisce la differenza. Conservare il risultato voluminoso di una query all’esterno, filtrarlo e presentare al modello soltanto le righe pertinenti è Context Engineering. Eseguire la query in un ambiente isolato, verificarne i permessi, interromperla in caso di errore e ritentarla appartiene all’harness. Le due funzioni collaborano, ma rispondono a problemi differenti.
Dal caricamento preventivo alla scoperta progressiva
Una delle trasformazioni più interessanti riguarda il momento in cui le informazioni vengono recuperate. Nel RAG tradizionale, il sistema effettua una ricerca prima dell’inferenza e inserisce nel prompt i documenti ritenuti pertinenti. Negli agenti sta emergendo un approccio più dinamico: il modello riceve inizialmente riferimenti e strumenti e recupera progressivamente ciò che gli serve.
Un agente che lavora su un repository software, per esempio, non deve necessariamente caricare l’intero codice. Può esaminare la struttura delle directory, cercare simboli, aprire i file pertinenti e approfondire soltanto le dipendenze necessarie. Lo stesso principio può essere applicato a un archivio documentale, a un sistema di ticket o a una piattaforma di osservabilità.
Anthropic parla di contesto “just in time” e di progressive disclosure: ogni esplorazione produce segnali che orientano quella successiva. Il vantaggio è un contesto più piccolo e aderente al compito. Lo svantaggio è un maggior numero di operazioni, con costi e latenza aggiuntivi, e il rischio che l’agente segua una pista sbagliata o non recuperi una fonte decisiva.
Non esiste perciò una soluzione universale. Un sistema può precaricare istruzioni, policy e informazioni stabili, recuperare preventivamente alcune fonti prevedibili e lasciare all’agente la ricerca dei dettagli. Il punto di equilibrio dipende dal rischio, dalla variabilità del dominio e dal costo di un’omissione.
I metodi disponibili per costruire il contesto
Non esiste un singolo “tool di Context Engineering”. La pratica combina metodi che intervengono in momenti differenti del ciclo dell’agente.
Istruzioni e contesto statico. Informazioni sempre valide – ruolo, obiettivi, regole, formati e pochi esempi canonici – possono essere inserite nelle istruzioni di sistema. Devono però rimanere essenziali. Un manuale monolitico occupa spazio, invecchia rapidamente e rende difficile distinguere le regole davvero importanti. Nel descrivere il lavoro svolto con Codex, OpenAI suggerisce di fornire all’agente una mappa verso fonti più dettagliate invece di caricare un enorme file di istruzioni.
Retrieval e reranking. Motori di ricerca, vector store, database e knowledge graph recuperano contenuti aziendali pertinenti. Il retrieval ibrido combina normalmente ricerca lessicale e semantica; filtri sui metadati e reranking riducono i risultati prima dell’inserimento nella finestra. Il RAG diventa Context Engineering quando la strategia di recupero viene adattata al compito e valutata insieme al risultato finale.
Selezione dinamica degli strumenti. Caricare nel prompt le descrizioni di centinaia di tool può generare confusione. Un registro può recuperarne soltanto un piccolo sottoinsieme in base alla richiesta, mentre MCP permette di scoprirli e invocarli attraverso un’interfaccia comune. La selezione dei tool diventa così una forma di retrieval applicata alle capacità, non ai documenti.
Memoria e stato esterni. Cronologia, preferenze, decisioni e avanzamento possono essere conservati fuori dalla finestra, in session store, database o file. Il modello riceve soltanto lo stato necessario al passaggio corrente. Occorre distinguere lo scratchpad della singola esecuzione dalla memoria persistente e stabilire politiche di selezione, aggiornamento, scadenza e accesso.
Compattazione e offloading. Quando la cronologia cresce, i passaggi meno recenti possono essere sintetizzati, mentre i grandi risultati degli strumenti vengono sostituiti da riferimenti a file o oggetti interrogabili. Il modello mantiene una sintesi operativa e può recuperare il dettaglio su richiesta. La compattazione deve conservare decisioni, vincoli e problemi irrisolti: una sintesi troppo aggressiva crea un nuovo tipo di perdita del contesto.
Isolamento. Sottoattività molto voluminose possono essere affidate a un agente con una finestra separata oppure eseguite in un sandbox. Al coordinatore ritorna soltanto un risultato strutturato. L’isolamento riduce l’inquinamento del contesto principale, ma introduce costi di coordinamento e il rischio che nell’handoff vadano persi dettagli importanti.
Caching. I blocchi stabili e riutilizzati — istruzioni, specifiche o documentazione — possono essere memorizzati dal provider per ridurre costo e latenza. Il caching non seleziona il contesto e non ne migliora la qualità: rende più economico riutilizzare una scelta già compiuta.
Evaluation e osservabilità. È necessario tracciare quali istruzioni, documenti, memorie e strumenti siano stati presentati in ogni chiamata. Dataset di prova, confronti tra varianti e metriche su qualità, token, latenza e tool selection permettono di capire se una modifica aiuta davvero. Senza questo ciclo, il Context Engineering rimane affidato all’intuizione.
Framework e piattaforme: chi fa che cosa
I framework per agenti implementano ormai molte di queste funzioni, ma con perimetri differenti. LangChain, LangGraph e Deep Agents sono tre progetti open source sviluppati nello stesso ecosistema da LangChain Inc., ma non sono prodotti equivalenti. LangChain è il framework di più alto livello: fornisce astrazioni e integrazioni per collegare modelli, strumenti e agent loop. LangGraph è invece un runtime di orchestrazione più vicino all’infrastruttura: rappresenta workflow e agenti come grafi, ne conserva lo stato e supporta esecuzione durevole, streaming, checkpoint e intervento umano.
Deep Agents è un agent harness costruito sopra LangGraph. Aggiunge componenti già predisposti per pianificazione, filesystem, memoria, subagent, sandbox e gestione del contesto, ed è rivolto soprattutto ad attività lunghe che richiedono più passaggi. In termini pratici, LangChain aiuta a costruire rapidamente un agente, LangGraph permette di controllarne nel dettaglio il workflow, mentre Deep Agents offre un’impalcatura più completa e opinionated.
Insieme, i tre progetti mostrano come il Context Engineering venga distribuito fra più livelli: middleware che modifica ciò che entra nel modello, store che conserva memoria e stato, selezione dinamica degli strumenti, summarization e offloading dei risultati più grandi. La documentazione LangChain distingue infatti fra contesto del modello, contesto degli strumenti e interventi sul ciclo di esecuzione.
OpenAI Responses API e Agents SDK offrono istruzioni dinamiche, function tool, ricerca, sessioni, limiti sulla cronologia e compattazione. La piattaforma Claude combina MCP, caching, memoria e tecniche di contesto just in time. Microsoft Agent Framework e Foundry IQ affrontano memoria, workflow e accesso governato alla conoscenza aziendale. Nessuno di questi prodotti coincide però con l’intero Context Engineering: ciascuno fornisce alcuni dei meccanismi con cui implementarlo. Il confronto fra framework, servizi gestiti e componenti di retrieval richiede perciò una guida separata.
Tre casi applicativi, tre modi di costruire il contesto
Azure SRE Agent: meno strumenti, più controllo
Il caso di Azure SRE Agent, il servizio Microsoft per l’automazione delle attività di Site Reliability Engineering mostra il Context Engineering applicato a un agente operativo. Nel resoconto tecnico dedicato al progetto, il team Microsoft racconta di essere partito con più di cento strumenti specializzati e oltre cinquanta agenti, per poi ridurre l’architettura a cinque strumenti principali e pochi agenti generalisti. Secondo il team, il sistema è diventato più affidabile perché il modello riceveva meno scelte sovrapposte e il contesto veniva frammentato da un minor numero di handoff.
Un problema concreto riguardava le query di telemetria: un singolo risultato poteva superare i duecentomila token. Invece di riversarlo nella finestra, l’agente lo conserva in un ambiente esterno, ne esamina la struttura e usa codice per filtrarlo o calcolare gli indicatori necessari. Al modello ritorna soltanto il risultato dell’analisi. Piano e cronologia vengono gestiti allo stesso modo: il primo è mantenuto come checklist esterna, la seconda viene compattata in una sintesi e in uno stato strutturato.
È una testimonianza tecnica dettagliata, ma pubblicata dallo stesso team che ha realizzato il prodotto e priva di un confronto quantitativo controllato. Documenta bene le decisioni architetturali; dimostra meno solidamente quanto ciascuna abbia contribuito al miglioramento complessivo.
Il data agent di OpenAI: sei livelli per interpretare 70.000 dataset
Il data agent interno descritto da OpenAI illustra invece il problema della conoscenza aziendale. La piattaforma dati comprende oltre 600 petabyte, 70.000 dataset e più di 3.500 utenti interni. In questo ambiente scegliere la tabella corretta richiede di comprenderne non soltanto schema e nome, ma provenienza, logica di costruzione, modalità d’uso e significato aziendale.
L’agente costruisce il contesto attraverso sei livelli: utilizzo storico delle tabelle, annotazioni umane, analisi del codice che le genera, conoscenza istituzionale recuperata da documenti e sistemi collaborativi, memoria delle correzioni e interrogazioni effettuate in tempo reale. Un processo offline normalizza e indicizza i primi livelli; al momento della domanda, il RAG recupera soltanto le informazioni pertinenti, mentre le query live verificano ciò che è mancante o potrebbe essere diventato obsoleto.
Il caso evidenzia che il contesto aziendale non coincide con i documenti: comprende lineage, query precedenti, codice, semantica di business, permessi e memoria. Anche questa rimane però una fonte aziendale. OpenAI pubblica dimensioni e architettura, ma non un benchmark indipendente dell’accuratezza o del risparmio ottenuto; il caso documenta soprattutto il metodo.
Bayer PRINCE: contesto selettivo in un ambiente regolato
PRINCE, il Preclinical Information Center di Bayer, offre un caso meglio documentato e riferito a un settore regolato. La piattaforma integra dati strutturati e non strutturati provenienti da oltre 18.000 studi preclinici. Il chatbot è stato introdotto nel marzo 2024 e il sistema multi-agente nel novembre dello stesso anno. L’architettura e i risultati sono descritti in un articolo pubblicato su Frontiers in Artificial Intelligence e in una successiva analisi tecnica di Thoughtworks.
PRINCE restringe dapprima lo spazio di ricerca mediante filtri ricavati dalla domanda; soltanto dopo seleziona semanticamente i passaggi dei documenti. Per le richieste complesse separa pianificazione, ricerca, verifica della sufficienza delle evidenze e scrittura. Ogni fase riceve un contesto differente: il Text-to-SQL vede soltanto lo schema pertinente, l’agente di reflection confronta domanda ed evidenze raccolte, mentre il writer riceve passaggi selezionati e vincoli di citazione anziché l’intera cronologia.
Lo stato del workflow è conservato in PostgreSQL; log, risultati intermedi e citazioni sono memorizzati separatamente, consentendo di riprendere l’esecuzione dal punto di errore. Le risposte espongono collegamenti ai paragrafi originali e il sistema viene valutato sia end-to-end sia nei passaggi intermedi.
I risultati pubblicati richiedono la consueta cautela: il campione di feedback comprende fra 15 e 20 utenti abituali. Il punteggio medio di facilità d’uso è stato 4 su 5; il 75% ha segnalato una riduzione significativa del tempo impiegato nella ricerca e l’introduzione del sistema multi-agente è associata a un miglioramento medio del 30% nei tempi di risposta alle query complesse. Sono dati prodotti dal progetto, non una valutazione indipendente, ma rendono PRINCE il caso più completo fra i tre per architettura, impatto e limiti dichiarati.
Dalla pratica tecnica alla categoria commerciale
Nel 2026 l’espressione è entrata esplicitamente nel lessico dei grandi fornitori. AWS Prescriptive Guidance definisce il Context Engineering come la progettazione di sistemi che assemblano dinamicamente l’insieme ottimale di informazioni per uno specifico compito. IBM lo collega alla trasformazione di dati frammentati, metadati, lineage, governance e segnali in tempo reale in contesto affidabile per gli agenti. Google Cloud lo descrive come la progettazione del sistema di dati e memoria utilizzato dall’AI.
Microsoft è andata oltre, presentando Foundry IQ come una piattaforma di Context Engineering capace di rendere la conoscenza aziendale disponibile agli agenti, applicando identità, sicurezza e policy.
Il passaggio è significativo. Un’espressione nata per descrivere il lavoro degli sviluppatori sta diventando una categoria di piattaforma nella quale confluiscono ricerca enterprise, data integration, semantic layer, knowledge base, governance e agentic retrieval.
È anche il momento in cui il termine rischia di perdere precisione. Se ogni sistema che porta dati a un modello diventa Context Engineering, l’espressione finisce per coincidere con l’intera architettura dell’AI enterprise.
Il confine proposto in precedenza resta quindi importante: una piattaforma di Context Engineering governa ciò che il modello può vedere e utilizzare; non coincide automaticamente con l’intera infrastruttura di esecuzione dell’agente.
Il contesto è anche una superficie di attacco
Recuperare informazioni da documenti, siti, email, strumenti e altri agenti significa introdurre nella finestra contenuti con livelli di attendibilità differenti. Un’istruzione malevola nascosta in una pagina o nel risultato di un tool può tentare di modificare il comportamento dell’agente. Se viene poi salvata nella memoria, l’effetto può persistere oltre la singola interazione.
L’OWASP GenAI Security Project include infatti il Memory and Context Poisoning tra i rischi delle applicazioni agentiche: riassunti, embedding, archivi RAG e memorie possono essere alterati in modo da influenzare successive decisioni o chiamate agli strumenti. Il Context Engineering deve quindi conservare provenienza, identità e autorizzazioni insieme ai contenuti, separare le istruzioni dai dati non affidabili e impedire che qualsiasi risultato venga promosso automaticamente a memoria duratura.
La difesa non può dipendere soltanto dalla capacità del modello di riconoscere un attacco. OpenAI propone di considerare insieme la fonte dalla quale può arrivare l’influenza ostile e la capacità pericolosa che potrebbe essere utilizzata. Least privilege, sandbox, conferme per le azioni sensibili, validazione deterministica degli output e controllo delle destinazioni limitano l’impatto anche quando il contenuto malevolo non viene identificato. In questo punto Context Engineering, sicurezza e harness tornano necessariamente a sovrapporsi.
Il contesto deve essere misurato
L’ultima differenza fra una collezione di tecniche e una disciplina ingegneristica riguarda la valutazione. Non basta aggiungere retrieval, memoria o compattazione e presumere che il sistema sia migliorato. Ogni intervento può introdurre nuove omissioni o distorsioni.
La selezione può eliminare una fonte necessaria. Una sintesi può perdere un’eccezione decisiva. La memoria può recuperare un fatto corretto ma riferito a un altro utente. La descrizione di uno strumento può indurre il modello a sceglierlo nel contesto sbagliato. Un documento non affidabile può contaminare le fasi successive.
Servono quindi dataset di valutazione rappresentativi dei compiti reali, tracing delle fonti e delle trasformazioni, misure di precisione del retrieval, test sulla scelta degli strumenti e verifiche end-to-end. Accuratezza, costo e latenza devono essere osservati insieme, perché un contesto più ricco può migliorare un indicatore e peggiorarne altri.
Il Context Engineering non promette di eliminare le allucinazioni né di rendere deterministico un modello probabilistico. Offre piuttosto una leva controllabile: progettare l’ambiente informativo nel quale il modello prende le proprie decisioni e misurare come ciascuna scelta ne modifica il comportamento.
Il modello non è più l’unico centro del progetto
L’affermazione secondo cui i dati valgono più del modello sarebbe altrettanto semplicistica di quella opposta. Modello e contesto svolgono funzioni differenti. Un modello più capace sa interpretare meglio le informazioni, scegliere strumenti e recuperare autonomamente ciò che manca. Ma non può ricostruire documenti ai quali non ha accesso, distinguere una policy vigente da una superata senza metadati o applicare autorizzazioni che il sistema non gli comunica.
La crescita del Context Engineering segnala quindi uno spostamento dell’attenzione: dalle caratteristiche isolate del modello al comportamento dell’applicazione completa. Quando i modelli diventano intercambiabili e gli agenti operano su processi reali, la differenza dipende sempre più da come vengono collegati a conoscenza, strumenti, memoria e regole aziendali.
Non basta più chiedersi quale LLM utilizzare. Occorre stabilire che cosa debba sapere in ogni momento, come possa procurarsi ciò che gli manca, che cosa debba dimenticare e quali prove debba produrre prima di agire. È questo il problema che il Context Engineering sta cercando di trasformare da insieme di espedienti a disciplina progettuale.
