EverMind åbner for EverOS, et open source memory‑runtime til AI‑agenter, der lagrer hukommelse som redigerbare Markdown‑filer og henter viden via en hybrid søgning, der blander BM25, vektor‑match og simple filtre. Lad os være ærlige: stateless LLM’er har længe været agenterens akilleshæl. Samtalen slutter, konteksten fordamper. EverOS forsøger at gøre hukommelse til en første‑klasses borger, ikke et eftertænkt bilag.
Hvad er EverOS teknisk?
Ifølge MarkTechPost er EverOS frigivet under Apache 2.0 og implementeret som et Python‑bibliotek med en local‑first runtime, der kan køre som server med CLI og FastAPI‑endpoint. Designet er async‑first. Man kan køre lokalt eller via en managed EverOS Cloud, hvor format og SDK er de samme. Pointen er inspektérbarhed: hvert lag kan åbnes og forstås, ingen sort boks.
Selve hukommelsen lever som almindelige .md‑filer, som agenter kan læse, redigere og søge i på tværs af sessioner. Markdown bliver “source of truth” — ikke som vedhæft i en tung database, men som filer der kan åbnes i en editor, greppes i terminalen eller ligge i et git‑repo. Det er bevidst lav‑friktion.
Tre‑lags storage‑stacken
Stacken beskrives som tre‑delt: Markdown til indholdet, SQLite til state og køer, og LanceDB til vektorer, BM25 og filtrering. Ingen Elasticsearch, Milvus eller Kafka som standard. Det sænker kompleksiteten, især for små teams, men skubber ansvar over på korrekt indeks‑synk og samtidig adgang.
EverOS’ endpoint‑stack er kompatibel med OpenAI‑protokollen, og der nævnes udskiftning mellem OpenAI, OpenRouter, vLLM, Ollama og DeepInfra ved at ændre base‑URL. I praksis vil netværk, auth og rate‑limits stadig kræve opsætning og test. En linje i en config løser sjældent alt, men friktionen kan falde.
Hvordan fungerer retrieval i praksis?
Retrieval er hybrid i én LanceDB‑forespørgsel: BM25 for nøgleord, vektor for semantik, plus skalarfiltre for scopes som user_id, agent_id, app_id, project_id og session_id. Den kombination kan give højere præcision end ren embedding‑ eller tekstmatch alene.
Under motorhjelmen ligger “cascade index sync”. Når en .md‑fil redigeres, fanger en fil‑watcher ændringen og opdaterer indeks. Det mindsker staleness, men rejser også driftsspørgsmål: Hvad sker der ved batch‑edits, merge‑konflikter eller mange samtidige filer i et multi‑tenant miljø? Latens kan variere med kombinationen af BM25 og vektoropslag.
Latens, relevans og konsistens
MarkTechPost gengiver leverandørens egne benchmarks, herunder under 500 ms p95 for retrieval. Det er lovende, men tallene er rapporteret af EverMind og bør kontrolleres på egne workloads. Hybrid søgning betyder flere deloperationer, så cache‑strategier, top‑k‑valg og filter‑granularitet bliver reelle knapper, der påvirker både relevans og svartid.
Konsistens afhænger af, at filændringer opsnappes og indekseres i rette rækkefølge. Ved højt write‑tryk eller netværkslag mellem noder kan der opstå perioder, hvor søgning og .md‑indhold ikke er helt i takt. For kritiske flows bør man tænke i idempotente opdateringer og eksplicitte resync‑jobs.
Memory‑model og operationel workflow
EverOS adskiller bruger‑orienterede records fra agent‑orienterede: Profiles, Episodes, Facts og Foresights på “bruger‑siden”; Cases og Skills på “agent‑siden”. Episoder beskriver hvad der skete, profiler hvem brugeren er, fakta er stabile oplysninger, og foresights peger frem.
Cases opsamler gennemførte opgaver, som siden destilleres til genbrugelige Skills. Det kaldes procedural, selv‑evolving memory. Ideen er, at agenten lærer mønstre over tid uden manuel hardcoding. EverAlgo, en separat stateless komponent, står for udtræksalgoritmer, mens EverOS orkestrerer og gemmer resultatet. Det åbner for ingeniørmønstre som offline validering af nye Skills, versionsmærkning og rollback ved fejl.
Den menneskeligt læsbare hukommelse er også en driftsfordel: git‑historik, pull‑requests, code owners — kendte værktøjer. Omvendt betyder .md‑filer følsomme data i klartekst, medmindre der indføres kryptering, adgangskontrol og klare regler for, hvad der må gemmes hvor.
Integration og drift
“Drop‑in” er løftet: eksisterende agent‑loops kan i udgangspunktet pege på EverOS via et OpenAI‑kompatibelt endpoint; ofte blot en base‑URL der skiftes. Men forvent arbejde med netværk, autentifikation, proxy’er og timeout‑politik — især hvis EverOS kører lokalt og modeller ligger hos hosted udbydere. Et par konfigurationsflag bliver sjældent hele historien.
Driftsmæssigt er stacken lettere end de fleste: SQLite til state, LanceDB til søgning og en fil‑watcher. Backup bliver filkopi og snapshot af SQLite. Versionering kan håndteres i git. Til gengæld kræver multi‑tenant drift en plan for concurrency (fil‑locks, transaktioner), index‑resync ved restore og overvågning af latensspidser, når hybrid‑spørgsmål presser CPU og RAM.
Lokal‑først eller managed cloud
Lokal‑først hjælper compliance: data kan blive i eget miljø, og hvert lag kan inspiceres. Managed cloud kan give enklere skalering og SLA’er. Valget handler om kompetencer og risikovillighed. Uanset model kræves en klar politik for sletning, retention og hvem der må se hvad i den redigerbare hukommelse.
Dokumentér backup/restore‑procedurer, definér versionsstrategi for .md (branch‑model, merge‑regler) og aftal, hvornår et index‑resync er påkrævet efter større importer. Tekstkonflikter kl. 02.13 er ikke tiden, man vil opfinde processen.
Sikkerhed, compliance og prompt‑injection
Prompt‑injektion er fortsat en toptrussel mod LLM‑systemer ifølge OWASP LLM Top 10 2025, omtalt i VentureBeat. Agenter og RAG‑pipelines er særligt udsatte, fordi de blander brugerinput, eksterne kilder og automatisk handling.
Local‑first og inspektérbarhed hjælper: man kan se, hvad der ligger i hukommelsen, auditere ændringer og rulle tilbage. Men den samme redigerbarhed udvider angrebsfladen. En fjendtlig passage i en .md kan manipulere både BM25‑ranking og vektor‑match. Der er også risiko for vektor‑poisoning og misbrug af fil‑watcheren til at trigge uønskede opdateringer. Adgangskontrol og input‑sanitering er ikke valgfrie.
Isolering og styring
EverOS giver mulighed for scoping af søgninger via user_id, agent_id, app_id m.m. Det er godt for isolation. Men organisationer bør lægge et ekstra lag ovenpå: policy‑baserede filtre, signering af skriftlige kilder samt skemaer for, hvad der må ind i memory overhovedet. Og en audit‑log, der viser hvem eller hvad der ændrede en record hvornår.
Til governance hører også sletningspolitik. Kilden beskriver ikke i detaljer, hvordan sletning og retention håndteres, eller hvordan kryptering og adgang håndteres end‑to‑end. Det hul skal lukkes ved implementering med egne kontroller.
Begrænsninger og hvad kilderne ikke beviser
Benchmarktallene er EverMind‑rapporterede. De skal verificeres uafhængigt på egne data og egne latenskrav. Der mangler konkrete beskrivelser af, hvordan stacken opfører sig under høj samtidighed, store mængder .md‑filer eller streng multi‑tenant isolation i enterprise‑miljøer.
Det er uklart, hvor detaljeret kryptering, adgangskontrol, audit‑logning og sletning er tænkt i baseline. Også migrationsværktøjer fra eksisterende memory‑stores er ikke beskrevet udførligt. Trusselsmodeller for hybrid retrieval (manipulation af BM25 via metadata, vektor‑poisoning, fil‑watcher‑misbrug) bør adresseres eksplicit før produktion.
Anbefalinger for virksomheder
Start med en lille proof of concept: én agent, klart afgrænset domæne, få brugere. Brug rigtige data under kontrollerede forhold. Hold øje med retrieval‑relevans, svartid og fejltyper. Dokumentér, hvor hukommelsen hjælper, og hvor den forvirrer modellen.
Kør målinger: end‑to‑end latens (p50/p95), kvalitet på top‑k hits mod et mærket eval‑sæt, ressourcetræk under spike‑load og effekt af forskellige embedding‑modeller. Kør også adversarial tests for prompt‑injektion og data‑exfiltration i både chat og fil‑indtag (markdown‑indhold med skjulte instruktioner, on‑save triggers, linkede kilder).
Governance‑tjekliste
- Adgangskontrol: rolle‑baseret adgang til hukommelsesmapper og API‑nøgler.
- Kryptering: i hvile for filer/SQLite, i transit for API‑kald.
- Sletningspolitik: processer for “ret til at blive glemt” og fuld sletning i både .md og indeks.
- Audit og versioner: obligatorisk versionsstyring, signering af ændringer samt periodiske reviews.
- Skill‑styring: validering før udrulning, automatisk rollback, sporbarhed mellem Case og Skill‑version.
- Index‑hygiejne: planlagte resync‑jobs, konsistenskontrol efter restore og imports.
Hvad kræver integration uden total rewrite?
Med OpenAI‑protokolkompatibilitet kan mange klienter tale med EverOS ved at pege mod et nyt endpoint. Men forvent at finjustere timeouts, streaming, token‑grænser og error‑håndtering. Hvis I bruger mellemled som OpenRouter eller vLLM, så tjek rate‑limits og backoff‑strategier, især når fil‑watcher udløser genindeksering og flere samtidige opslag.
Planlæg også import: eksisterende noter, kundedata eller cases skal normaliseres til Markdown. Definér et skema (front‑matter, tags, IDs). Beslut, hvordan I mapper gamle kontekster til Profiles, Episodes, Facts og Foresights. Små valg her bliver store senere.
Konklusion
EverOS er et konkret bud på vedvarende agent‑hukommelse, der ikke gemmer sig bag proprietære vægge. Markdown som sandhed, SQLite til state, LanceDB til søgning. Det er jordnært. For små teams, research og prototyper kan det være et stærkt værktøj allerede nu. Det interessante er, at hukommelsen bliver læsbar og reviderbar.
