Embodied cognition e tool use agentico: estendere la mente, non incarnarla

Un coding agent legge un file, lancia un grep, edita una funzione, esegue i test, vede un errore, corregge. Questo loop — operativo, prosaico, quotidiano nel 2026 — è la forma più diffusa in cui un sistema LLM “estende la propria cognizione” oltre i pesi del modello. È anche la forma più frequentemente confusa con embodiment. Il capitolo articola il legame con extended mind di Clark e Chalmers, e con la stessa cura traccia la linea oltre cui parlare di tool use come embodiment diventa un errore di classe.

Una scena, un claim limitato

Aprile 2026, terminale di uno sviluppatore. La richiesta a un agent: “fixa il bug nel modulo csv_loader.py per cui le righe con virgolette annidate vengono troncate”. L’agent ha a disposizione un set di tool — read_file, write_file, bash, grep, edit_file — esposti via MCP (Model Context Protocol, lo standard client-server di cui parleremo più avanti). Il loop osservabile, riga per riga, è questo:

Thought: prima leggo il file per capire la struttura.
Action: read_file(path="src/csv_loader.py")
Observation: [contenuto del file, 240 righe]
Thought: il parser usa una regex semplice che non gestisce virgolette annidate. Cerco i test esistenti.
Action: grep(pattern="csv_loader", path="tests/")
Observation: tests/test_csv_loader.py:1-95
Thought: leggo i test per capire i casi attesi.
Action: read_file(path="tests/test_csv_loader.py")
Observation: [contenuto, 95 righe, include test_nested_quotes che fallisce]
Thought: scrivo la patch usando il modulo csv standard invece della regex.
Action: edit_file(path="src/csv_loader.py", old="...", new="...")
Observation: file edited, 12 lines changed
Thought: lancio i test.
Action: bash(cmd="pytest tests/test_csv_loader.py -v")
Observation: 14 passed, 0 failed.
Thought: fix completato.

Questo loop — Thought, Action, Observation ripetuto fino a chiusura — è l’instanziazione canonica del pattern ReAct introdotto da Shunyu Yao (allora dottorando a Princeton, ora in OpenAI) e colleghi nel paper “ReAct: Synergizing Reasoning and Acting in Language Models” (arXiv:2210.03629, ICLR 2023). Il modello LLM, da solo, non avrebbe potuto leggere il file (non ha accesso al filesystem), né eseguire i test (non ha runtime). I tool — funzioni esterne registrate nel context con uno schema JSON — gli concedono questi accessi. Il risultato è un sistema che fa cose che il solo modello non poteva fare.

Da qui il claim filosofico facile: il tool use estende la cognizione del modello oltre i suoi pesi. Lo dice, in forma più cauta, l’argomento dell’extended mind di Andy Clark (filosofo britannico, allora a Washington University in St. Louis, oggi a Sussex) e David Chalmers (filosofo australiano, oggi a NYU), formulato nel breve articolo “The Extended Mind” pubblicato su Analysis 58:7-19 nel 1998 e già discusso in cognizione-embodied. La tesi: se un processo esterno svolge funzionalmente lo stesso ruolo di un processo interno, va contato come parte della cognizione. Otto, paziente con Alzheimer, tiene un quaderno con indirizzi e date. Inga, sana, tiene gli stessi dati nella memoria interna. Per parità funzionale, il quaderno di Otto è parte della sua mente.

L’analogia è seducente. Un coding agent senza tool sarebbe Inga senza memoria; con tool è Otto col quaderno, una mente estesa nel filesystem, nel registry MCP, nel browser. Il claim è onesto se restiamo dentro un perimetro definito: extended cognition in senso funzionalista debole. Diventa errore se scivoliamo verso embodiment forte — la tesi di Maurice Merleau-Ponty (filosofo francese, 1908-1961) sul corpo come soggetto pre-riflessivo della percezione, o quella di Francisco Varela (biologo cileno, 1946-2001) sull’autopoiesi come condizione della cognizione.

Questo capitolo articola il bridge con quel perimetro. Tool use è un’instanziazione ingegneristica plausibile dell’extended cognition di Clark e Chalmers. Non è embodiment forte. La distinzione fa lavoro reale, sia nel descrivere cosa fa un agent (e cosa non fa) sia nel valutare le pretese filosofiche che vi si attaccano.

Perché un ponte qui

Il capitolo precedente, cognizione-embodied, ha presentato la famiglia di tesi che vanno sotto il nome di embodied cognition e ha articolato il framework della cosiddetta 4E cognition — embodied, embedded, enacted, extended. Le quattro Es non sono identiche. Embodied (il corpo è strutturalmente costitutivo della cognizione) e Enacted (la cognizione costituisce il proprio mondo via accoppiamento sensorimotor con metabolismo) sono le tesi forti. Embedded (la cognizione usa l’ambiente come scaffolding) e Extended (un processo esterno funzionalmente equivalente a uno interno è parte della cognizione) sono le tesi più deboli, e più facili da operazionalizzare in sistemi artificiali.

Il capitolo precedente ha anche fissato un’osservazione importante: dei vari pattern AI moderni, il tool use è quello più frequentemente identificato come “estensione” della cognizione del modello. Nella letteratura divulgativa e nei pitch industriali del 2024-2026 si legge spesso “MCP fa dell’LLM una mente estesa”, “il computer use dà al modello un corpo digitale”, “il tool use rompe la barriera disembodied degli LLM”. Frasi che mescolano analogie utili e equivalenze pericolose.

Il ponte serve a separare. Tre obiettivi dichiarati:

Primo, descrivere il tool use con onestà ingegneristica — la storia, i pattern, la meccanica, i limiti. Senza ridurlo né a “function calling potenziato” (perdita di portata) né a “embodiment digitale” (eccesso di portata).

Secondo, mappare con precisione il legame con extended mind. Quale parte di Clark e Chalmers si applica? Quale no? Cosa significa esattamente “extended cognition funzionalista debole” e perché è il claim più solido che il capitolo è disposto a difendere.

Terzo, smontare le equivalenze pericolose. Tool use non è embodiment. MCP non è autopoiesi. Computer use non è un corpo. Il capitolo dedica spazio a queste distinzioni perché sono il punto in cui la divulgazione 2024-2026 più frequentemente scivola.

Il sotto-registro è operativo. Date e nomi del 2022-2026 vivono nel corpo principale, non confinati a sidebar. È legittimo perché il fenomeno è del presente e questo è un capitolo ponte, non un capitolo storico.

Il disclaimer iniziale

Tre punti di igiene, prima della tassonomia.

Primo, cap. 83 ha già fatto il lavoro filosofico pesante. Le quattro Es, le dispute fra rappresentazionalismo ed enattivismo, la replication crisis dell’embodied strong (Goldinger 2016), la critica disembodied di Bender-Koller e LeCun: tutto già esposto. Qui prendo per assodate quelle distinzioni e non le riapro. Riferimento per dettagli: cognizione-embodied.

Secondo, il claim del capitolo è limitato. Tool use non implementa Merleau-Ponty. Non implementa Varela. Implementa, in senso ingegneristico ragionevole, una versione debole di extended mind à la Clark-Chalmers. La frase chiave da tenere in mente: extended cognition funzionalista debole. “Funzionalista” perché l’argomento procede per ruolo funzionale, non per somiglianza materiale. “Debole” perché Clark e Chalmers stessi richiedevano quattro condizioni (disponibilità costante, accessibilità immediata, trust automatico, endorsement cosciente passato) che il tool use moderno soddisfa solo parzialmente — la trust automatica, in particolare, è esplicitamente messa in dubbio dalle vulnerabilità di prompt injection.

Terzo, la filiazione storica del tool use non passa per Clark-Chalmers. I paper fondativi (ReAct, Toolformer, Gorilla) non citano The Extended Mind. La somiglianza fra tool use e extended mind è analogia funzionale, non discendenza documentata. Il tool use AI discende da una tradizione tecnica diversa: function calling nel software ingegneristico, RPC distribuiti, agent architectures BDI, tool selection in RL, plugin in editor di programmazione. Se Clark-Chalmers entrano in scena è perché un’analogia retrospettiva è utile, non perché qualcuno abbia letto loro come ispirazione.

Storia del tool use: dalla function call al MCP

sequenceDiagram
  participant U as Utente
  participant L as LLM
  participant H as Harness
  participant T as Tool esterno
  U->>L: query
  L->>H: tool_use {name, input}
  H->>T: execute(args)
  T->>H: raw result
  H->>L: tool_result {content}
  L->>U: risposta finale
  Note over L,H: loop finché non c'è più tool_use

Figura 1 — Timeline of tool use in LLM agents 2022-2026: ReAct, Toolformer, OpenAI function calling, Gorilla, ToolBench, Claude tool use, computer use, MCP standardization

La traiettoria operativa del tool use in agent LLM è recente — sostanzialmente 2022-2026 — e i suoi snodi principali sono databili al mese.

Ottobre 2022 — ReAct. Shunyu Yao e colleghi, “ReAct: Synergizing Reasoning and Acting in Language Models” (arXiv:2210.03629). Princeton e Google Brain. È il primo paper che mostra empiricamente che alternare reasoning testuale (“Thought”) e azioni nel mondo (“Action”) batte sia il puro CoT (chain-of-thought) sia il puro Act-only su benchmark eterogenei: HotPotQA (multi-hop QA), FEVER (fact verification), ALFWorld (task domestici testuali), WebShop (e-commerce navigation). Il paper non introduce un’API: introduce un pattern di prompt few-shot in cui l’LLM è istruito a produrre un trace strutturato che il harness esterno può parsare e su cui può agire. Il pattern Thought-Action-Observation diventa lo standard implicito di tutto il tool use successivo.

Febbraio 2023 — Toolformer. Timo Schick (allora in Meta AI) e colleghi, “Toolformer: Language Models Can Teach Themselves to Use Tools” (arXiv:2302.04761, NeurIPS 2023). La domanda di partenza: invece di insegnare all’LLM a usare i tool via prompt few-shot, possiamo trainarlo a inserire chiamate API direttamente come parte della generazione? Il metodo è elegante: il modello base annota il proprio training corpus inserendo, per ogni frase, possibili chiamate a un piccolo set di API (calculator, Q&A, web search, calendar, machine translator); si misura se la chiamata, una volta eseguita e il risultato inserito, riduce la perplexity della parte successiva della frase; si filtrano solo le chiamate che riducono perplexity oltre una soglia; si fa fine-tuning sul corpus annotato. Il risultato: GPT-J 6B post-Toolformer batte GPT-3 175B (29× più grande) su SQuAD, MLQA, ASDiv. Il messaggio: i tool sono una forma di knowledge offloading che compensa scala.

Marzo-maggio 2023 — pattern agentici. Reflexion (Noah Shinn et al., NEU + Princeton), Self-Refine (Aman Madaan et al., CMU), AutoGPT, BabyAGI: una proliferazione di harness che combinano LLM + tool + memoria episodica + loop di critique. Tutti già discussi in ponte-metacognizione-self-correction per il loro lato self-correction. Qui rilevanti perché normalizzano il pattern “agent = LLM + tools + loop”.

Giugno 2023 — OpenAI function calling. Annuncio del 13 giugno 2023, “Function calling and other API updates”. Il parametro functions viene aggiunto all’endpoint Chat Completions; lo sviluppatore fornisce uno schema JSON per ciascun tool; i modelli gpt-3.5-turbo-0613 e gpt-4-0613 sono fine-tunati per produrre output strutturato function_call: {name, arguments}. È l’industrializzazione del pattern: function calling smette di essere un’abilità da elicitare via prompt, diventa una primitiva dell’API. Lo stesso anno Anthropic introduce tool use in beta (gennaio 2024) e Google segue con function calling in Gemini.

Maggio 2023 — Gorilla. Shishir Patil (UC Berkeley) e colleghi, “Gorilla: Large Language Model Connected with Massive APIs” (arXiv:2305.15334). Il problema affrontato: con un large tool registry (1645 ML model API di HuggingFace, TorchHub, TensorHub) i modelli base hallucinano tool inesistenti il 52% delle volte (GPT-4 baseline). Soluzione: retrieval-aware training — durante il fine-tuning, retrieve documentazione API rilevante e includila nel prompt; il modello impara a condizionarsi sulla documentazione recuperata. Hallucination scende al 14%. Gorilla introduce un principio che diventerà standard: non addestrare il modello a memorizzare tutti i tool, addestrarlo a usare correttamente i tool che gli vengono mostrati nel context.

Luglio 2023 — ToolBench / ToolLLM. Yujia Qin (Tsinghua) e colleghi, “ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs” (arXiv:2307.16789, ICLR 2024). Benchmark con 16464 API reali estratte da RapidAPI; fine-tuning ToolLLaMA via DFS-based Decision Tree (DFSDT). Il punto: scalare il numero di tool oltre il piccolo set di Toolformer e oltre il dominio limitato di Gorilla.

Aprile 2024 — Anthropic Claude tool use GA. Tool use API Anthropic passa da beta a General Availability. Schema JSON, parallel tool calls, parametro tool_choice per controllo (auto, any, tool specifico). Claude 3 Opus e Sonnet diventano i primi modelli “tool use first” in cui il pattern è centrale al training, non un add-on.

Ottobre 2024 — computer use. Anthropic annuncia il 22 ottobre 2024 “computer use” su Claude 3.5 Sonnet (new). Il modello riceve uno screenshot del desktop e ha accesso a tre primitive: screenshot (rilegge lo schermo), mouse_click(x, y) (clicca a coordinate), keyboard_type(text). Benchmark OSWorld (Tianbao Xie et al. 2024, suite di 369 task reali su sistemi operativi) passa da 7.7% (zero-shot) a 14% (computer use) e poi a 22% con scaffolding più elaborato. Numeri ancora bassi in assoluto ma in rapida progressione. È il primo modello commerciale che vede e agisce su una GUI generica senza API dedicate.

Novembre 2024 — Model Context Protocol (MCP). Anthropic annuncia il 25 novembre 2024 “Introducing the Model Context Protocol”, una specifica open source per esporre tool, dati e prompt a modelli LLM via JSON-RPC. Tre primitive: Resources (dati read-only, simili a file URI), Tools (azioni write, function-call style), Prompts (template parametrici). Trasporti supportati: stdio (subprocess locale) e SSE (Server-Sent Events su HTTP). SDK ufficiali in Python, TypeScript, Java, Kotlin. Il punto strategico: prima di MCP, ogni harness (Claude Desktop, Cursor, Continue, Aider) gestiva tool integration in modo proprio; dopo MCP, esiste una superficie standard. Il marketplace di server MCP cresce rapidamente fra dicembre 2024 e aprile 2025: filesystem, GitHub, Slack, Google Drive, Postgres, Brave Search, Puppeteer, e centinaia di server custom.

2025-2026 — agentic harness consolidation. Claude Code (CLI Anthropic), Cursor agentic mode, Devin, Aider, Continue, Cline: ecosystem di tool che convergono su MCP come superficie comune e su pattern simili (slash commands, hooks, skills, multi-agent orchestration). Il pattern emergente del 2026 è il multi-agent orchestration via tool: agent che chiamano altri agent come tool, fan-out parallelo per task indipendenti, subagent isolation come pattern di context engineering.

sequenceDiagram
  participant U as Utente
  participant L as LLM
  participant H as Harness
  participant T as Tool esterno
  U->>L: query
  L->>H: tool_use {name, input}
  H->>T: execute(args)
  T->>H: raw result
  H->>L: tool_result {content}
  L->>U: risposta finale
  Note over L,H: loop finché non c'è più tool_use

Figura 1 — MCP architecture: Host (Claude Desktop / Claude Code / Cursor) connects to multiple MCP Clients, each connected via JSON-RPC to an MCP Server exposing Resources / Tools / Prompts

La traiettoria è coerente. Si parte da un pattern di prompt (ReAct), si passa per fine-tuning specifici (Toolformer, Gorilla), si arriva a primitive d’API (function calling), poi a modelli “tool use first” (Claude 3-4), poi a una superficie GUI generica (computer use), infine a uno standard di interoperabilità (MCP). Quattro anni in tutto. La velocità è degna di nota.

Tassonomia dei tool

sequenceDiagram
  participant U as Utente
  participant L as LLM
  participant H as Harness
  participant T as Tool esterno
  U->>L: query
  L->>H: tool_use {name, input}
  H->>T: execute(args)
  T->>H: raw result
  H->>L: tool_result {content}
  L->>U: risposta finale
  Note over L,H: loop finché non c'è più tool_use

Figura 1 — Tool taxonomy radial: center “Agent tools”, six leaves (Computational, Information retrieval, External actions, Code execution, File system, GUI/Browser) in one color family, separated leaf “Robotic actions” in different color marking the qualitative jump to embodiment

Sei famiglie principali nel mondo digitale; una settima, separata, marca il salto qualitativo verso l’embodiment.

Computational tools. Python interpreter, calculator, math solver (Wolfram Alpha plugin), unit converter, regex engine, SAT solver. Sono tool che eseguono calcolo deterministico. Caratteristica chiave: idempotenti (stesso input, stesso output) e cacheable. Esempio canonico: il code interpreter di OpenAI (luglio 2023) e il Python tool di Claude — il modello scrive codice Python, un sandbox lo esegue, il risultato torna come testo (eventualmente con plot inline come immagini).

Information retrieval tools. Web search (Brave, Tavily, Exa, Perplexity API), vector DB query, RAG pipeline (retrieval-augmented generation), document chunk retrieval, knowledge graph query. Read-only, generalmente idempotenti modulo aggiornamento dell’indice. Esempio: l’agent di ricerca che riceve “trova i tre paper più citati su MoE 2024”, lancia search, leggi tre URL, sintetizza.

External actions (write). Send email (Gmail tool), create calendar event (Google Calendar), post Slack message, create Jira ticket, send transaction blockchain, post tweet, place order. Side-effecting nel mondo esterno, quindi non idempotenti e generalmente irreversibili. Richiedono permission gating esplicito: l’utente conferma prima dell’esecuzione, oppure l’azione è limitata a un budget configurato.

Code execution. REPL Python, REPL JavaScript, sandbox container (Docker, Firecracker microVM), Bash exec, Jupyter kernel, dev container con LSP. Side-effecting con scope limitato a un container effimero. Centrale nei coding agent. Esempio: Claude Code che lancia pytest, vede l’output, decide il prossimo passo.

File system. read_file, write_file, edit_file, glob, grep. Locale o remoto. Combinato con code execution costituisce il core di un coding agent. Vincoli: permission scope (read-only vs write), path restrictions (directory whitelisted), limiti di dimensione.

GUI / Browser. Playwright primitives (click, type, select, screenshot, navigate), Puppeteer, Anthropic computer use (raw mouse/keyboard a coordinate), browser-use library. La differenza qualitativa rispetto agli altri tool digitali: la superficie d’azione è un’immagine pixel (screenshot) invece che un’API tipata. Il modello deve fare visual grounding di elementi UI. Più rumorosa, più lenta, più fragile, ma generale rispetto a qualunque applicazione.

Robotic actions. Comandi end-effector di un VLA (Vision-Language-Action model) come RT-2 (Anthony Brohan et al., Google DeepMind 2023) o OpenVLA (Stanford 2024). Già trattati in cognizione-embodied. Citati qui per contrasto: l’azione di un VLA su un braccio robotico ha (a) un corpo continuo con dinamica fisica, (b) feedback sensorimotor in tempo reale (proprioception, force sensing), (c) accoppiamento causale stretto fra azione e ambiente. Le altre sei famiglie non hanno nessuno dei tre. È embodiment forte, non solo tool use. La separazione cromatica nella figura 2 marca questo salto.

La meccanica: come funziona il tool use

Pattern canonico — funziona in modo simile per OpenAI, Anthropic, Google, e per modelli open weights addestrati a tool use (Llama 3.1+, Qwen2.5-Coder, DeepSeek-V3).

Passo 1 — tool definition. Lo sviluppatore definisce uno schema per ciascun tool: nome, descrizione testuale (visibile al modello), schema JSON dei parametri (type, properties, required, description per ogni parametro). Esempio minimale, in formato Anthropic:

{
  "name": "get_weather",
  "description": "Get current weather for a location",
  "input_schema": {
    "type": "object",
    "properties": {
      "location": {"type": "string", "description": "City name or coordinates"},
      "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
    },
    "required": ["location"]
  }
}

La descrizione testuale è cruciale: è il principale segnale che il modello usa per decidere quando chiamare questo tool e con quali argomenti. Una descrizione vaga produce tool selection errors; una descrizione precisa produce comportamenti affidabili. È prompt engineering applicato all’API surface.

Passo 2 — tool registration. Lo schema viene incluso nel parametro tools della chiamata API. Il modello riceve la lista come parte del context, formattata in un modo specifico al training del modello (system prompt augmentato, messaggi speciali, o token markers).

Passo 3 — tool selection. Il modello, condizionato su (a) la query utente, (b) la storia conversazionale, (c) la lista dei tool disponibili, decide se chiamare un tool e quale. L’output non è testo libero ma un blocco strutturato — in Anthropic il tool_use block, in OpenAI il function_call field — con campi name e input (parametri come oggetto JSON).

Passo 4 — argument generation. Stesso step del precedente nella generazione del modello: i parametri vengono riempiti coerentemente allo schema. La validation lato harness verifica che l’output sia JSON valido e matchi lo schema; se non lo fa, l’harness restituisce un errore al modello che può ritentare. Tecniche di constrained decoding (logit masking, grammar-constrained generation) garantiscono validità sintattica by construction.

Passo 5 — tool execution. L’harness — il codice client che orchestra la conversazione — intercetta il tool_use block, identifica la funzione corrispondente nel proprio registry, la chiama con gli argomenti (HTTP request, subprocess exec, DB query, qualsiasi cosa), riceve il risultato (testo, JSON, immagine, errore).

Passo 6 — tool result return. L’harness inserisce un tool_result block nel context, con un tool_use_id che fa match con il tool_use originale. Il modello rilegge il context aumentato.

Passo 7 — LLM continues. Il modello produce la prossima generazione: o un altro tool_use block (loop), o un blocco di testo finale (terminazione). Il harness loopa fino a quando non ci sono più tool_use, oppure fino a un budget massimo configurato (max_iterations).

Pseudocodice del harness lato client (semplificato):

messages = [{"role": "user", "content": query}]
while True:
    response = client.messages.create(
        model="claude-opus-4",
        tools=tool_schemas,
        messages=messages,
    )
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason != "tool_use":
        break
    tool_results = []
    for block in response.content:
        if block.type == "tool_use":
            result = execute_tool(block.name, block.input)
            tool_results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": result,
            })
    messages.append({"role": "user", "content": tool_results})
print(response.content[-1].text)

flowchart TB
  H["Host (Claude Desktop / Claude Code / Cursor)"]
  H --> C1["MCP Client A"]
  H --> C2["MCP Client B"]
  H --> C3["MCP Client C"]
  C1 -->|JSON-RPC stdio/SSE| S1["Filesystem MCP Server"]
  C2 -->|JSON-RPC stdio/SSE| S2["GitHub MCP Server"]
  C3 -->|JSON-RPC stdio/SSE| S3["Custom MCP Server"]
  S1 --- R1["Resources / Tools / Prompts"]
  S2 --- R2["Resources / Tools / Prompts"]
  S3 --- R3["Resources / Tools / Prompts"]

Figura 4 — Tool use loop sequence diagram: User -> LLM (query); LLM -> Harness (tool_use); Harness -> External Tool (execute); External Tool -> Harness (raw result); Harness -> LLM (tool_result); LLM -> User (final answer). Loop arrow over “until no more tool_use”

Questa è la base. Tutto il resto sono variazioni: parallel tool calls (l’LLM emette N tool_use simultanei nello stesso assistant turn, l’harness li esegue in parallelo), MCP (i tool non sono definiti nel codice client ma scoperti dinamicamente da server MCP esterni), tool retrieval (con 1000+ tool, prima si fa retrieval dei top-k tool rilevanti per la query, poi si passano solo quelli al modello).

Pattern operativi

Sette pattern ricorrenti, ordinati per complessità.

Single-shot tool call. Una sola chiamata, una sola risposta. “Che ore sono a Tokyo?” → get_time(timezone="Asia/Tokyo") → 03:14. Caso d’uso più semplice, copre una grande percentuale del tool use in production (FAQ con knowledge base, lookup CRM, calcoli singoli).

Multi-step tool use (ReAct loop). Più tool calls in sequenza, ognuna condizionata dalle precedenti. Esempio: domanda multi-hop “qual è la capitale del paese che ha vinto i mondiali di calcio nel 2022?” → web_search("FIFA World Cup 2022 winner") → “Argentina” → web_search("capital of Argentina") → “Buenos Aires”. Il modello deve mantenere uno stato implicito attraverso il context.

Tool composition (pipeline). L’output di un tool diventa input di un altro. Pattern frequente nei research agent: web_search → read_url → summarize → cite. La composizione può essere lineare o ad albero (fan-out su più sottotask, poi fan-in).

Tool selection con large registry (routing). Con 100+ o 1000+ tool, l’LLM viene overwhelmed: la lista di schema diventa lunga, il modello fatica a scegliere il tool giusto, il context si gonfia. Soluzioni: retrieval-based tool selection (Gorilla style — embedding del query e dei tool description, top-k retrieval, mostro al modello solo i k più rilevanti); routing LLM gerarchico (un primo modello classifica la query in macro-categoria, poi un secondo vede solo i tool della categoria); MCP server discovery (l’host scopre dinamicamente quali server sono disponibili e attiva solo quelli necessari per la sessione).

Error recovery. Il tool restituisce errore (HTTP 500, file not found, syntax error). Il modello deve leggere il messaggio di errore, decidere se è un errore recuperabile (argomenti malformati → riprova con argomenti corretti), un errore transitorio (timeout → retry con backoff), o un errore terminale (permission denied → escalate all’utente). Il pattern è osservabile in coding agent moderni: leggono i traceback, identificano la riga d’errore, propongono un fix.

Constrained generation. Garantire by construction che l’output del modello sia un tool_use sintatticamente valido. Tecniche: logit masking (a ogni step di decoding, azzero le probabilità dei token che violerebbero la grammatica JSON o lo schema specifico), grammar-constrained decoding (Earley parser sul prefisso generato, accetto solo token che mantengono il prefisso parseable). Critico per tool use affidabile: senza vincoli, anche modelli grandi producono occasionalmente JSON malformato (virgole mancanti, escape errati).

Parallel tool calls. L’LLM emette N tool_use block simultaneamente nello stesso assistant turn. L’harness li esegue in parallelo (un thread per tool call), raccoglie tutti i tool_result, li passa al modello insieme. Caso d’uso: query indipendenti — “qual è il meteo a Roma, Tokyo, e New York?” → tre get_weather paralleli invece che tre seriali. Pattern formalizzato in Anthropic API a fine 2024 con il flag disable_parallel_tool_use opzionale.

