Prodotti in evidenza / Toolbox
Centinaia di strumenti.
Zero appesantimento della finestra di contesto.
Swisper Toolbox carica gli strumenti su richiesta.
L'agente vede solo ciò di cui ha bisogno, quando ne ha bisogno.
I framework di agenti tradizionali caricano all'avvio tutte le definizioni degli strumenti nella finestra di contesto. Con 50+ strumenti, questo consuma migliaia di token prima ancora che l'agente inizi a ragionare. La finestra di contesto si riempie di schemi di strumenti invece che dei dati che contano.
Lazy loading tramite server MCP
Gli strumenti sono registrati in un ToolboxRegistry centrale, ciascuno con un riassunto di una riga. Il planner dell'agente vede un catalogo leggero, non gli schemi completi. Quando il planner decide di aver bisogno di una toolbox specifica, gli schemi vengono idratati dal server MCP in tempo reale. Dopo l'esecuzione, gli schemi vengono rimossi. Gli altri 99 strumenti non occupano un solo token.
Economia dei token, scenario reale:
Organizzazione gerarchica degli strumenti
Non tutte le integrazioni sono un elenco piatto di endpoint API. I domini complessi, l'e-commerce con più retailer, i viaggi con più fornitori, necessitano di una propria logica di pianificazione, di uno stato proprio e di flussi human-in-the-loop. Swisper Toolbox supporta due percorsi di esecuzione da un unico orchestratore:
Entrambi i percorsi producono lo stesso contratto di risultato tipizzato. Questo significa che le nuove integrazioni possono nascere come toolbox leggere e crescere fino a diventare agenti di dominio completi man mano che la complessità lo richiede, senza modificare nulla a valle.
Il pattern dell'agente di dominio
Invece di esporre centinaia di singoli strumenti, Swisper presenta interi agenti di dominio come strumenti. Il Supervisore Globale delega all'Agente Viaggi (che internamente conosce decine di API di prenotazione) anziché scegliere tra singoli strumenti per voli, hotel, taxi e parcheggi. Questo riduce drasticamente lo spazio decisionale per l'agente orchestratore, preservando al contempo l'intera capacità.
Lazy loading all'interno degli agenti di dominio
Lo stesso pattern di lazy loading funziona a ogni livello della gerarchia. Un agente di dominio che gestisce l'e-commerce su più retailer non carica tutte le API dei fornitori, individua quale fornitore usare e carica in modo lazy la toolbox di quel fornitore. Questo significa che un agente e-commerce con 100+ strumenti su 5 fornitori paga lo stesso costo in token di uno con 10 strumenti.
Questo è architetturalmente distinto da ciò che offrono Claude Code o LangGraph. Le loro soluzioni aggiungono il lazy loading come componente accessorio al livello superiore. Il pattern di Swisper è ricorsivo: il planner globale, gli agenti di dominio e i sotto-agenti condividono tutti lo stesso ciclo di idratazione-esecuzione-rimozione. La scalabilità è integrata, non applicata a posteriori.
Integrazioni enterprise:
Collegate il vostro stack
Connettori MCP pre-costruiti per i sistemi enterprise. Ogni connettore è una toolbox, caricata su richiesta, rimossa una volta terminata.