Quarto articolo della serie sul sandbox per agenti. Si sposta l’avanzamento dalla memoria del container a un disco condiviso, poi si elimina di proposito il container che sta lavorando — un altro riprende da pagina 17. Compresa la parte onesta: questo «ripristino automatico» richiede ancora che qualcuno prema qualcosa.
Terzo articolo della serie sul sandbox per agenti. Il pool caldo è il posteggio dei taxi in aeroporto — si parte subito, e i motori consumano anche da vuoti. Più il resoconto onesto dei tre difetti di questo dispatcher, che sono poi ciò che rende necessari gli articoli seguenti.
Secondo articolo della serie sul sandbox per agenti. Un container per task sembra ovvio, e fa aspettare l’utente dai 45 ai 90 secondi dopo l’invio. Dove finiscono davvero quei secondi, e perché l’interfaccia costruita per amministrare un cluster non deve stare sul percorso che l’utente clicca.
Primo articolo della serie sul sandbox per agenti. Chiedi a un’AI di lavorare due ore di fila e la distanza tra «funziona» e «si può mettere online» si riduce a una cosa: l’isolamento. Un piccolo servizio, ucciso di proposito dal sistema, rende il problema visibile. I termini sono spiegati man mano: non serve conoscere Kubernetes.
Dove passa il confine tra ontologia, knowledge graph, schema di database, workflow e agente — e perché credo che un’azienda non debba costruire un’ontologia globale dall’alto, ma ricavarla a ritroso dalle azioni che i suoi agenti sono autorizzati a compiere.
Dopo aver messo insieme il materiale pubblico, la mia conclusione è che il valore di Glean non sta nella qualità della ricerca, ma nell’aver portato a termine il lavoro ingrato di «chi può vedere cosa». In coda, cosa penso della tesi che il contesto lungo sostituirà il RAG.