Limiti e fallimenti

Sei modi tipici in cui il tool use rompe.

Tool selection errors. Il modello sceglie un tool sbagliato, o non chiama un tool quando dovrebbe (e produce risposta from-memory possibilmente sbagliata), o chiama un tool quando non dovrebbe (overhead inutile). Frequenza: dipende dalla qualità delle descrizioni dei tool e dall’overlap semantico fra di loro. Mitigazione: descrizioni precise con esempi positivi e negativi nel campo description, riduzione del numero di tool esposti per turno.

Argument errors. Parametri malformati: tipo sbagliato (string invece di int), valore fuori range, formato data non parseable, encoding errato. Mitigazione: schema JSON stretto con type, enum, pattern regex; validation lato harness con messaggio d’errore esplicito che il modello può leggere e correggere.

Hallucinated tool calls. Il modello inventa tool che non esistono (chiama get_user_address(user_id=123) quando il tool registrato è lookup_user(id)). Documentato esplicitamente nel paper Gorilla: GPT-4 baseline hallucina tool inesistenti il 52% delle volte su large registry. Mitigazione: retrieval-aware training (Gorilla), constrained decoding sullo spazio dei tool name, system prompt con lista dei tool disponibili ripetuta.

Brittleness. Cambio API esterna rompe l’agent. Una nuova versione del tool con parametri rinominati, un endpoint deprecato, un cambio di schema di risposta: il modello continua a chiamare con la vecchia signature e produce errori a cascata. Mitigazione: contract testing, MCP server con versioning esplicito, fallback graceful.

Cost e latency. Ogni tool call aggiunge un round-trip: rete, esecuzione, ritorno. Un loop ReAct con 8 tool call in sequenza significa 8 round-trip + 8 chiamate LLM (ognuna con context crescente). Costi e latency si sommano. Mitigazione: parallel tool calls dove possibile, caching idempotente, prompt compression, modelli più piccoli per step di routing.

Sicurezza. Tre vettori principali. SQL injection / command injection: argomenti generati dall’LLM finiscono in SQL o shell command senza sanitization. Prompt injection via tool output: il tool restituisce contenuto controllato da un attaccante (per esempio una pagina web malevola) che contiene istruzioni in forma testuale; il modello, leggendo il tool_result, segue le istruzioni invece dei comandi del legittimo utente. Documentato in Kai Greshake e colleghi (Saarland + CISPA), “Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection” (arXiv:2302.12173, 2023). Permission escalation: tool con permessi più ampi del necessario (write su tutto il filesystem invece che su una directory specifica). Mitigazioni standard: principle of least privilege sui tool, content security policy sul tool output, instruction hierarchy nel modello (Anthropic 2024-2025 ha lavorato esplicitamente su instruction hierarchy per resistere a prompt injection).

Failure mode	Cosa va storto	Mitigazione standard
Selection	tool sbagliato per il task (calculator per ricerca web)	system prompt con descrizioni nette + esempi few-shot
Argument	tool corretto ma argomenti malformati / tipi errati	strict JSON schema validation + retry con error feedback
Hallucination	invenzione di tool inesistenti (52% baseline GPT-4 in Gorilla)	retrieval-aware training, constrained decoding sullo spazio dei tool
Brittleness	cambio API rompe l’agent	contract testing, MCP server con versioning, fallback graceful
Cost / Latency	round-trip e LLM call si sommano	parallel tool calls, caching idempotente, modelli piccoli per il routing
Security	injection (SQL/shell), prompt injection via tool output, permission escalation	least-privilege, sanitization, instruction hierarchy (Anthropic 2024-2025)

La connessione con extended mind: cosa si applica, cosa no

Veniamo al cuore filosofico del capitolo. Tre passaggi: l’argomento pro, l’argomento contro, la posizione che il capitolo sostiene.

L’argomento pro: tool use come extended cognition funzionalista

La Parity Principle di Clark e Chalmers nella formulazione originale del 1998: “if, as we confront some task, a part of the world functions as a process which, were it to go on in the head, we would have no hesitation in recognizing as part of the cognitive process, then that part of the world is part of the cognitive process”. Tradotto in modalità AI: se un tool fa, fuori dal modello, qualcosa che — se il modello lo facesse internamente — chiameremmo cognizione, allora il tool è parte della cognizione del sistema agentico.

Test del principio su tre tool concreti.

Calculator tool. Un LLM con calculator risolve 472 × 891 chiamando il tool e ricevendo 420552. Senza il tool, il modello probabilmente sbaglia (il calcolo aritmetico multi-cifra è fragile nei modelli base, anche grandi). Internalmente, un umano che fa 472 × 891 a mente esegue un processo cognitivo (algoritmo della moltiplicazione, working memory dei riporti). Per parità funzionale: il calculator esterno svolge lo stesso ruolo. Soddisfa il Parity Principle? Plausibilmente sì.

Memory tool / vector DB. Un agent recupera “cosa l’utente ha chiesto la settimana scorsa” da un vector DB. Internalmente, un umano lo recupera dalla memoria episodica. Parità funzionale: ricordo. Soddisfa Parity? Sì, in modo simile a Otto col quaderno.

Web search tool. Un agent risponde “qual è la popolazione attuale di Tokyo?” via web search invece che da memoria parametrica (che è stale al training cutoff). Internalmente, un umano consulterebbe Wikipedia, o ricorderebbe da una lettura recente. Parità funzionale: lookup di fatto. Soddisfa Parity? Sì.

Su questi casi l’argomento pro tiene. Il tool use sembra implementare una forma di extended cognition: il sistema agentico = modello + tool + harness, e la cognizione del sistema include propriamente i tool, non solo i pesi del modello.

L’argomento contro (parte uno): le quattro condizioni di Clark-Chalmers

Clark e Chalmers, nel paper del 1998, non sostengono che qualsiasi processo esterno sia parte della mente. Aggiungono quattro condizioni che il processo deve soddisfare, generalmente note come “the four conditions”:

1. Disponibilità costante — il processo deve essere “regolarmente invocato e usato dal soggetto”.
2. Accessibilità immediata — il processo deve essere disponibile “direttamente, senza ostacoli significativi”.
3. Trust automatico — l’output del processo deve essere “automaticamente endorsato come affidabile, senza scrutinio critico”.
4. Endorsement cosciente passato — il processo deve essere stato “consciously endorsed in the past” dal soggetto come parte del proprio sistema cognitivo.

Test di queste condizioni sul tool use:

Disponibilità costante: soddisfatta per tool registrati nell’harness e attivi nella sessione. MCP server attivi sono regolarmente invocabili. Sì.

Accessibilità immediata: soddisfatta in senso ingegneristico debole (latency di rete, ms-secondi) ma non in senso psicologico stretto (la latency è di ordine di grandezza maggiore di un’operazione cognitiva interna). Parzialmente.

