Il context engineering è la nuova infrastruttura di delivery

Dalla serie

Obiettivo

Trattare contesto, memoria operativa, repository, decisioni e feedback come dipendenze architetturali progettate per l’esecuzione affidabile degli agenti.

Come leggerla in pratica

In un SDLC agentico, il contesto non è un prompt più lungo: è una dipendenza architetturale da progettare. Se un agente deve aprire una modifica, generare una proposta o sintetizzare un’opzione tecnica, deve sapere con chiarezza quali fonti sono autorevoli, quali informazioni descrivono soltanto il lavoro corrente e quali sono già superate. Contesto, memoria operativa e fonti autorevoli non sono sinonimi. Il contesto è l’insieme selezionato delle informazioni necessarie per svolgere un’attività. La memoria operativa conserva stato, avanzamento ed evidenze del lavoro corrente. Le fonti autorevoli possiedono invece la verità su decisioni, contratti o dati specifici. La regola pratica è assegnare a ogni informazione una fonte proprietaria e dichiarare la precedenza quando più fonti possono entrare in conflitto. Da architetto, il tuo obiettivo non è dare più contesto, ma fornire il contesto minimo corretto. Quando due fonti confliggono, l’agente non dovrebbe indovinare: deve sapere quale prevale oppure fermarsi e rendere visibile l’ambiguità. Questo rende il comportamento ripetibile, verificabile e più facile da discutere con il team.

Trade-off da considerare

Più contesto non significa migliore qualità. Aggiungere documenti, chat e note senza governance aumenta il rischio di contraddizioni, introduce rumore e rende difficile ricostruire l’origine di una decisione. Un contesto più selettivo e versionato migliora l’affidabilità, ma richiede disciplina: responsabilità chiare sulle fonti, aggiornamento continuo e meccanismi per segnalare informazioni obsolete. C’è anche un costo di progettazione. Separare memoria operativa, repository, dati runtime e feedbackGlossarioFeedbackUn segnale del lettore usato per migliorare i contenuti e le scelte editoriali future.Apri la voce completa implica definire confini, permessi e regole di aggiornamento. È meno comodo all’inizio, ma evita il classico effetto collaterale degli agenti bravi a scrivere e deboli nel rispettare la verità del sistema. In pratica, si scambia velocità apparente con affidabilità reale.

Esempio enterprise realistico

Immagina un team di piattaforma in una banca che usa agenti per preparare note di rilascio e proposte di modifica. Se l’agente legge soltanto la conversazione corrente, può citare una policy superata o una dipendenza già dismessa. Se invece il flusso recupera le decisioni architetturali dal repository, lo stato del lavoro dal sistema operativo che lo governa e le eccezioni approvate dal registro di governance, il risultato diventa molto più affidabile. In questo scenarioGlossarioScenarioUna situazione concreta usata per testare come un design o una decisione si comporta.Apri la voce completa, il valore non sta nel capire tutto, ma nel ricostruire il minimo contesto corretto per quella specifica attività. Il team può così rivedere le proposte dell’agente come qualsiasi altro artefatto di delivery: con fonti, precedenze e responsabilità chiare.

Per approfondire

Fonti autorevoli per approfondire la progettazione del contesto operativo e degli ambienti che rendono affidabile il lavoro degli agenti. • OpenAI, Harness engineering: leveraging Codex in an agent-first world, https://openai.com/index/harness-engineering/ • Anthropic, Effective context engineeringGlossarioContext EngineeringLa disciplina che progetta, governa, seleziona e rende disponibili le informazioni autorevoli e i feedback necessari a un agente per eseguire un'attività in modo affidabile.Apri la voce completa for AI agents, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents