Remarks 321° | Async agent.
Due modelli multi-agente asincroni.
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 "orchestrazione software" e "configurazione LLM" svanisce?
Mentre il mondo è ancora impantanato a fare “prompt engineering” su singole chat monolitiche e sequenziali, Anthropic ha silenziosamente pubblicato i blueprint operativi per superare il collo di bottiglia strutturale dell’era generativa: il framework di orchestrazione asincrona multi-agente.
Non stiamo parlando dei soliti script lineari dove l’Agente A aspetta l’Agente B, accumulando latenza e frammentando lo stato. Questa è la transizione verso sistemi event-driven nativi in asyncio, in cui micro-agenti specializzati nascono, si scambiano messaggi tramite hub centralizzati, parallelizzano i task e muoiono non appena l’obiettivo è raggiunto. Se gestisci la crescita tecnica, devi smettere di pensare al prompt come testo e iniziare a trattarlo come un microservizio asincrono.
TL;DR | Takeaways
In questa edizione del Remarks, svisceriamo l’architettura dei pattern multi-agente asincroni rilasciati da Anthropic e come implementarli in produzione da domani mattina. Scoprirai:
Il superamento della latenza sequenziale: come far cooperare agenti paralleli riducendo i tempi di esecuzione dell’80% tramite loop asincroni;
L’architettura shared message hub: il funzionamento del pattern a team fisso con messaggistica paritaria e “sveglie” controllate dagli eventi.
Lo spawning dinamico e i micro-agenti: come istanziare sub-agenti specializzati a ciclo di vita ridotto per task massivi e distruggerli subito dopo per azzerare i costi di infrastruttura.
Stai leggendo una nuova edizione del light format del Remarks.
Oggi parliamo di come:
Il problema fondamentale delle vecchie pipeline agentiche è il blocco della catena di calcolo. In un sistema sequenziale classico, se devi analizzare una campagna complessa, l'agente che controlla i dati di traffico deve terminare prima che l'agente di copy optimization possa iniziare. Se il primo impiega 15 secondi, il secondo ne accumula altri 15. Latenza totale: 30 secondi. Inaccettabile su larga scala.
La vera rivoluzione sta nell'implementazione di un loop asincrono centralizzato in cui gli agenti coesistono come coroutine. Un agente non attende bloccando il sistema; cede il controllo al loop finché un evento specifico non lo risveglia. Questo cambia radicalmente il funzionamento dell'infrastruttura di marketing e operations, portando a un'esecuzione parallela iper-veloce.
Addio pipeline lineare.
GO↓
🔵 Async agent.
Tre pratici approcci
Qui entriamo nel cuore tecnico dell'implementazione. Non andiamo a cambiare le parole del prompt, andiamo a riscrivere il modo in cui i modelli invocano i tool e scambiano i dati di contesto tramite JSON strutturati.
1/ → Shared Message Hub
Questo approccio serve quando hai un team fisso di agenti specialistici che devono collaborare sullo stesso progetto in tempo reale (es. un analista dati, un copywriter e un compliance auditor). Invece di passarsi i dati in ordine, tutti gli agenti girano contemporaneamente e leggono/scrivono su un Hub comune.
Configura l’infrastruttura definendo un dizionario per le inbox e un sistema di eventi asincroni. Ogni agente, nel suo ciclo di esecuzione, chiama uno strumento bloccante che si risveglia solo quando l’Hub riceve un messaggio a lui indirizzato.
Usa questo schema logico per far scrivere al tuo team il codice di orchestrazione:
import asyncio
class SharedMessageHub:
def __init__(self):
self.inboxes = {}
self.events = {}
async def send_message(self, recipient, sender, content):
payload = {"sender": sender, "content": content}
self.inboxes.setdefault(recipient, []).append(payload)
if recipient in self.events:
self.events[recipient].set()
async def wait_for_message(self, agent_name):
if agent_name not in self.events:
self.events[agent_name] = asyncio.Event()
if not self.inboxes.get(agent_name):
await self.events[agent_name].wait()
self.events[agent_name].clear()
return self.inboxes.setdefault(agent_name, []).pop(0)Passa questo script al tuo team di sviluppo. Da domani, quando dovrai validare un lancio di prodotto, l'Analista dati immetterà i KPI nell'Hub; l'Auditor si sveglierà istantaneamente per verificare la compliance legale del testo appena l'agente di Copywriting invierà il suo pezzo all'Hub, riducendo le ore di riunione a pochi millisecondi di calcolo parallelo.
2/ →Dynamic Subagent Spawning
Usa questo approccio quando l’Engine riceve un input massivo imprevedibile (es. analizzare un feed catalogo di 1.000 prodotti per estrarre angoli di vendita o correggere bug semantici). Il Lead agent non fa il lavoro: agisce da orchestratore puro.
Il Lead agent mappa l’input e chiama un tool di sistema per creare sotto-agenti paralleli temporanei, assegnando a ciascuno un singolo record JSON.
Istruisci il Lead agent con questo system prompt strutturato per l’output in JSON:
{
"system_instruction": "Agisci come Lead Orchestrator. Non elaborare i singoli elementi del catalogo. Il tuo unico compito è mappare l'array di input, suddividere il carico di lavoro in batch e invocare lo strumento 'spawn_subagents' passando un array di configurazioni specifiche per ciascun worker.",
"required_tool_call": {
"name": "spawn_subagents",
"arguments": {
"workers_count": "int",
"tasks": [
{
"subagent_id": "string",
"context_payload": "object"
}
]
}
}
}In questo modo, se carichi un file con 50 competitor da analizzare, il sistema genera istantaneamente 50 micro-istanze isolate che eseguono il controllo in parallelo. Il Lead raccoglie i risultati aggregati e termina i sub-agenti, azzerando i costi di calcolo fissi.
Implementando questo loop nel backend del tuo team, elimini completamente i controlli umani sui flussi ripetitivi. L'AI corregge se stessa all'interno di un ambiente asincrono protetto finché il JSON non rispetta al 100% i criteri aziendali stabiliti, inviando in produzione solo dati perfetti.↓
Referral Program
Se pensi che questo Remarks possa interessare a qualcuno, puoi condividerlo.
3/ →Orchestrazione a due vie
Il terzo approccio risolve il problema dei sistemi autonomi che “vanno fuori strada”. Introduciamo un pattern di validazione incrociata in cui un agente genera una proposta tecnica e un secondo agente (il Validator) ha il potere di bocciare l’output e rispedirlo al mittente iniettando nel contesto le correzioni precise in formato strutturato.
L’agente esecutore riceve il task e genera la prima bozza di configurazione o codice. Il Validator intercetta l’output e lo testa a livello semantico e logico. Se non passa, solleva un’eccezione interna che forza l’esecutore a correggersi.
Configura la chiamata di sistema applicando questa regola di validazione dei passaggi:
{
"workflow_state": "validation_loop",
"max_retries": 3,
"validation_schema": {
"status": "APPROVED | REJECTED",
"error_logs": "string (vuoto se APPROVED)",
"rejection_reason": "string (specificare il fallimento logico)",
"next_action_payload": "object"
}
}Il passaggio dal prompt testuale all'architettura software asincrona è l'unico vero elemento di differenziazione competitiva rimasto.
Flotte di micro-agenti autonomi.
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→