Second Brain OS
AI agent’ları için düz metin dosyalarında tutulan kalıcı bellek. Projeler arasında taşınan bilgi tek bir vault’ta, her projenin güncel durumu kendi reposunda duruyor. Yeni bir session projeyi baştan dinlemek yerine bu dosyaları okuyup kaldığı yerden devam ediyor; aynı dosyaları insan da açıp okuyabiliyor.
- Durum
- Kullanımda, geliştirme sürüyor. Açık şablon Eylül 2026’da v1.0 ile yayımlandı; proje durumunu repolara taşıyan v1.1 de yayında.
- Ne
- AI agent’ları için dosya tabanlı, uzun süreli bellek ve proje durumu sistemi
- Yığın
- Markdown · YAML frontmatter · [[wikilink]] · Git · Node.js script’leri · Claude Code ve Codex hook’ları ve skill’leri · Obsidian
- Kod
- github.com/brkakyldz/second-brain-os — açık şablon, v1.1
01
Kısaca
- Problem
- Her yeni AI session’ı sıfırdan başlıyor: projenin bağlamını, verilmiş kararları ve tercihleri her seferinde yeniden anlatmak gerekiyor. Anlatılmadığında agent makul görünen ama bu projede yanlış olan cevaplar veriyor. Aynı anda birkaç proje yürüdüğünde bir sorun daha çıkıyor: bir projenin durumu birkaç farklı yerde yazılı kalıyor ve bunlardan biri er geç eskiyor.
- Kullanıcı için değişen
- Notlar, kararlar ve çalışma kayıtları bir sonraki session’ın okuyup devam edebileceği kalıcı bir belleğe dönüşüyor. Bir projeye dönen session, nerede kalındığını o projenin kendi reposundaki tek bir durum dosyasından okuyor; projelerden çıkan bilgi ve dersler vault’ta birikiyor. Aynı dosyaları insan da okuyup düzeltiyor, bu yüzden bellek her zaman denetlenebilir.
- Bunu mümkün kılan karar
- Bellek düz Markdown dosyalarından ibaret: veritabanı, vector store ya da embedding indeksi yok. Sürüm geçmişini Git tutuyor, yanlış bir yazma geri alınabiliyor. Her session’da belleğin tamamı değil, sadece o an gereken kısmı yükleniyor. Her kayıt da okunduğu yerde tutuluyor: bir projenin durumu kendi reposunda, projeyi aşan bilgi vault’ta.
- Kanıt
- Aynı sorular aynı modele iki kez soruldu: bir kez belleğe tam erişimle, bir kez sadece kısa bir tanıtım metniyle. Bellekli taraf açık farkla daha fazla soruyu doğru cevapladı; belleksiz taraf yanlışlarını kendinden emin bir dille verdi. Doğru cevapların hepsi aramayla bulunan bir Markdown dosyasından geldi. Proje durumunu repolara taşıma kararı da bir taramadan çıktı: 12 proje reposu ve 405 session kaydı.
02
Yakından
Bu projede uğraştığım şey, agent’ın bir session’da öğrendiğini bir sonraki session’da da bilmesiydi.
Belleğin biçimi
Belleği düz Markdown dosyalarında tutuyorum.
Belleği bir veritabanına ya da vector store’a koymak yerine düz Markdown dosyalarında tuttum. Her notun üstünde birkaç satırlık bir künye var ve notlar birbirine bağlantılarla bağlanıyor. Böylece aynı klasör üç işi birden görüyor: ben onu Obsidian’da bir vault olarak geziyorum, agent onu belleği olarak okuyor, Git de her değişikliği bir sürüm olarak saklıyor. Yanlış bir yazma olursa o commit geri alınarak düzeltilebiliyor.
Belleğin tamamını her session’da okutmuyorum. En üstte her session’da otomatik yüklenen birkaç küçük dosya var: kim olduğum, ne üzerinde çalıştığım ve kalıcı bilgiler. Notların kendisi gerektiğinde açılıyor; session kayıtları ise sadece belirli bir gün sorulduğunda okunuyor.
Klasörleri konuya göre değil, notun yaşam evresine göre ayırdım. Bir not olgunlaştığında yer değiştirmediği için ona verilmiş hiçbir bağlantı kırılmıyor. Her session’da yüklenen katmanın boyutu karakterle sınırlı; sınır aşıldığında bilgi kırpılmak yerine benzer satırlarla birleştiriliyor.
Aynı belleği iki agent ortamı, Claude Code ve Codex, eşit olarak kullanıyor. Kurallar tek bir dosyada, skill’ler tek bir kopyada duruyor; iki taraf da aynı dosyaları okuduğu için aralarında bir fark oluşmuyor.
Karar · kod ve model
Kodla kontrol edilebilen işleri script’lere, yorum isteyen işleri modele bıraktım.
Kırık bağlantı var mı, bir dosya bütçesini aştı mı, kaç not birikti gibi sorular kodla kontrol ediliyor. İki notun aynı bilgiyi anlatıp anlatmadığına karar vermek ise yorum istiyor; o kararı modele bıraktım. Otomatik kontroller çalışmayı hiçbir zaman durdurmuyor, bir bakım aracı bozulsa bile session devam ediyor.
Belleğe her şey aynı kapıdan giriyor ve her yeni bilgi için tek bir karar veriliyor: yeni bir not açmak, var olan notla birleştirmek, eskisinin yerine geçmek ya da hiçbir şey yapmamak. Bir bilginin her session’da yüklenen katmana girmesi için de ikinci ve bağımsız bir teyit gerekiyor. Bunu şart koştum, çünkü o katmana giren tek bir yanlış bilgi sonraki her session’a taşınıyor.
Proje durumu
Projelerin güncel durumunu vault’tan çıkarıp her projenin kendi reposuna taşıdım.
İlk tasarımda projelerin durumu da vault’ta tutuluyordu. Proje sayısı arttıkça bu kayıtların gerçekte nasıl okunduğuna baktım ve 12 proje reposunu, 405 session kaydını taradım. Bir projeye geri dönen session’lar kaldıkları yeri her seferinde projenin kendi dosyalarından okuyordu; vault’taki proje notundan devam eden bir session yoktu. Zaman içinde güncel kalan tek durum kaydı da projenin içinde tutulan ve her iş bitiminde yeniden yazılan tek bir dosyaydı.
Bu yüzden kayıtları okundukları yere göre ayırdım. Bir projenin durumu, yani nerede kalındığı, sıradaki adım ve açık kararlar, o projenin reposunda tek bir dosyada duruyor. Yanında sadece eklenerek büyüyen bir çalışma günlüğü ve agent’ın kendi başına yürüttüğü her çalışmanın raporu var; planlar ve araştırmalar dahil hepsi commit ediliyor. Vault’ta ise projeden daha uzun yaşayan şeyler kalıyor: her proje için reposunu ve neden var olduğunu gösteren ince bir kart, projelerden çıkan dersler ve birden fazla projenin işine yarayan alan bilgisi.
Bir iş bittiğinde bir kapanış adımı iki tarafı birlikte güncelliyor: repodaki durum dosyasını ve günlüğü yazıyor, sadece o işin değiştirdiği dosyaları commit ediyor ve vault’a projeye geri işaret eden tek bir kısa kayıt bırakıyor. Ayrı bir script de bütün proje kartlarının gösterdiği repoları salt okunur olarak tarıyor; commit edilmemiş proje belleğini, güncelliğini yitirmiş bir durum dosyasını ya da geride kalmış worktree’leri raporluyor.
Ölçülen
Belleğin işe yarayıp yaramadığını aynı soruları iki kez sorarak ölçtüm.
Aynı soruları aynı modele iki kez sordum: bir kez belleğin tamamına erişimle, bir kez sadece kısa bir tanıtım metniyle. Bellekli taraf açık farkla daha iyiydi; belleksiz taraf yanlış cevaplarını kendinden emin ve genel bir dille verdi. Doğru cevapların hepsi aramayla bulunan düz Markdown dosyalarından geldi; bu cevaplarda otomasyon araçlarının bir payı yoktu.
- veritabanı · vector store · embedding indeksi
- 0
- bellek katmanı · her session’da sadece gereken yükleniyor
- 3
- yazılı mimari karar · her biri gerekçesiyle
- 45
Karşılaştırmanın düzeneği yerinde duruyor; bellekte yapılan her değişiklikten sonra yeniden çalıştırılabiliyor.
03
Nasıl çalışır
Okuma
- Session açılıyor; çekirdek kendiliğinden yükleniyor: kim olduğum, ne üzerinde çalıştığım, kalıcı bilgiler.
- Bir proje soruluyor. Notların tamamı değil, gereken iki üç not açılıyor.
- Session kayıtları sadece belirli bir gün sorulduğunda okunuyor.
- Cevap düz Markdown dosyalarından geliyor. Veritabanı, vector store ya da embedding kullanılmıyor.
Yazma
- Session’da yeni bir bilgi çıkıyor. Belleğe her şey aynı kapıdan giriyor.
- Her yeni bilgi için tek bir karar veriliyor: yeni not, birleştir, eskisinin yerine geç ya da hiçbir şey yapma.
- İlk kez görülen bir bilgi notlara düşük güvenle giriyor ve değişiklik bir commit oluyor. Yanlış bir yazma her zaman geri alınabiliyor.
- Bilginin her session’da yüklenen çekirdeğe girmesi için onu ikinci, bağımsız bir session’ın da doğrulaması gerekiyor.
- Teyit gelince bilgi çekirdeğe giriyor. Çekirdeğin boyutu sınırlı; sınır aşılırsa bilgi kırpılmak yerine benzer satırlarla birleştiriliyor.
Proje
- Session bir projenin reposunda açılıyor. Çekirdek her zamanki gibi yükleniyor ve yanında bir kural geliyor: işe başlamadan önce projenin kendi durum dosyasını oku.
- Agent nerede kalındığını, sıradaki adımı ve açık kararları projenin reposundaki tek bir durum dosyasından okuyor.
- İş bitince kapanış adımı çalışıyor: durum dosyası ve çalışma günlüğü güncelleniyor, agent kendi başına çalıştıysa raporu yazılıyor ve sadece bu işin dosyaları commit ediliyor.
- Vault’a projeye geri işaret eden tek bir kısa kayıt düşüyor. Ayrıntı repoda kalıyor, vault durumu kopyalamıyor.
- Vault’ta her projenin reposunu gösteren bir kartı var. Ayrı bir script bu kartlardan yola çıkıp bütün repoları salt okunur tarıyor; commit edilmemiş proje belleğini ya da eskimiş bir durum dosyasını raporluyor.