Passa al contenuto principale

API Multi-Agente Native: Responses Multi-Agent Beta di OpenAI vs Costruirtelo da Solo

Avanzato

Per diciotto mesi, "multi-agente" ha significato che tu scrivevi il fan-out. Scrivevi il prompt del coordinatore, spawnavi N chiamate in parallelo, fondevi il loro JSON, gestivi i retry. Il 9 luglio 2026 OpenAI ha collassato tutto questo in un parametro di richiesta: multi_agent.enabled: true sulla Responses API, avvolto in una feature consumer chiamata Sol Ultra Mode. È il modello stesso a decidere quanti sub-agenti spawnare, li esegue in parallelo, e sintetizza il risultato — tutto dentro una singola chiamata HTTP. Nessun altro vendor frontier ha rilasciato una primitiva simmetrica. Questa pagina mappa cosa è uscito davvero, i numeri dietro, cosa offre Anthropic al suo posto, e — la parte che conta — i tre carichi di lavoro dove la primitiva nativa si guadagna il costo e i due dove un fan-out DIY vince ancora.

What you'll learn
  • Leggere il corpo esatto della richiesta multi-agente sulla Responses API e sapere cosa capa davvero max_concurrent_subagents
  • Fare la matematica dei costi: quanto ti addebita davvero 'il modello spawna 4 sub-agenti' ai prezzi di Sol
  • Mappare lo stesso territorio dal lato Anthropic — Cowork, Managed Agents, e i sub-agenti di Claude Code — e vedere il gap di primitive
  • Scegliere la primitiva giusta per carico di lavoro: multi-agente nativo, fan-out DIY, A2A, o un singolo turno lungo
  • Evitare i quattro failure mode che trasformano una chiamata Ultra a 4 agenti in una bolletta 4x senza guadagno di accuratezza

La versione in una frase​

Ultra Mode è una skin consumer sopra multi_agent.enabled: true della Responses API — una primitiva nativa che permette al modello di spawnare sub-agenti in parallelo dentro una richiesta, sintetizzare i loro output, e restituire una singola risposta. Ti compra un bump di accuratezza piccolo-ma-reale sui task parallelizzabili (Terminal-Bench 2.1: 88.8% → 91.9%), a una bolletta di token che scala grosso modo linearmente con il numero di sub-agenti che il modello sceglie di spawnare.

Cosa è uscito davvero il 9 luglio 2026​

Nello stesso lancio sono atterrate due cose, e vale la pena separarle:

  • Ultra Mode — un toggle di prodotto dentro ChatGPT e Codex. Disponibile sul tier flagship (Sol). Quando abilitato, i task difficili vengono decomposti in run di sub-agenti paralleli prima della sintesi. Marketizzato come "spawna 4+ agenti"; alcune delle stesse grafiche benchmark GA di OpenAI mostrano anche configurazioni a 16 agenti su BrowseComp e SEC-Bench Pro, ma quattro è il default operativo.
  • Responses API multi-agent beta — una primitiva per sviluppatori. La stessa capability sottostante, esposta come multi_agent.enabled: true su client.beta.responses.create(). È questa che useresti per costruire la tua esperienza in stile Ultra.

La confusione lasciata dal marketing è reale: i builder continuano a chiedere "come chiamo Ultra Mode dall'API?" La risposta è che non lo fai — abiliti la beta multi-agente, che è la primitiva sotto la feature di prodotto.

La richiesta multi-agente della Responses API​

Concretamente, questa è la forma (Python SDK):

Chiamata Responses API multi-agente minima

from openai import OpenAI

client = OpenAI()

resp = client.beta.responses.create(
  model="gpt-5.6-sol",
  input="Audit this repo for auth-bypass patterns and write a report.",
  multi_agent={
      "enabled": True,
      "max_concurrent_subagents": 3,
  },
  tools=[...],  # your MCP tools, function tools, etc.
  extra_headers={"OpenAI-Beta": "responses_multi_agent=v1"},
)

Quattro cose non ovvie su questa forma:

  • max_concurrent_subagents non è un budget totale. Capa i turni di sub-agente attivi attraverso l'intero albero in un dato momento — root più discendenti. Il modello può spawnare un numero totale molto maggiore di sub-agenti nell'arco di vita della richiesta; semplicemente non può averne più di N attivi contemporaneamente.
  • La profondità è illimitata. Un sub-agente può a sua volta spawnare sub-agenti. Non c'è un cap fisso sulla profondità dell'albero o sul conteggio totale di sub-agenti per run. La tua superficie di costo non è "N chiamate" — è un albero che il modello modella a runtime.
  • La root sintetizza. L'agente root è responsabile della fusione delle risposte dei sub-agenti nella risposta finale. Non ricevi indietro un oggetto strutturato {subagents: [...]}; ricevi una risposta, e i turni intermedi degli agenti sono opachi al tuo codice.
  • Alcuni parametri vengono disabilitati silenziosamente. reasoning.summary e max_tool_calls non sono supportati con multi-agent abilitato, e l'endpoint di compaction non è supportato per risposte multi-agente. Se ti affidi ai reasoning summary per l'osservabilità, li perdi nell'istante in cui accendi questa modalità.

La matematica dei costi che nessuno stampa sulla pagina marketing​

Al prezzo GA di Sol di $5 input / $30 output per milione di token, l'aritmetica è impietosa. Dai writeup dei builder che hanno fatto reverse-engineering di run Ultra reali:

  • Un task che Ultra decompone in 2 sub-agenti ≈ 2x il costo dei token output di una singola chiamata Sol — perché entrambi i sub-agenti generano output, e poi la root genera la sintesi sopra.
  • Un task in cui Ultra spawna 5 sub-agenti ≈ 5x — stesso ragionamento, più un replay di token input proporzionalmente maggiore attraverso l'albero.
  • Le grafiche BrowseComp / SEC-Bench che mostrano configurazioni a 16 agenti non sono un pasto gratis: sono una dimostrazione di grado ricerca, non un default. A 16 sub-agenti concorrenti su Sol, sei di fronte a una cifra a due cifre medie di dollari per query difficile nei soli token output.

Il modo di pensarci: stai pagando una Monte Carlo di chiamate Sol più un passaggio di sintesi sopra. A volte questo ti compra abbastanza accuratezza da contare. A volte è solo una bolletta 4x per un task che una singola chiamata avrebbe risolto.

Cosa compra davvero l'accuratezza​

I delta pubblicati sulle eval parallelizzabili — i carichi di lavoro per cui Ultra Mode è progettata — sono reali ma modesti:

BenchmarkSol (singolo)Sol UltraDeltaCosa misura l'eval
Terminal-Bench 2.188.8%91.9%+3.1Pianificazione multi-step da riga di comando, coordinamento di tool
BrowseComp87.5%92.2%+4.7Ricerca web multi-fonte e sintesi
SEC-Bench Pro—74.3%(numero single-mode non pubblicato)Ragionamento su documenti regolatori attraverso corpora grandi

Tre punti su questa tabella:

  • La banda di +3–5 punti è consistente con quello che il sampling parallelo ha storicamente comprato su altre frontiere (best-of-N, self-consistency). La primitiva è genuinamente utile; il delta non è un cambio di scalino.
  • Questi sono il best case — valutazioni scelte per mostrare bene la modalità. Sui task sequenziali (una modifica di codice lineare, la riscrittura di un singolo file, una chat breve), Ultra aggiunge latenza di sintesi e costo senza muovere l'accuratezza.
  • Sulla stessa grafica Terminal-Bench 2.1, Opus 4.8 di Anthropic ha segnato 78.9% — significa che il vantaggio di Sol Ultra viene da entrambi il modello base migliore e il boost multi-agente impilato sopra. Se migri a Sol Ultra da Opus, non attribuire tutto il gap alla primitiva multi-agente.

Cosa fa Anthropic al suo posto​

Anthropic non ha rilasciato una primitiva API simmetrica. Gli analoghi più vicini risolvono ciascuno una fetta diversa dello stesso problema:

  • Cowork — una superficie di prodotto. Uno spazio di lavoro desktop agentico dove un agente svolge lavoro sostenuto multi-step accanto all'utente. Paragonabile a Ultra Mode come feature, ma non come primitiva API.
  • Managed Agents e i managed-agents memory stores — un loop di agente hostato con stato persistente e scheduling. Riempie lo slot "agente background long-running", non lo slot "spawna 4 in parallelo e fondi".
  • Sub-agenti di Claude Code e i limiti della flotta di sub-agenti — una primitiva di sub-agente di prima classe, ma scoped alla CLI Claude Code. Documentata, spawnabile in parallelo, e l'analogo più vicino a multi_agent.enabled — con la differenza importante che il prompt del coordinatore lo scrivi tu.
  • Building Agents sulla Messages API — il percorso DIY. Fai fan-out di N chiamate messages.create in parallelo, scrivi il prompt di sintesi, gestisci i retry. Stesso risultato, più codice.

