Agent memory runtime EverOS става Markdown-first
EverMind пусна EverOS, open-source agent memory runtime, на 29 юни 2026 г., като го позиционира като Markdown-first начин да даде на AI агентите памет между отделни сесии. Това е важно, защото повечето agent stack решения се провалят по скучни, но скъпи начини, когато контекстът изчезне: retry заявките се увеличават, handoff-ите стават хаотични и всяка задача започва от нулата. Според доклада на MarkTechPost от 29 юни за EverOS, EverOS се разпространява под Apache 2.0 и комбинира Markdown файлове, SQLite и LanceDB за постоянна памет.
EverMind releases EverOS to give AI agents persistent memory
От гледна точка на внедряването EverOS не се опитва да бъде цялостен agent framework. Това е Python библиотека и local-first runtime, който може да се включи в съществуващ loop, да се expose-не през FastAPI и да се насочи към model backends, които вече говорят OpenAI protocol. Именно този по-тесен обхват прави изданието важно за следене.
Проблемът, който адресира, е добре познат. В един клиентски prototype, по който работих миналия месец, моделът се справяше добре с support workflow през първите 20 минути, но във втората сесия забрави специфичните предпочитания на клиента и започна да иска информация, която вече беше видял. Моделът беше наред; memory layer-ът беше твърде тънък. EverOS е насочен точно към този пропуск: постоянна памет за AI агенти, без всичко да се натиква в един vector store.
MarkTechPost предава позиционирането ясно: EverOS третира паметта като файлове за редакция, а не като скрити записи в база данни. Това е практическа разлика, а не просто предпочитание в дизайна. Ако паметта е файл, инженерът може да я прегледа, сравни, версионира и поправи, без да измисля нов admin UI.
Markdown becomes the source of truth for agent memory
Необичайната част е източникът на истината. EverOS записва memory records като обикновени .md файлове, а придружаващата библиотека EverAlgo поема extraction логиката. Това означава, че profiles, episodes, facts, foresights, cases и skills са представени във формат, който човек може да отвори директно. Ако екипът ви вече използва Git, shell инструменти или системи за бележки като Obsidian, operational моделът е напълно разбираем от пръв поглед.
Това ми допада повече, отколкото очаквах. В production memory bug-овете често не са първо retrieval bug-ове; по-често са проблеми във формата на състоянието. Някое preference е слято два пъти. Ключът за user identity е drift-нал. Някоя extraction стъпка е overfit-нала към една фраза. Когато тези проблеми са скрити в embeddings, диагностиката става по-бавна. Съхраняването на каноничното състояние в Markdown дава на екипите по-прост път за debugging.
Все пак има indexing отдолу. EverOS използва file watching и sync cascade, така че редакциите в Markdown да не оставят търсенето остаряло. Това е частта, която бих тествал най-сериозно в пилотен проект, особено ако няколко агента или worker-и могат да пишат едновременно. Local-first звучи чисто, докато не се появят concurrent writes, partial failures и queue lag.
Свързан архитектурен избор е изолацията по обхват. Търсенията могат да бъдат ограничени по user_id, agent_id, app_id, project_id и session_id. За enterprise automation това е базово изискване. Ако интегрирах това в реален workflow, бих прегледал именно тези граници още преди която и да е benchmark графика.
Екипите, които оценяват как това се вписва в по-широк delivery stack, вероятно ще се интересуват по-малко от новостта с Markdown и повече от това колко бързо може да се интегрира в реални процеси. Там най-близкото приложение е AI Business Process Automation: EverOS изглежда най-полезен, когато паметта е един компонент в по-голям автоматизиран процес, а не самостоятелен science project.
How EverOS combines SQLite, LanceDB, BM25, and vectors
Под капака storage stack-ът е умишлено малък. Markdown е източникът на истината. SQLite управлява state и queues. LanceDB управлява vectors, BM25 и scalar filtering. В сравнение с по-тежки memory stack решения, които включват Redis, Elasticsearch, Kafka и отделна vector база данни, това е по-лек отпечатък за малък екип.
Ключовото твърдение при retrieval е хибридно търсене в една заявка: BM25 за прецизност по ключови думи, dense vectors за семантична близост и scalar filters за граници по метаданни. Ако някога сте виждали vector-only retrieval да пропуска точен продуктов код или име на клиент, защото embedding-ът е класирал по-обща концепция по-високо, знаете защо BM25 още има значение. Hybrid BM25 vector retrieval не е ефектно, но решава напълно реални failure mode-ове.
Според изходната статия EverMind нарича този комбиниран път multimodal retrieval-augmented generation, или mRAG. Механиката е по-важна от етикета. Въпросът е дали заявките ви са предимно семантични, предимно лексикални или смесени. В support логове, compliance текстове и техническо troubleshooting те обикновено са смесени.
Точно тук EverOS изглежда по-силен от prompt-only memory. Да добавяте още история в context window работи до момента, в който разходът, latency или attention decay не започнат да тежат. Retrieval layer с точно съвпадение на термини и scoped search обикновено остарява по-добре от подхода просто да направите prompt-а по-голям.
Cases turn into Skills in EverOS
По-интересната функция е procedural memory. EverOS съхранява завършените задачи като Cases, а след това извлича от повтарящите се успешни модели използваеми Skills. Аз бих описал това по-малко като магия на самоусъвършенстването и повече като компресия на workflow. Ако агентът многократно решава един и същ клас задачи, по-полезно е да се запази успешният път, отколкото да се трупат сурови transcript-и завинаги.
Въпреки това точно тук бих бил най-скептичен. Distillation pipeline-ите могат да drift-нат. Могат да over-generalize от малка извадка, да запазят крехки стъпки или да пренесат лошо решение, което просто е изглеждало успешно в един контекст. EverOS версия 1.1.0 добавя lifecycle компоненти като Knowledge APIs и Reflection, за да прецизира profiles, episodes и skills между сесиите, което е правилната посока. Но пак бих искал одит как един Case става Skill и колко лесно може да се направи rollback.
Изходната статия описва memory модела просто: episodic memory следи какво се е случило, profile memory следи кой е потребителят, а procedural memory следи как се изпълнява дадена задача. Това е полезно разделение. Повечето екипи започват с chat history, а после осъзнават твърде късно, че task memory и user memory не трябва да се смесват в един недиференциран лог.
Where EverOS fits versus naive RAG and full context windows
EverOS изглежда най-подходящ за екипи, които вече имат agent loop и им трябва по-малка memory subsystem, която могат да инспектират. Спрямо naive RAG ползата не е просто vectors плюс BM25. Тя е в комбинацията от четимо за хора състояние, metadata scoping и procedural memory layer. Спрямо подходите с пълен контекст ползата е в постоянството и селективността.
Но компромисите са реални. Истината, базирана на файлове, е по-лесна за инспекция, но може да стане по-трудна за управление, ако naming conventions, schema-ите и дисциплината при писане са разхлабени. SQLite държи stack-а компактен, но все пак трябва да се мисли за concurrency ограничения и recovery процедури. LanceDB намалява разрастването на stack-а, но пак поемате ангажимент да поддържате indexing и retrieval quality във времето.
От положителната страна runtime-ът изглежда лесен за пилотиране. MarkTechPost отбелязва Python 3.12+, local demo, FastAPI server и OpenAI-compatible endpoints, които могат да се пренасочат към OpenAI, OpenRouter, vLLM, Ollama или DeepInfra само със смяна на base URL. Това намалява integration tax за екипи, които искат да тестват memory слой, без първо да преправят model layer-а.
What teams should verify before adopting EverOS
Benchmark резултатите изглеждат обещаващо, но сами по себе си още не са достатъчни за решение. Изходната статия цитира докладвани от EverMind резултати от 93.05% на LoCoMo, 83.00% на LongMemEval, 93.04% на HaluMem и p95 retrieval latency под 500 ms. Бих ги приел като отправна точка, а не като доказателство. Пуснете същите тестове върху собствената си форма на натоварване, особено ако данните ви включват дълги технически нишки, строги tenancy boundaries или сесии с много записи.
Това, което бих следил нататък, е дали ранните потребители ще публикуват не само успешни примери, но и доклади за провали. Ако EverOS успее да запази memory layer-а инспектируем при реално multi-agent натоварване, Markdown-first дизайнът може да се наложи. Ако не, идеята пак може да повлияе на начина, по който екипите ще изграждат следващото поколение agent memory runtime решения, дори ако сменят части от stack-а.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation