Il runtime di memoria per agenti EverOS adotta un approccio Markdown-first
EverMind ha rilasciato EverOS, un runtime di memoria per agenti open source, il 29 giugno 2026, posizionandolo come una soluzione Markdown-first per fornire agli agenti AI una memoria persistente tra le sessioni. Questo è fondamentale perché la maggior parte degli stack per agenti fallisce in modi noiosi e costosi non appena il contesto svanisce: i tentativi aumentano, i passaggi di consegne diventano caotici e ogni attività riparte da zero. Secondo il report del 29 giugno di MarkTechPost su EverOS, EverOS è distribuito con licenza Apache 2.0 e combina file Markdown, SQLite e LanceDB per la memoria persistente.
EverMind rilascia EverOS per fornire memoria persistente agli agenti AI
Dal punto di vista dell'implementazione, EverOS non cerca di essere un framework completo per agenti. È una libreria Python e un runtime local-first che puoi inserire in un ciclo esistente, esporre tramite FastAPI e puntare a backend di modelli che supportano già il protocollo OpenAI. Questo ambito più ristretto è il motivo per cui vale la pena seguire questo rilascio.
Il problema che affronta è noto. In un prototipo per un cliente su cui ho lavorato il mese scorso, il modello ha gestito bene un flusso di lavoro di supporto per i primi 20 minuti, poi ha dimenticato le preferenze specifiche del cliente nella seconda sessione e ha iniziato a chiedere informazioni che aveva già visto. Il modello andava bene; il livello di memoria era debole. EverOS punta esattamente a questa lacuna: memoria persistente per agenti AI senza forzare tutto in un unico vector store.
MarkTechPost riassume chiaramente l'idea: EverOS tratta la memoria come file modificabili anziché come record di database nascosti. Si tratta di una distinzione pratica, non solo di una preferenza di design. Se la memoria è un file, un ingegnere può ispezionarlo, confrontarlo, versionarlo e ripararlo senza dover inventare un'altra interfaccia di amministrazione.
Il Markdown diventa la fonte di verità per la memoria degli agenti
L'aspetto insolito è la fonte di verità. EverOS scrive i record di memoria come file .md semplici, mentre una libreria complementare, EverAlgo, gestisce la logica di estrazione. Ciò significa che profili, episodi, fatti, previsioni, casi e competenze sono tutti rappresentati in un formato che un essere umano può aprire direttamente. Se il tuo team utilizza già Git, strumenti shell o sistemi di note come Obsidian, il modello operativo è immediatamente leggibile.
Questo mi piace più di quanto mi aspettassi. In produzione, i bug di memoria spesso non sono bug di recupero; sono bug legati alla struttura dello stato. Una preferenza è stata unita due volte. Una chiave di identità utente è cambiata. Un passaggio di estrazione ha sovradimensionato una frase. Nascondere questi problemi all'interno degli embedding li rende più lenti da diagnosticare. Memorizzare lo stato canonico in Markdown offre ai team un percorso di debug più semplice.
Esiste comunque un'indicizzazione sottostante. EverOS utilizza il monitoraggio dei file e una cascata di sincronizzazione in modo che le modifiche al Markdown non rendano obsoleta la ricerca. Questa è la parte che testerei a fondo in un progetto pilota, specialmente se più agenti o worker possono scrivere contemporaneamente. Il local-first sembra pulito finché non compaiono scritture simultanee, errori parziali e ritardi nelle code.
Una scelta di design correlata è l'isolamento dell'ambito. Le ricerche possono essere limitate da user_id, agent_id, app_id, project_id e session_id. Per l'automazione aziendale, questo è il minimo indispensabile. Se dovessi integrare questo sistema in un flusso di lavoro live, esaminerei questi confini prima di qualsiasi benchmark.
I team che valutano come questo si inserisce in uno stack di distribuzione più ampio probabilmente si preoccuperanno meno della novità del Markdown e più della rapidità con cui può essere integrato nei flussi di lavoro reali. È qui che un servizio come AI Business Process Automation è la soluzione più adatta: EverOS appare più utile quando la memoria è un componente all'interno di un processo automatizzato più ampio, non un progetto scientifico a sé stante.
Come EverOS combina SQLite, LanceDB, BM25 e vettori
Sotto il cofano, lo stack di archiviazione è intenzionalmente piccolo. Il Markdown è la fonte di verità. SQLite gestisce lo stato e le code. LanceDB gestisce vettori, BM25 e filtraggio scalare. Rispetto agli stack di memoria più pesanti che includono Redis, Elasticsearch, Kafka e un database vettoriale separato, questo ha un impatto minore per un piccolo team.
La chiave del recupero è la ricerca ibrida in un'unica query: BM25 per la precisione delle parole chiave, vettori densi per la similarità semantica e filtri scalari per i confini dei metadati. Se hai mai visto un recupero basato solo su vettori mancare un codice prodotto esatto o un nome cliente perché l'embedding classificava più in alto un concetto più ampio, sai perché il BM25 è ancora importante. Il recupero ibrido BM25-vettoriale non è appariscente, ma risolve problemi reali.
Secondo l'articolo originale, EverMind definisce questo percorso combinato come generazione aumentata dal recupero multimodale, o mRAG. I meccanismi contano più dell'etichetta. La domanda è se le tue query siano principalmente semantiche, lessicali o miste. Nei log di supporto, nei testi di conformità e nella risoluzione dei problemi tecnici, sono solitamente miste.
È anche qui che EverOS sembra più forte della memoria basata solo sul prompt. Aggiungere più cronologia alla finestra di contesto funziona finché non iniziano a pesare costi, latenza o decadimento dell'attenzione. Un livello di recupero con corrispondenza esatta dei termini e ricerca limitata solitamente invecchia meglio rispetto al semplice aumento del prompt.
I casi diventano Skills in EverOS
La funzionalità più interessante è la memoria procedurale. EverOS archivia le attività completate come Casi, quindi distilla i modelli di successo ripetuti in Skills riutilizzabili. La descriverei meno come una magia di auto-miglioramento e più come una compressione del flusso di lavoro. Se un agente risolve ripetutamente la stessa classe di attività, preservare il percorso di successo è più utile che archiviare trascrizioni grezze per sempre.
Detto questo, è qui che sarei più scettico. Le pipeline di distillazione possono deviare. Possono generalizzare eccessivamente da un piccolo campione, preservare passaggi fragili o portare avanti una decisione sbagliata che sembrava corretta in un contesto. EverOS versione 1.1.0 aggiunge componenti del ciclo di vita come Knowledge API e Reflection per perfezionare profili, episodi e competenze tra le sessioni, il che è la direzione giusta. Ma vorrei comunque audit su come un Caso diventa una Skill e quanto sia facile tornare indietro.
L'articolo originale spiega il modello di memoria in modo semplice: la memoria episodica tiene traccia di ciò che è accaduto, la memoria del profilo tiene traccia di chi è l'utente e la memoria procedurale tiene traccia di come viene svolta un'attività. È una separazione utile. La maggior parte dei team inizia con la cronologia delle chat, poi si rende conto troppo tardi che la memoria delle attività e la memoria dell'utente non dovrebbero essere mescolate in un unico log indifferenziato.
Dove si colloca EverOS rispetto alla RAG ingenua e alle finestre di contesto complete
EverOS sembra ideale per i team che hanno già un ciclo di agenti e necessitano di un sottosistema di memoria più piccolo che possano ispezionare. Rispetto alla RAG ingenua, il vantaggio non è solo vettori più BM25. È la combinazione di stato leggibile dall'uomo, scoping dei metadati e un livello di memoria procedurale. Rispetto agli approcci a contesto completo, il vantaggio è la persistenza e la selettività.
Ma i compromessi sono reali. La verità basata su file è più facile da ispezionare, ma può diventare più difficile da governare se la denominazione, gli schemi e la disciplina di scrittura sono sciatte. SQLite mantiene lo stack compatto, ma devi comunque pensare ai limiti di concorrenza e alle procedure di ripristino. LanceDB riduce la dispersione dello stack, ma ti impegni comunque a gestire l'indicizzazione e la qualità del recupero nel tempo.
Sul lato positivo, il runtime sembra facile da testare. MarkTechPost nota Python 3.12+, una demo locale, un server FastAPI ed endpoint compatibili con OpenAI che possono essere reindirizzati a OpenAI, OpenRouter, vLLM, Ollama o DeepInfra con una modifica dell'URL di base. Ciò riduce l'onere di integrazione per i team che vogliono testare la memoria senza dover prima cambiare piattaforma al livello del modello.
Cosa dovrebbero verificare i team prima di adottare EverOS
I numeri dei benchmark sono promettenti ma non ancora decisivi di per sé. L'articolo cita punteggi riportati da EverMind del 93,05% su LoCoMo, 83,00% su LongMemEval, 93,04% su HaluMem e una latenza di recupero p95 inferiore a 500ms. Li considererei un punto di partenza, non una prova. Esegui gli stessi test sul tuo carico di lavoro, specialmente se i tuoi dati includono lunghi thread tecnici, rigidi confini di tenancy o sessioni ad alta scrittura.
Ciò che osserverò in seguito è se i primi utilizzatori pubblicheranno report sui fallimenti oltre ai casi di successo. Se EverOS mantiene il livello di memoria ispezionabile sotto un carico reale multi-agente, il design Markdown-first potrebbe affermarsi. In caso contrario, l'idea potrebbe comunque influenzare il modo in cui i team costruiscono la prossima generazione di runtime di memoria per agenti, anche se dovessero sostituire parti dello stack.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation