Dieci agenti AI specializzati. Più i tuoi. Un solo sistema operativo.
Agent OS è il sistema con cui un CEO gestisce un team di agenti AI come gestirebbe un team di persone. Ogni agente ha un ruolo, una memoria, una storia. Tu li chiami, lavorano, lasciano traccia. Niente prompt da copiare ogni volta. Niente contesto perso. Niente "riparti da zero". Crei i tuoi agenti custom dal portal, gestisci più workspace con un solo account, la memoria delle iniziative si aggiorna da sola — e ora gli agenti entrano in riunione: su Google Meet, con volto e voce, o come notetaker silenzioso.
Per CEO che hanno smesso di prompt-engineerare ogni mattina.
Se oggi usi l'AI come una calcolatrice — apri una chat, chiedi una cosa, copi la risposta, chiudi — Agent OS è quello che separa quel modo di lavorare da una vera operatività AI-native.
CEO di PMI
Vuoi un team di consulenti AI sempre disponibili — strategy, marketing, operations, prodotto — senza pagare 8 fee mensili a 8 persone diverse.
Founder seriali
Hai 5 progetti aperti contemporaneamente. Ti serve memoria condivisa per ognuno. Niente "ah giusto, dove eravamo rimasti?".
Operatori dell'innovazione
Gestisci accelerazione, venture building, turnaround. Hai bisogno di processi ripetibili, non di magia LLM una tantum.
Tre cose che una chat normale non fa.
Specializzazione vera, non camuffata.
Ogni agente ha un system prompt costruito per un mestiere preciso — non una "persona generica con un cappello diverso". Vince ragiona da CMO con 15 anni di campagne addosso. Iron parla la lingua dei P&L. Set pensa come un CdA. Quando chiami Vince, ottieni Vince. Non una versione travestita di Claude.
Le sessioni si sommano. Il contesto cresce.
Ogni chat con un agente lascia traccia: decisioni prese, learnings, KPI toccati, prossimi passi. Quando lo richiami fra una settimana, lui sa già dove eravate rimasti. Niente "fammi riassumere il contesto" da te al ritmo di tre paragrafi a sessione.
Iniziative, non conversazioni.
Il lavoro vive dentro iniziative — il prodotto, il cliente, la campagna, il pilot. Ogni iniziativa ha la sua SOTA (State of the Art): cosa è, dove sta oggi, ultime mosse, prossima azione, decisioni prese. Gli agenti la leggono prima di rispondere. Tu la leggi prima di una riunione.
Quattro passi. Sempre gli stessi.
Quando lavori con un agente, segui un ciclo che il sistema gestisce per te. Sei tu a guidare la conversazione — il resto è automatico.
Dici /invoke vince oppure scrivi semplicemente "voglio lavorare con Vince sulla campagna X".
Il sistema apre una sessione, carica il suo prompt, gli passa la SOTA dell'iniziativa, gli ricorda gli handoff pending.
Conversazione normale — solo che l'agente arriva già briefato e in carattere. Risponde da CMO, non da chatbot. Sa cosa hai fatto la volta scorsa.
Dici /wb. Il sistema estrae da solo: decisioni prese, output prodotti, performance dell'agente, segnali di evoluzione.
Tutto scritto sul tuo Notion. Niente da appuntare a mano.
I writeback diventano materiale di training: ogni N sessioni l'agente assorbe pattern che funzionano e ne scarta altri. Più lo usi, più ti somiglia.
Dieci ruoli, dieci teste. Una sola squadra.
Ognuno ha un dominio chiaro, un nome, un'identità. Quando hai un dubbio su chi chiamare, Agent OS ti suggerisce — ma una volta che ci prendi la mano, sai a colpo sicuro chi ti serve.
| Agente | ID | Ruolo | Quando lo chiami |
|---|---|---|---|
| Dean | AGT-1 | Growth Strategist | Workshop, keynote, materiali formativi |
| Lora | AGT-2 | CPO Challenger | Decisioni di prodotto, UX, storytelling |
| Vince | AGT-3 | CMO | Campagne, funnel, copy, brand |
| Spacey | AGT-4 | Program Director | Acceleratore, valutazione startup, open innovation |
| Iron | AGT-5 | COO | Operations, KPI, P&L, turnaround |
| Set | AGT-6 | Board Strategist | Strategia di gruppo, piano industriale, investor relations |
| Focus | AGT-7 | Chief of Time | Pianificazione settimanale, prioritizzazione |
| Doc | AGT-8 | Chief AI Architect | Architettura AI, automazione, decisioni tecniche |
| Bookey | AGT-9 | Scheduling Agent | Agenda, scheduling con prospect/clienti, filtro inbound |
| Han | AGT-10 | Co-Founder Agentico | Djungle SOLO + consulting, P&L cost-out, cap table, deal terms |
/invoke vince
/invoke set
/invoke iron
/invoke doc
/invoke focus
/invoke dean
/invoke lora
/invoke spacey
Il salto: dal "ricordare bene" al "sapere dove sei".
Fino a v3.1 gli agenti avevano memoria — leggevano sessioni passate, decisioni, learnings. Con v3.2 hanno qualcosa di più importante: stato vivo di ogni iniziativa che gestisci.
L'unità di lavoro persistente.
Ogni cosa che vale la pena tracciare diventa un'iniziativa — il prodotto Agent OS Platform, il workshop di Dicembre, il pilot Rentable, il lancio della campagna Q1. Le iniziative hanno tipo (business, experiment, project, asset), stage, health, e si linkano fra loro (X depends_on Y, X output_of Y).
Quando chiami un agente, gli dici su quale iniziativa lavorate. Tutto quello che fa resta lì, non si mescola con altro.
State of the Art — le sei sezioni che contano.
Per ogni iniziativa, sei caselle vive che gli agenti aggiornano e tu leggi:
- what_it_is — la frase che spiega cos'è in un colpo solo
- current_state — dove siamo oggi, in modo onesto
- last_3_moves — le ultime tre cose successe, con data
- open_loops — cose lasciate aperte che richiedono follow-up
- next_action — la prossima mossa concreta
- decisions_log — le decisioni prese e perché
Non è un documento da scrivere a mano. È un layer che si compila lavorando — gli agenti lo aggiornano, tu lo leggi prima di una riunione o di un commercio.
Diagnostica strutturale, sempre attiva.
Quando un agente entra su un'iniziativa, il Probe gli passa anche le carenze rilevate: sezioni SOTA vuote, KPI mancanti, open loop aperti da troppo tempo, iniziative ferme. L'agente le segnala prima di rispondere al task — così tu vedi cosa è da sistemare, ma sei sempre tu a decidere se intervenire ora o dopo.
Niente auto-fix. Niente "ho aggiornato la SOTA per te" — è materiale tuo.
Da agente ad agente, tracciato.
Quando Set finisce una nota strategica e serve a Vince per declinarla in campagna, parte un handoff. Vince lo trova all'avvio della prossima sessione, lo legge, lo consuma o lo posticipa. Niente passaggi a voce, niente conversazioni perse.
Tu vedi tutto in un'unica cartella di mirror locale (~/Documents/Claude/djungle-context/) —
è il tuo audit trail leggibile.
L'AI scrive lo stato da sola. Tu confermi al writeback.
Lo stato delle iniziative (la SOTA) non lo aggiorni più a mano.
Quando chiudi una sessione con /wb, una passata di
Session Digestion lato server legge l'intera conversazione,
estrae i fatti che hai raccontato e te li propone come delta SOTA, raggruppati per iniziativa.
Tu confermi in un colpo solo.
Deterministica, non più "sperata".
Fino alla v4.4 la cattura dipendeva dall'agente che annotava i fatti durante la chat — inaffidabile per natura. Dalla v4.5 la cattura è una funzione del server: al writeback, un modello dedicato (Haiku) digerisce il transcript completo e classifica i fatti in 8 tipi — stage_change, move_done, decision, open_loop_new/closed, reference, metric, next_action_change.
Vedere l'intera sessione paga: un loop aperto e poi chiuso nella stessa chat si annulla da solo. Confidence high/medium → proposto. Low → scartato. Mai falsi positivi auto-applicati: la SOTA è semantica, confermata da te.
Digest, review, conferma, commit.
Al writeback la pipeline ti mostra:
- Summary della sessione (close + memory log cross-post con initiative_id)
- Fatti estratti dal transcript, raggruppati per iniziativa con preview testuale
- Diff proposti su last_3_moves, decisions_log, open_loops, next_action, stage
- Scelta: Y (tutti) · n (scarta) · review-singolo (uno per uno)
- Commit atomico, audit log, probe cache invalidata
Cattura continua, anche se non chiudi mai la sessione.
Dalla v4.6 il writeback non è più solo un comando: è un evento del ciclo
di vita della sessione. Un hook cattura i fatti a ogni turno di conversazione,
e la commit policy del tenant decide la sorte di ciascuno: i fatti espliciti
sull'iniziativa della sessione si applicano da soli, tutto il resto — inferenze,
fatti ambigui, fuori scope — finisce in una review queue che
smaltisci con un click (/review-queue in Cowork).
Chiudi il laptop a metà lavoro: il contesto è già salvo.
E ogni scrittura è verificabile: la risposta del sistema dichiara su quali iniziative ha scritto davvero — mai un conteggio senza destinazione. Il tenant è vincolato alla sessione alla nascita: due chat in parallelo su workspace diversi non si pestano i piedi.
Le iniziative, sempre fresche, nel portal.
Su agents.djungle.io/dashboard/sota vedi tutte le iniziative
del workspace attivo, raggruppate per dominio, con la SOTA espandibile al click.
Multi-tenant nativo: cambi tenant e il dashboard cambia dati. Da Cowork lo apri con
/sota-board.
I 10 Djungle + i tuoi. Editor visuale, niente CLI.
Fino a v4.0, creare un agente custom richiedeva tool MCP da terminale — impossibile per un CEO non-tech. Da v4.1, hai un editor nel portal: form, textarea prompt, capabilities, publish toggle. In 5 minuti hai il TUO CFO virtuale, il TUO consulente di settore, il TUO assistente operativo.
Form classico, niente tool da imparare.
Vai su /dashboard/agents/new. Compili nome, ruolo, system prompt
(100-8000 caratteri), tagline, descrizione estesa. Scegli la visibilità (privato di default,
pubblico opzionale per il marketplace). Salvi. L'agente è subito invocabile dal tuo Cowork
scrivendo invoca <name> oppure il comando skill
/invoke <slug>.
Lo slug è l'identificatore URL (kebab-case, immutabile dopo creazione). Il sistema genera un
AGT-N progressivo se non lo specifichi.
Ogni modifica al prompt è una nuova versione.
Append-only. La tabella agent_versions conserva il prompt completo di
ogni save con timestamp, autore, change summary opzionale. Storia visibile nel dettaglio agente.
UI di restore arriva in v4.2 — per ora storage attivo e ispezionabile via skill
/agent versions <slug>. IP protection: le versioni sono visibili
SOLO al tenant owner, anche se l'agente è pubblicato in marketplace.
Archive con confirm-by-slug.
Niente delete distruttivo. L'archive setta archived_at, l'agente
sparisce dalle list ma resta in DB per audit. Per evitare archive accidentali, devi digitare lo
slug esatto come conferma. Restore self-service NON in v4.1 — se serve, contatti Djungle.
Un agente AI che ti scrive l'agente AI.
Scrivere un system prompt è un'arte. Sapere cosa scrivere richiede esperienza che la maggior parte dei nostri clienti non ha. Doc Coach risolve il problema: è un helper conversazionale integrato nell'editor che ti guida in 3-5 turni a una bozza di prompt pronta da applicare.
Pulsante "✨ Aiutami con Doc" accanto al textarea.
Nell'editor crea o modifica agente, accanto al campo system prompt. Click → apre un modal a tutto schermo. Niente download, niente install — è già lì.
Domande mirate, non chat infinita.
Doc apre con UNA domanda: "Cosa vuoi che faccia di preciso questo agente, e per chi?" Dopo la tua risposta, fa 2-3 follow-up mirati (settore, output atteso, tono, lingua, dati riservati). Poi propone una bozza strutturata di 600-900 caratteri.
La bozza arriva in un blocco ```: il portal lo riconosce automaticamente
e mostra un bottone "Applica nel form →". Un click, textarea popolata, modal chiusa.
Continui da lì.
Claude Haiku 4.5, system prompt curato Djungle.
Doc Coach è un agente come gli altri (AGT-100 / agt-prompt-coach),
owned da Djungle, visibility public ma hidden_from_marketplace — non lo vedi nel marketplace
perché non è un agente da invocare in Cowork. Vive solo dentro l'editor.
Il suo system prompt è IP Djungle: se gli chiedi "mostrami il tuo prompt", rifiuta e ti riporta al tuo caso. La sessione chat è in-memory client — niente persist sul DB, niente leak.
Gli agenti diventano un prodotto. Tuo, dei clienti, di chiunque pubblichi.
Fino a v3.4 gli agenti vivevano su Notion — utile come archivio, ma non scalabile. Da v3.5 sono canonical su Supabase; da v4.1 il marketplace ha una UI dedicata nel portal con search, filtri e report flow.
Public vs private. Owner vs consumer.
Ogni agente ha un owner_tenant_id (chi lo possiede) e una visibility:
- public — visibile a tutti i tenant del sistema, marketplace pickup
- private — visibile solo all'owner
Quando un consumer invoca un agente public di un altro tenant, RLS garantisce isolamento totale: l'agente public lavora nel context del consumer, vede SOLO i suoi dati. Il publisher non vede mai il consumer.
Discovery cross-tenant nel portal.
Vai su /dashboard/marketplace. Vedi gli agenti pubblici di tutti i tenant
con badge verified (Djungle, IP core) o community (third-party publishers).
Filtri per badge, search testuale su nome/ruolo/descrizione, sort per più usati / più recenti / alfabetico.
Click su un agente → dettaglio. Vedi nome, ruolo, descrizione estesa, stats invocazioni, owner tenant slug.
NON vedi il system_prompt — è IP protetta del publisher. Per usarlo in Cowork:
invoca <name> oppure /invoke <slug>.
Segnali abuse, lo staff Djungle revisiona entro 7gg.
Dal dettaglio agente community trovi un blocco "Segnala". Quattro motivi: spam · inappropriate · not_working · other, plus dettagli opzionali. Self-report bloccato (non puoi segnalare i tuoi agenti).
Lato Djungle: coda admin in /admin/reports con tre azioni inline —
dismiss, mark_reviewed, unpublish (quest'ultima forza l'agente a
visibility=private immediatamente).
Alternativa CLI: skill da Cowork.
Se preferisci comandi a UI, le skill restano disponibili:
/agent create <slug> "<name>" "<role>" "<prompt>"/agent update <slug> system_prompt="…"/agent publish <slug>— diventa visibile cross-tenant/agent versions <slug>— lista storia versioni/agent archive <slug>— soft-delete con audit
Editor portal e skill sono backed dalla stessa API + RLS server-side: write cross-tenant bloccate in entrambi i casi.
Notion deprecato come staging editor. Ora è solo archivio storico.
Fino a v4.0 Notion era specchiato 1×/giorno per visual review. Da v4.1 il cron Notion mirror è disabilitato di default — l'editor UI nel portal sostituisce il bisogno di Notion come staging. Notion resta visitabile come archivio storico read-only, ma non viene più aggiornato.
Per riattivare il mirror (se necessario): set env var NOTION_MIRROR_ENABLED=true
su Vercel.
Più aziende, un solo account.
Un imprenditore non ha una sola azienda. Agent OS lo sa: con un solo login gestisci N workspace isolati — ognuno con i suoi agenti, le sue iniziative, la sua memoria, la sua brand identity. Djungle, una holding, un cliente in consulenza: ciascuno è un tenant separato, i dati non si mescolano mai.
Cambia workspace in un click.
Dal portal, lo switcher in alto cambia il tenant attivo: dashboard, agenti e iniziative si aggiornano all'istante. Ogni tenant ha la sua brand emoji (🔵 Djungle, 🟡 Space for Imagination, 🛵 Tour in Vespa) che apre le risposte degli agenti — così sai sempre in quale workspace stai lavorando.
Switch fluido anche in chat.
In Cowork, /tenant list mostra tutti i tuoi workspace,
/tenant switch <slug> cambia quello attivo. Con la
Personal API Key (una sola, valida su tutti i tenant) non devi più
riconfigurare il connettore ad ogni cambio. Portal e Cowork restano sincronizzati.
Il portfolio a colpo d'occhio.
agents.djungle.io/dashboard/tenants non è più solo un'anagrafica: per ogni workspace vedi scala (iniziative, domini, persone, agenti), vitalità (attività recente, trend sessioni) e salute (health, alert, drift). Un bordo colorato segnala subito i tenant che richiedono attenzione.
Un bibliotecario che tiene in ordine la tua memoria.
Le SOTA crescono, lo Scribe cattura fatti, ma col tempo si accumulano drift, contraddizioni e duplicazioni che nessuno controlla. Il Librarian è un agente di background che ogni settimana fa una passata di consolidamento sulla knowledge base del tenant e ti consegna un briefing con gli alert prioritari.
Cinque fasi, in autonomia.
Orient → Prune → Merge → Reorganize → Surface. Il Librarian legge iniziative, SOTA, sessioni e handoff, e segnala: iniziative dormienti, memory log vecchi da archiviare, duplicati semantici, contraddizioni interne (es. due numeri diversi per lo stesso deal), reference rotte, pattern e opportunità cross-iniziativa.
Solo segnalazione, mai correzione automatica: le risoluzioni le decidi tu. Gli alert hanno tre stati — gestito, ignora, rimanda.
Settimanale, o on-demand.
Gira ogni lunedì in automatico, oppure lo lanci quando vuoi con
/librarian-now. Il risultato lo leggi con
/briefing in Cowork o nel dashboard
/dashboard/librarian. Lo abiliti dalle impostazioni
del tenant.
I tuoi agenti entrano in riunione.
Il confine della chat è caduto. Un agente Agent OS può partecipare a una riunione su Google Meet: entra come partecipante con volto e voce, ascolta in tempo reale, e quando lo chiami per nome risponde — con il contesto vivo delle tue iniziative, non con risposte generiche. E a fine call, il lavoro non evapora: diventa memoria e piano operativo.
Ascolta tutto, non decide niente da solo.
Il bot entra in call, trascrive in italiano con boosting sui nomi delle tue iniziative e dei tuoi agenti, e a fine riunione una passata di digest estrae i fatti dal transcript — gli stessi 8 tipi dello Scribe. Con una regola prudenziale in più: i fatti da riunione non vanno mai dritti in SOTA. Passano tutti dalla review queue, perché una call è piena di ipotesi discusse e scartate — e "discusso" non è "deciso".
Lo chiami per nome, ti risponde in call.
Ogni agente ha la sua wake word, il suo avatar video e la sua voce. Dici "Set, dammi il contesto dell'iniziativa X" e risponde a voce in pochi secondi, come un collega al tavolo: prima la conclusione, poi il perché, poi cosa resta aperto. Il contesto è quello del tuo workspace — SOTA, decisioni, metriche. Puoi interromperlo ripetendo il suo nome, fare follow-up senza richiamarlo, e congedarlo con un "grazie".
"A fine call preparami il piano."
Lo chiedi in riunione, a voce. A call conclusa il sistema estrae le azioni decise — solo quelle, non le ipotesi — ognuna ancorata a una citazione letterale del transcript: un'azione senza prova viene scartata, mai inventata. Il piano nasce in bozza, ti arriva via email, e nessuna azione parte finché non confermi dal portal.
Anteprima, in rollout.
In-Call è in rollout progressivo: oggi gira sulle call interne Djungle, l'apertura ai tenant avviene su richiesta. Se vuoi provarlo sul tuo workspace, scrivici — l'infrastruttura (trascrizione, voce, avatar) è già multi-tenant per costruzione.
Costruito su strumenti che già usi.
Niente nuova app da imparare. Niente dashboard proprietaria. Agent OS si infila dentro la tua interfaccia Claude e diventa parte del tuo modo di lavorare.
| Componente | Tecnologia | Cosa fa |
|---|---|---|
| Frontend | Claude Desktop · Cowork | L'interfaccia con cui parli agli agenti — quella che già conosci. |
| Plugin | djungle-agent-os.plugin v4.0.1 | 12 skill: /invoke, /wb, /sota, /handoff, /initiative, /probe, /scribe-status, /agent, /marketplace, /sota-update, /sync_mirror. |
| Portal | agents.djungle.io · v4.1 | Self-service signup, dashboard, editor custom agents, marketplace UI, Doc Coach AI-assist. Next.js 14 su Vercel. |
| MCP server | agents-api.djungle.io · 52 tool MCP | Il ponte fra Claude e i tuoi dati. Dual auth (OAuth magic-link + API key), multi-tenant, RLS. |
| Knowledge layer | Supabase · Postgres canonical | Agenti, moduli, capabilities, knowledge, iniziative, SOTA, sessioni, handoff, memory log, scribe buffer — tutto strutturato e queryable. |
| Notion mirror | Notion · read-only sync 1×/giorno | Archivio leggibile per visual review. Cron one-way Supabase→Notion. Editing canonico via /agent update. |
| Modello AI | Claude Sonnet · Opus | L'engine che fa parlare gli agenti. Anthropic, top di gamma. |
Restano tuoi. Stop.
Multi-tenant rigoroso
Ogni cliente ha il suo schema isolato. I tuoi handoff, le tue SOTA, le tue decisioni non finiscono mai dentro la knowledge di un altro cliente. Nemmeno per sbaglio.
L'IP degli agenti resta a Djungle
I system prompt, i prompt module, le capabilities — il "cervello" degli agenti — sono nostri. Tu vedi le risposte, non le viscere. È quello che giustifica la fee.
Mirror locale
Tutti gli handoff, le decisioni, i report librarian arrivano anche su disco —
in ~/Documents/Claude/[tenant]-context/.
Audit trail leggibile, file system-grade. Esportabile sempre.
OAuth + API key, a tua scelta
Plugin Cowork usa OAuth magic-link (zero .env da gestire) come default.
Per script, CI o integrazioni terze hai anche API key statiche revocabili da
/dashboard/api-keys. Entrambe scoperate al tuo tenant via RLS.
I primi 30 minuti.
Non c'è onboarding di tre giorni. Apri Claude, installi il plugin, lavori.
-
Crea il tuo tenant
Vai su agents.djungle.io, click "Inizia gratis". Inserisci email + nome workspace. Arriva un codice a 6–8 cifre via email: lo inserisci, sei dentro. Niente API key da copiare, niente link da cliccare in un browser a caso.
-
Aggiungi il marketplace e installa il plugin
In Claude/Cowork: Customize → Plugin → Aggiungi marketplace → incolla
fox-0101/djungle-plugins. Trovadjungle-agent-ose installa. -
Connetti il connettore
Click "Connect" sul connettore. Ricevi un magic link via email, lo clicchi, sei autenticato. Nessuna chiave da incollare — l'accesso è via login.
-
Invoca il primo agente
Per partire, prova Focus o Vince — sono i più produttivi nei primi giorni.
/invoke focus -
(Opzionale) Crea il tuo agente custom
Vai su
/dashboard/agents/new. Clicca "✨ Aiutami con Doc" e in 5 minuti hai il tuo CFO virtuale, consulente di settore, assistente operativo. -
Chiudi sempre con writeback
A fine sessione,
/wb. È l'abitudine che separa chi usa Agent OS da chi lo possiede — e da v4.5 aggiorna le SOTA da solo.
# Ciclo tipico — un lunedì mattina /invoke focus → pianifichi la settimana, lui ti sfida sulle priorità /wb → la sessione è salvata, le tue priorità diventano next_action sulle iniziative /invoke vince "sulla campagna Q2" → Vince entra già briefato, vede l'handoff che Set ha lasciato venerdì → producete il copy, lui chiude con un handoff per Doc per la landing /wb
Quello che chiedono prima di partire.
Devo essere uno sviluppatore per usarlo?
No. Se sai usare Notion e Claude, sai usare Agent OS.
Le skill (/invoke, /wb, /sota) si chiamano scrivendo —
niente terminale, niente codice. Lo stack tecnico esiste ma è invisibile.
I miei dati finiscono in un modello pubblico?
No. Le conversazioni passano da Claude (Anthropic), che ha policy enterprise. Iniziative, SOTA, handoff, sessioni stanno sul tuo schema isolato in Postgres. Il mirror locale è sul tuo disco. L'IP degli agenti è di Djungle, ma non si confonde con i tuoi dati.
Gli agenti entrano davvero in riunione?
Sì. Su Google Meet un agente entra come partecipante, con avatar video e voce propria: lo chiami per nome, risponde col contesto del tuo workspace, e a fine call il transcript diventa memoria (in review queue) ed eventualmente un piano operativo da confermare. La funzione è in anteprima: oggi gira sulle call interne Djungle, l'apertura ai tenant è su richiesta. Dettagli nella sezione In-Call.
Posso aggiungere agenti miei?
Sì — è esattamente il modello. Ogni cliente parte con un set base e poi forgia agenti propri sul suo dominio (un commerciale, un controller, un legal). Doc è l'agente che ti accompagna a costruirne di nuovi.
Dove metto la mia API key nel plugin?
Da v4.4 non serve. Il connettore Cowork si autentica via login con email (magic link OAuth): installi il plugin, clicchi "Connect", confermi dalla mail. Nessuna chiave da incollare. Le API key servono solo per integrazioni programmatiche — script, CI/CD, chiamate API server-to-server — e le generi quando ti servono in /dashboard/api-keys.
Posso gestire più aziende con lo stesso account?
Sì. Con un solo login crei e gestisci più tenant (workspace) isolati — uno per ogni azienda
o cliente. Cambi workspace dallo switcher nel portal o con /tenant switch
in chat. I dati di un tenant non sono mai visibili da un altro.
Cosa succede se Claude non risponde bene?
La sessione resta tracciata, lo writeback registra il problema come "performance signal", e nella fase EVOLVE il system prompt viene rivisto. L'agente non ti restituisce solo output — ti restituisce anche dati su sé stesso.
Quanto costa?
Modello: setup fee per l'onboarding del tenant + abbonamento mensile per agente attivo + consulenza opzionale. La trattativa è case-by-case. hello@djungle.io per il dettaglio.
Funziona in inglese?
Sì. Gli agenti rispondono nella lingua in cui scrivi. Il prompt di sistema è scritto in italiano (lingua operativa di Djungle), ma il modello tiene il bilinguismo nativamente.
Posso usarlo anche per i miei clienti?
Sì — è uno dei modelli d'uso. Iron, in particolare, viene installato presso clienti in turnaround. Il tenant del cliente è isolato dal tuo. La fattura è separata, la knowledge anche.