Remarks 318° | Agent Teams.
Riflessione sull'isolamento e sulla compressione.
Moment Of Truth | 03:33 Minuti
Il tuo touchpoint sullo spazio digitale: uno strumento pratico dove troverai idee, riflessioni, conoscenze e framework in grado di guidarti nell’esecuzione della tua innovazione digitale. Testala, è gratis ↓
Buondì, e buon lunedì.
La distinzione tra "ruolo" e "contesto" svanisce definitivamente?
Mentre il mondo è ancora impegnato a capire come unire più agenti simulando un organigramma aziendale umano, Anthropic ha appena ridefinito le regole del gioco con il rilascio silenzioso del suo framework nativo.
Stiamo parlando di una virata drastica che demolisce il modo in cui i team concepiscono l’orchestrazione dei LLM.
Non si tratta di decidere se usare più agenti. La vera domanda architetturale è: che tipo di coordinamento richiede realmente questo task? Claude introduce due paradigmi strutturalmente opposti: sub-agents e agent teams.
Sembrano simili sulla carta, ma risolvono problemi geometricamente diversi. Se sbagli l’approccio, crei un sistema affetto da latenza e degradazione dei dati.
TL;DR | Takeaways
In questa edizione del Remarks, analizziamo l’anatomia tecnica del framework di Claude e come la corretta gestione dei confini informativi stia cambiando per sempre la progettazione di sistemi complessi, riducendo l’inquinamento della context window e i costi di calcolo in tempo reale.
Sub-agents (isolamento e compressione): istanze temporanee “fire-and-forget” che operano in context window isolate, eseguendo micro-task e restituendo al padre solo il segnale finale condensato;
Agent teams (stato condiviso e P2P): istanze persistenti a lungo ciclo di vita che comunicano direttamente tra loro, negoziando i task tramite una lavagna di stato comune e dipendenze attive;
La trappola del gioco del telefono: dividere il lavoro per ruoli (planner, implementatore, tester) distrugge l’informazione a ogni handoff. Il segreto è la scomposizione incentrata sul contesto;
Quando non usarli affatto: se i modelli devono condividere continuamente la stessa memoria, l’overhead supera il valore d’esecuzione. Un singolo agente ben strutturato surclassa i sistemi multi-agente inefficienti.
Stai leggendo una nuova edizione del light format del Remarks.
Oggi parliamo di come:
Il problema centrale risolto dai sub-agents è la saturazione della memoria di lavoro. Immagina il lead di un gruppo di ricerca: non legge ogni singola fonte primaria, delega domande mirate e sintetizza i risultati. Un sub-agent fa esattamente questo. Riceve un prompt di sistema, un set di tool isolati e una context window pulita. Quando finisce, non riporta la catena di ragionamento (Chain of Thought) o i log grezzi. Riporta solo il payload compresso. Il padre non viene inquinato dal rumore di fondo.
La logica impone un vincolo rigido che diventa una feature di prevedibilità: i sub-agents non possono parlarsi tra loro e non possono generare altri sub-agents. Tutto fluisce verticalmente verso il padre, che rimane l'unico coordinatore centrale del flusso.
La morte della "lista dei ruoli".
GO↓
🔵 Agent Teams.
Tre pratici approcci
Qui entriamo nel cuore tecnico della progettazione. Gli sviluppatori non devono più mappare processi lineari rigidi, ma definire i confini delle informazioni. Il framework permette di muoversi tra l'isolamento puro e la collaborazione a lungo termine.
# Sincronizzazione dell'ambiente di lavoro con i moduli di integrazione edge
npm install -g @anthropic-ai/claude-code
claude1/ → Sub-agents per l'audit parallelo e isolato
Puoi usare l’SDK di Claude per istanziare sub-agenti specializzati che analizzano componenti diverse in parallelo, lasciando il coordinatore libero di elaborare la sintesi senza accumulare token inutili.
Il campo description all’interno della definizione è il segnale di routing che dice al padre quale istanza attivare in base al prompt iniziale. Se la richiesta evidenzia problemi di sicurezza, il padre interroga l’agente dedicato eliminando il rumore degli altri moduli.
from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition
async def main():
async for message in query(
prompt="Review the authentication module for security vulnerabilities",
options=ClaudeAgentOptions(
allowed_tools=["Read", "Grep", "Glob", "Agent"],
agents={
"security-reviewer": AgentDefinition(
description="Security specialist. Use for vulnerability checks and security audits.",
prompt="You are a security specialist with expertise in identifying vulnerabilities.",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
"performance-optimizer": AgentDefinition(
description="Performance specialist. Use for latency issues and optimization reviews.",
prompt="You are a performance engineer with expertise in identifying bottlenecks.",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
},
),
):
print(message)2/ →Agent Teams per la gestione delle dipendenze asincrone
Quando i task non sono isolabili ma richiedono una negoziazione continua sul codice o sullo stato del sistema, devi passare al modello collaborativo persistente.
Invece di forzare i passaggi attraverso l’agente principale, configuri un team in cui i componenti comunicano peer-to-peer. Sfruttando il parametro blockedBy nella pianificazione delle fasi, un tester non si avvia finché lo sviluppatore backend non ha rilasciato l’endpoint, coordinandosi direttamente sulla lavagna di stato comune.
Claude (Team Lead):└── spawnTeam("auth-feature")
Phase 1 - Planning:
└── spawn("architect", prompt="Design OAuth flow", plan_mode_required=true)
Phase 2 - Implementation (parallel):
└── spawn("backend-dev", prompt="Implement OAuth controller")
└── spawn("frontend-dev", prompt="Build login UI components")
└── spawn("test-writer", prompt="Write integration tests", blockedBy=["backend-dev"])Separare queste funzioni crea solo un handoff distruttivo che costa più del valore generato dal parallelismo.↓
Referral Program
Se pensi che questo Remarks possa interessare a qualcuno, puoi condividerlo.
3/ →Scomposizione centrica del contesto prima del codice
Insegna al tuo team a non separare mai l’implementatore dal tester se vuoi evitare il fallimento del sistema dovuto ad assunzioni incompatibili.
Quando progetti l’architettura, chiediti sempre quale contesto serve realmente a quel sotto-task. Se due attività richiedono informazioni sovrapposte, devono rimanere nello stesso agente. Chi scrive il codice deve scrivere anche i test per quella specifica feature: possiede già la conoscenza implicita all’interno della sua context window.
Il consiglio fondamentale resta immutato: parti da un singolo agente. Spingilo al limite finché non trovi il punto di rottura in cui le prestazioni degradano. Sarà quel fallimento misurato a indicarti esattamente dove tracciare il confine e quale pattern di orchestrazione applicare.
La complessità si paga in token.
Questo è Remarks. Il Touchpoint digitale di Catobi.
Se ti fa piacere continuare a parlare di questi temi, basta scrivermi →
In questo canale offriamo spazio, attraverso varianti pubblicitarie, al racconto dell’innovazione dei nostri Partner, e veicolando il contenuto su tutte le nostre piattaforme, comprese LinkedIn, Instagram e Telegram.
Qui tutte le informazioni su come sponsorizzare gli episodi della newsletter→