Trust automatico: questa è la condizione più problematica. La trust nei tool non è automatica nei sistemi moderni. Le vulnerabilità di prompt injection (Greshake 2023), le supply chain attack su MCP server (problema di sicurezza emergente 2025-2026), le hallucination del tool stesso, richiedono che l’agent (o un layer di mediazione) faccia scrutinio critico. Il principio di “non fidarti del tool output” è esplicitato in tutte le linee guida di security AI 2024-2026. No, almeno non nel senso forte di Clark-Chalmers.

Endorsement cosciente passato: l’LLM non ha “passato” continuo nel senso fenomenologico richiesto. Una sessione conversazionale ha memoria limitata; episodic memory persistente è un feature aggiunta, non un fatto del modello. Inoltre l’endorsement “cosciente” presuppone fenomenalità che il capitolo hard-problem-chalmers ha lasciato come questione aperta per gli LLM. Problematico.

Conclusione del test: tool use soddisfa due condizioni su quattro pienamente, una parzialmente, una problematicamente. È extended cognition in senso indebolito rispetto al paper originale del 1998. Non è scarto totale: Clark stesso, in lavori successivi (Supersizing the Mind 2008, Surfing Uncertainty 2016), ha rilassato alcune condizioni e accettato versioni più liberali. Ma il claim onesto è: “tool use è extended cognition funzionalista debole”, non “tool use è extended mind à la Clark-Chalmers stretto”.

L’argomento contro (parte due): non è embodiment forte

Più forte: il tool use non implementa embodiment forte nei sensi articolati nel cap. 83.

Embodiment Merleau-Ponty (body schema, flesh): assente. Non c’è un corpo continuo che funga da soggetto pre-riflessivo della percezione. Lo screenshot del computer use non è il “lato visibile di un corpo” nel senso fenomenologico. È un’immagine pixel processata frame per frame.

Embodiment Pfeifer-Bongard (morphological computation): assente. La forma fisica del modello (i suoi pesi, l’architettura transformer) non fa “computazione morfologica” nel senso del passive dynamic walker. La computazione è digitale, simbolica, eseguita su silicio general-purpose.

Embodiment Varela-Thompson (autopoiesi, enaction): assente. Manca metabolismo, manca closure operativa, manca la costituzione di un mondo via accoppiamento sensorimotor. Un agent LLM “vive” nel context per la durata di una sessione e cessa. Nessuna persistenza autopoietica.

Embodiment ingegneristico VLA: assente. RT-2 ha corpo continuo, sensori proprioceptivi, attuatori con dinamica fisica, feedback in millisecondi. Un coding agent non ha nulla di tutto questo.

flowchart TB
  H["Host (Claude Desktop / Claude Code / Cursor)"]
  H --> C1["MCP Client A"]
  H --> C2["MCP Client B"]
  H --> C3["MCP Client C"]
  C1 -->|JSON-RPC stdio/SSE| S1["Filesystem MCP Server"]
  C2 -->|JSON-RPC stdio/SSE| S2["GitHub MCP Server"]
  C3 -->|JSON-RPC stdio/SSE| S3["Custom MCP Server"]
  S1 --- R1["Resources / Tools / Prompts"]
  S2 --- R2["Resources / Tools / Prompts"]
  S3 --- R3["Resources / Tools / Prompts"]

Figura 4 — Extended cognition spectrum: horizontal axis “Cognitive extension”. Three points: “Pure LLM” (left, no extension), “Tool-augmented LLM” (middle, extended functionally), “Embodied robot” (right, embodied physically). Three sub-axes per point: Corporeality (none / digital / physical), Sensorimotor feedback (none / partial async / continuous real-time), Autopoiesis (none / none / none — note: even VLA lacks it)

La posizione del capitolo

Tesi: il tool use in agent LLM è un’instanziazione ingegneristica plausibile di extended cognition funzionalista debole. Non è embodiment forte. Non è Clark-Chalmers stretto, ma una versione liberalizzata (Clark 2008+).

Questa tesi consente di dire cose vere e di non dire cose false. Cose vere:

• Un coding agent con tool MCP fa cose che il solo modello non poteva fare; in questo senso la sua cognizione è estesa.
• L’analogia con Otto-quaderno è didatticamente utile: aiuta a vedere il tool registry come una memoria esterna funzionalmente integrata.
• L’extended cognition funzionalista ha implicazioni progettuali concrete: design dei tool come parte del design cognitivo dell’agent, non come dettaglio di implementazione.

Cose false (da non dire):

• “Il tool use rende l’LLM embodied”. Falso. Manca corpo, manca feedback sensorimotor stretto, manca autopoiesi.
• “MCP è la mente estesa di Claude”. Iperbolico. MCP è infrastruttura, non mente; la mente estesa è una descrizione filosofica, non un’architettura tecnica.
• “Computer use chiude la critica disembodied di Bender-Koller”. Falso. La critica riguardava grounding referenziale al mondo via accoppiamento sensorimotor con metabolismo; computer use non lo fornisce.

Casi d’uso 2024-2026

Cinque settori in cui il tool use è in produzione su scala.

Coding assistants. Claude Code (CLI Anthropic, 2024-2026), Cursor agentic mode, Continue, Aider, Devin, Cline. Set di tool tipico: read_file, write_file, edit_file, glob, grep, bash, git, lsp (language server protocol per definitions/references). Pattern: ReAct loop, multi-step, con sub-agent per task indipendenti. Metrica osservata: SWE-bench Verified passa dal 12% (2023, GPT-4 + agent harness primitivo) al 65%+ (2026, Claude 4 Opus + Claude Code) nei primi tre anni del benchmark.

Research agents. Perplexity, Anthropic research preview, OpenAI Deep Research, Gemini Deep Research. Set di tool: web search, URL fetcher, document parser (PDF, HTML), summarizer, citation tracker. Pattern: tool composition (search → fetch → parse → summarize → cite), spesso con sub-agent paralleli per query indipendenti.

Data analysis. ChatGPT con code interpreter, Claude con Python tool, dedicated platforms come Hex, Mode con AI features. Set di tool: SQL query, Python REPL, dataframe operations, plot rendering. Pattern: spesso single-shot o low-step (l’utente ha una domanda specifica, l’agent scrive una query, esegue, mostra risultato).

Customer support. Zendesk AI, Intercom Fin, agent custom con LangChain/LlamaIndex. Set di tool: CRM lookup, ticket creation, knowledge base search, escalation a umano. Pattern: heavy guardrails, single-shot prevalente, escalation come fallback.

Trading e finanza (con review umana). Bloomberg AI tools, hedge fund custom. Set di tool: market data, order placement (con confirmation), risk calculation. Pattern: il tool use è gateway per operazioni con permission gating molto stretto. Le azioni write sono sempre soggette a revisione.

Esempi concreti

Tre esempi eterogenei, dichiaratamente didattici, che mostrano il tool use in azione.

Esempio 1 — ReAct loop su question answering

Domanda utente: “qual è la popolazione di Tokyo nel 2024 e quanti grattacieli alti più di 200 metri ha?”

Trace dell’agent:

User: qual è la popolazione di Tokyo nel 2024 e quanti grattacieli alti più di 200 metri ha?

Assistant (Thought): la domanda ha due parti, posso cercarle in parallelo.
Assistant (tool_use): web_search(query="Tokyo population 2024")
Assistant (tool_use): web_search(query="Tokyo skyscrapers over 200 meters")

Tool result A: "Tokyo metropolis: approx 13.96 million (2024 estimate, Tokyo Metropolitan Government). Greater Tokyo Area: approx 37.4 million."
Tool result B: "Tokyo has approximately 50 buildings taller than 200 meters as of 2024, including Tokyo Skytree (634m, broadcast tower), Toranomon Hills Mori Tower (266m), Azabudai Hills Mori JP Tower (330m, completed 2023)."

Assistant (Thought): ho entrambe le informazioni, posso rispondere.
Assistant (text): "Tokyo metropolis ha circa 13,96 milioni di abitanti nel 2024 (Greater Tokyo Area circa 37,4 milioni). I grattacieli oltre i 200 metri sono circa 50, fra cui Azabudai Hills Mori JP Tower (330m, 2023) e Toranomon Hills Mori Tower (266m). Tokyo Skytree (634m) è una torre broadcast, non un grattacielo abitabile."

Punti rilevanti dell’esempio. Parallel tool calls nel turno iniziale: l’agent emette due tool_use simultanei, l’harness li esegue in parallelo, riduce latency. Tool composition implicita: i due risultati indipendenti vengono fusi in una risposta sintetica. Critica del tool output: l’agent distingue Tokyo Skytree (torre broadcast) dai grattacieli abitabili — non si fida cieco del tool result, ma lo interpreta. Quest’ultimo punto è esattamente la condizione di “trust automatico” che Clark-Chalmers richiedevano e che, come visto, il tool use moderno non soddisfa: la cognizione critica è ineliminabile.

Esempio 2 — Coding agent (Claude Code style) end-to-end

Task utente: “fixa il bug nel modulo csv_loader.py per cui le righe con virgolette annidate vengono troncate, e aggiungi un test che dimostri il fix”.

Trace dell’agent (semplificato):

T1. Thought: prima esploro la struttura del progetto.
A1. bash(cmd="ls -la")
O1. [output: src/, tests/, README.md, setup.py, ...]

T2. Thought: leggo il modulo target.
A2. read_file(path="src/csv_loader.py")
O2. [contenuto: 240 righe, regex semplice non gestisce nested quotes]

T3. Thought: cerco i test esistenti per capire il pattern.
A3. grep(pattern="csv_loader", path="tests/")
O3. tests/test_csv_loader.py:1-95

T4. Thought: leggo i test.
A4. read_file(path="tests/test_csv_loader.py")
O4. [contenuto: include test_nested_quotes che attualmente fallisce]

T5. Thought: lancio i test per confermare lo stato.
A5. bash(cmd="pytest tests/test_csv_loader.py -v")
O5. [13 passed, 1 failed: test_nested_quotes]

T6. Thought: scrivo la patch sostituendo la regex con il modulo csv standard.
A6. edit_file(path="src/csv_loader.py", old="<vecchia funzione parse>", new="<nuova funzione con csv.reader>")
O6. file edited, 12 lines changed

T7. Thought: rilancio i test.
A7. bash(cmd="pytest tests/test_csv_loader.py -v")
O7. [14 passed, 0 failed]

T8. Thought: aggiungo un test edge-case con virgolette doppie annidate.
A8. edit_file(path="tests/test_csv_loader.py", old="", new="<nuovo test_doubly_nested_quotes>")
O8. file edited, 8 lines added

T9. Thought: verifico.
A9. bash(cmd="pytest tests/test_csv_loader.py -v")
O9. [15 passed, 0 failed]

T10. Thought: fix completato. Riassumo.
A10. text: "Bug fixed: sostituita la regex custom in csv_loader.py con il modulo csv standard, che gestisce nativamente virgolette annidate. Aggiunto test_doubly_nested_quotes per garantire il caso edge. Tutti i 15 test passano."

Dieci step, sei diversi tool, decisioni intermedie basate su tool result. È il caso d’uso più rappresentativo del tool use moderno: la cognizione del sistema agentico è genuinamente distribuita fra modello, filesystem, runtime di test, parser. Senza questi tool il modello potrebbe al massimo proporre una patch testuale; con i tool, può chiudere il loop “fix verificato”.

Esempio 3 — Computer use su browser GUI

Task utente: “vai su Google Flights, cerca un volo Roma-Tokyo per il 15 maggio 2026, prendi screenshot del risultato più economico”.

Trace dell’agent (Anthropic computer use, Claude 3.5 Sonnet new o successivi):

S1. Thought: apro il browser su Google Flights.
A1. screenshot()
O1. [screenshot del desktop attuale]

S2. Thought: il browser è aperto su un'altra pagina, navigo.
A2. keyboard_type(text="https://www.google.com/travel/flights")
A3. keyboard_press(key="enter")

S3. Thought: aspetto il caricamento.
A4. screenshot()
O4. [screenshot di Google Flights]

S5. Thought: vedo i campi "From" e "To". Clicco "From".
A5. mouse_click(x=420, y=312)
A6. keyboard_type(text="Rome FCO")
A7. mouse_click(x=420, y=350)  # primo suggerimento
A8. screenshot()

[continua con clic su "To", inserimento Tokyo, selezione data, conferma ricerca]

S20. Thought: i risultati sono caricati, ordino per prezzo.
A20. mouse_click(x=860, y=180)  # tab "Price"
A21. screenshot()
O21. [screenshot dei risultati ordinati per prezzo]

S22. Thought: il risultato più economico è in alto. Salvo lo screenshot.
A22. text: "Volo più economico Roma FCO - Tokyo NRT per il 15 maggio 2026: ITA Airways via Istanbul, 624 euro. Screenshot allegato."

Ventidue step circa. Visual grounding di elementi UI a coordinate pixel. Fragile (un cambio di layout della pagina rompe le coordinate cached), lento (ogni screenshot è 100KB+ e va processato dal vision encoder), generale (funziona su qualsiasi sito senza API dedicata). È il caso d’uso che più sfida il claim “tool use è digitale, non embodied”: la GUI è una superficie quasi-fisica che richiede percezione visiva e coordinazione mano-occhio simulata. Quasi-fisica. Resta digitale: pixel, coordinate, cliché di interazione GUI. L’analogia con “occhi e mani digitali” è didattica, l’equivalenza con embodiment forte rimane falsa.

Dove si rompe

Sezione ampia. Quattro cliché ricorrenti da smontare e tre limiti operativi da nominare.

Cliché 1 — “tool use rende l’LLM embodied”

Slogan presente in pitch, blog post, talk. Falso. L’embodiment forte richiede corpo continuo, feedback sensorimotor stretto, autopoiesi. Il tool use è interfaccia digitale verso processi esterni; manca tutto e tre. La distinzione è importante perché chi crede di aver “risolto” la critica disembodied attraverso tool use sta credendo a una cosa che non è successa. Le critiche di Emily Bender e Alexander Koller (octopus thought experiment, 2020) e di Yann LeCun (LLM disembodied, 2022+) restano in piedi: il tool use non fornisce grounding referenziale-causale al mondo nel senso che richiedevano.

Cliché 2 — “MCP è la mente estesa di Claude”

Iperbole marketing. MCP è un protocollo di interoperabilità — JSON-RPC con primitive Resources/Tools/Prompts. È infrastruttura tecnica, non architettura cognitiva. Chiamarlo “mente estesa” è scivolamento di classe: confonde la descrizione filosofica (“la cognizione di Claude include i tool MCP”) con l’architettura tecnica (“MCP è il protocollo che espone i tool”). La descrizione filosofica può essere vera (in senso debole, vedi sezione precedente) anche senza che il protocollo sia una mente.

Cliché 3 — “computer use è un corpo digitale”

Analogia, non equivalenza. Computer use ha alcune proprietà che ricordano un corpo: percezione visiva (screenshot), azione motoria (click, type), feedback (next screenshot). Ma il loop è asincrono e granulare (frame-per-azione, non continuo), il “corpo” non ha morfologia (non c’è una geometria fisica che vincoli l’azione), non c’è propriocezione, non c’è dinamica fisica. È un’interfaccia agente-software, non un corpo. La analogia è utile come euristica didattica (“immagina che il modello abbia occhi e mani sullo schermo”), pericolosa come tesi filosofica.

Cliché 4 — “tool use risolve il symbol grounding problem”

Falso o, almeno, sopravvalutato. Il symbol grounding problem (Stevan Harnad 1990, vedi symbol-grounding) chiede come i simboli interni di un sistema acquisiscano significato non-circolarmente, senza appello ad altri simboli. Il tool use connette simboli del modello a chiamate API che eseguono nel mondo, ma le chiamate API restituiscono altri simboli (testo, JSON, immagini-token). Il loop è fra simboli e simboli, non fra simboli e referenti causali nel senso fenomenologico. Il grounding tramite tool use è grounding ingegneristico debole, non risoluzione di Harnad. Per quella servirebbe accoppiamento sensorimotor con metabolismo (Varela), o almeno robotica embodiment (Brooks).

Limite operativo 1 — la composizione profonda è fragile

In teoria un agent può fare loop ReAct di lunghezza arbitraria. In pratica, oltre 8-12 step la performance cala in modo non-lineare. Cause: context length che cresce, attention dilution, error compounding (un errore in step 3 si propaga in step 7), drift di attenzione dal goal originale. Mitigazioni: hierarchical agent (planner + executor), context summarization, sub-agent isolation. Dettagli in agent-harness (in preparazione) e capitoli specifici di Parte XII e XVI.

Limite operativo 2 — la sicurezza via prompt injection

Il tool result è testo, e l’LLM lo legge come parte del context. Se il tool restituisce contenuto controllato da un attaccante (web page, email, document letto via tool), e quel contenuto contiene istruzioni in linguaggio naturale, il modello può seguirle. Documentato sistematicamente in Greshake et al. 2023. Mitigazioni in evoluzione (instruction hierarchy, content marking, sandboxing) ma non risolto al 2026. È il problema di sicurezza più serio del tool use moderno.

Limite operativo 3 — la riproducibilità

Tool result possono variare nel tempo (web search, market data, anche file locali se modificati da altri processi). Un agent run a t=0 produce un risultato; lo stesso run a t=1 ne produce un altro. Per use case che richiedono determinismo (audit, reproducibility scientifica) serve cache snapshotting, version pinning dei tool, time-bounded queries.

Collegamenti

• cognizione-embodied — il capitolo precedente, base filosofica per il bridge. Il framework 4E (embodied, embedded, enacted, extended), Clark-Chalmers, Merleau-Ponty, Varela. Da rileggere per capire perché il claim “tool use = embodiment” è scivolamento di classe.
• ponte-s1-s2-llm — tool use compare lì come una delle famiglie di pattern di deliberation (famiglia 4: agent loop e tool). Qui il tool use è oggetto, non strumento di deliberation.
• ponte-metacognizione-self-correction — CRITIC tool-augmented come pattern grounded di self-correction. Tool use come ancoraggio esterno per chiudere il loop di monitoring.
• mente-estesa — il capitolo specifico su Clark-Chalmers extended mind, Otto-Inga, Parity Principle. Riferimento per il dettaglio filosofico delle quattro condizioni.
• symbol-grounding — perché il tool use non risolve il grounding problem di Harnad.
• funzionalismo — la tesi che la cognizione è caratterizzata dal ruolo funzionale, multiple realizability. Background per “extended cognition funzionalista”.
• era-agenti-2024 — la storia operativa dell’anno in cui MCP, Claude Code, Cursor agentic, computer use sono diventati mainstream.
• react (in preparazione) — il deep-dive tecnico sul pattern ReAct.
• tool-use-fondamenti (in preparazione) — function calling sotto il cofano.
• mcp-introduzione (in preparazione) — motivazioni e architettura del Model Context Protocol.
• browser-computer-use (in preparazione) — agenti che cliccano e vedono schermo.
• agent-harness (in preparazione) — orchestrazione, sandbox, permission model.

Per andare oltre

• Clark, A. & Chalmers, D. (1998), “The Extended Mind”, Analysis 58:7-19. Il paper fondativo. Sei pagine, leggibile in mezz’ora. Le quattro condizioni sono nelle ultime due pagine.
• Clark, A. (2008), Supersizing the Mind: Embodiment, Action, and Cognitive Extension, Oxford UP. La versione liberalizzata di Clark dell’argomento, con risposte alle critiche (Adams-Aizawa, Rupert).
• Yao, S. et al. (2022), “ReAct: Synergizing Reasoning and Acting in Language Models”, arXiv:2210.03629. Il paper fondativo del pattern. Leggibile, esempi chiari.
• Schick, T. et al. (2023), “Toolformer: Language Models Can Teach Themselves to Use Tools”, arXiv:2302.04761. Il paper sul self-supervised tool augmentation. Metodologicamente elegante.
• Mialon, G. et al. (2023), “Augmented Language Models: a Survey”, arXiv:2302.07842. Survey di review, utile per orientarsi nello spazio.
• Anthropic (2024), spec del Model Context Protocol, modelcontextprotocol.io. Documentazione tecnica, esempi di server e client. Punto di partenza pratico.