Il gap: nessuna superficie API di Anthropic al momento ti permette di flippare un singolo booleano e avere il modello stesso a decidere quanti sub-agenti spawnare e fondere il loro lavoro. Se vuoi quel comportamento contro Claude, te lo costruisci — vedi Cowork & Agent Teams per la storia lato prodotto e Managed Agents per la primitiva del loop hostato.

Scegliere la primitiva giusta per carico di lavoro​

Guided walkthrough1 of 5
  1. Se i sotto-task possono girare senza aspettare i risultati l'uno dell'altro — auditare un repo, ricercare un tema attraverso molte fonti, refactorare N file indipendentemente — una forma fan-out si guadagna il costo. Se il task è sequenziale (modifica A, poi leggi il risultato di A, poi modifica B), qualsiasi primitiva multi-agente aggiunge overhead di sintesi per zero guadagno.

Quattro failure mode che trasformano Ultra in una bolletta 4x per nulla​

  • Accenderlo su task sequenziali. Il modello decompone e sintetizza anche quando il task non parallelizza. Paghi l'overhead di coordinamento su lavoro che non ne aveva bisogno. Regola pratica: se non riesci ad articolare cosa starebbe facendo il secondo sub-agente mentre gira il primo, non abilitare il multi-agent.
  • Lasciare l'osservabilità del reasoning-summary sulla tua dashboard. reasoning.summary è silenziosamente non supportato con multi-agent. Se il tuo monitoring dipende da questo, otterrai campi vuoti e penserai che il modello non stia pensando. Spedisci un cambio di schema prima di flippare il flag.
  • Usare max_tool_calls come limite di sicurezza. Anche questo silenziosamente disabilitato con multi-agent. La storia di sicurezza che pensavi di avere — "al massimo 20 chiamate tool per richiesta" — è sparita. Enforcia i tetti di chiamate tool al livello dell'adapter tool, non via parametro di richiesta.
  • Assumere che max_concurrent_subagents sia un cap di costo. Capa i sub-agenti attivi in un momento, non il totale spawnato durante la richiesta. Una singola chiamata Ultra può spawnare dozzine di sub-agenti in sequenza e rispettare comunque un limite max_concurrent_subagents: 3. Se il costo è il tuo tetto, aggiungi un max_output_tokens a livello di richiesta.

Cosa "multi-agente nativo" non è​

Due primitive adiacenti vengono spesso confuse con esso:

  • Non è il sampling n > 1. Il vecchio parametro n di OpenAI campiona molteplici completion e le restituisce tutte; tu ne scegli una. Il multi-agente esegue sub-agenti diversi che fanno lavori diversi e ne sintetizza gli output. Il primo è sampling di temperatura; il secondo è decomposizione di task.
  • Non è la batch inference. La batch API processa molte richieste indipendenti in background. Il multi-agent è molti sub-agenti coordinati dentro una richiesta interattiva. Il batch è orientato al throughput, il multi-agent è orientato al risultato.

Dove sta andando​

Il protocollo A2A (vedi A2A: Il Protocollo Agent-to-Agent) copre il multi-agente inter-vendor. multi_agent.enabled: true copre il multi-agente intra-model. Lo slot non riempito è una primitiva cross-vendor — il modello sul vendor A spawna un sub-agente sul vendor B e ne fonde il risultato — e non c'è ancora una spec pubblica per questo. Quando atterrerà, atterrerà come A2A + un verbo di handoff nativo, non come una nuova API su nessuno dei due lati. Tieni d'occhio quello spazio.

Check yourself

0/4
  1. Cosa capa max_concurrent_subagents nella beta multi-agente della Responses?
  2. Abiliti multi-agent e la tua dashboard di monitoring mostra improvvisamente campi reasoning-summary vuoti. Cos'è successo?
  3. Ti servono sub-agenti paralleli che girano in account cliente diversi attraverso due vendor. Quale primitiva è quella corretta?
  4. Quale di questi è un candidato scarso per Ultra Mode / multi_agent.enabled?
Nessuna carta — aggiungine qualcuna per iniziare a studiare. 🃏

Fonti e approfondimenti​