Buzz’da olay hafızası: Bir konuşma ne zaman işe yarar?

Bir ekipte aynı hata ikinci kez ortaya çıktığında ilk soru genellikle “Bunu daha önce nasıl çözmüştük?” olur. Birisi eski sohbeti bulur, başka biri kod değişikliğini arar, üçüncü kişi o günkü dağıtım kararını hatırlamaya çalışır. Kayıtlar mevcut olabilir ama aynı karara bağlanmıyorsa işe yarayan bir hafıza oluşmaz. Ajanın bütün bu kaynakları okuyabilmesi de tek başına sorunu çözmez. Hangi kaydın kesinleşmiş karar, hangisinin yalnızca bir ihtimal olduğunu anlaması gerekir.

Buzz, Block’un geliştirdiği açık kaynak, kendi sunucunuzda çalıştırılabilen insan ve ajan çalışma alanı. Nostr relay üzerinde mesajları, iş akışı adımlarını, inceleme olaylarını ve Git olaylarını imzalı kayıtlar olarak ele alıyor. Masaüstü uygulaması, ajanlara yönelik komut satırı aracı ve Goose, Codex ile Claude Code için ACP bağlantısı bulunuyor. Bu yazı Buzz’ın “her şey aynı olay günlüğünde” yaklaşımına başka bir açıdan bakıyor: Kayıtları bir araya getirmek, onları güvenilir bilgiye nasıl dönüştürür?

Aynı yerde durmak aynı şeyi söylemek değildir

Buzz’ın aranabilir kanal geçmişi, yama ve inceleme kaydını yan yana koyması güçlü bir başlangıç. Hata tartışmasının yanından ilgili Git olayına geçmek, olay sırasında ne söylendiğini görmeyi kolaylaştırır. Bu, farklı uygulamalarda birbirinden kopuk duran bilgilerin ilişkilendirilmesi için pratik bir çalışma alanıdır.

Yine de bir kanal mesajı ile test raporu aynı türden kanıt değildir. Bir geliştirici “muhtemelen önbellek kaynaklı” diye yazmış olabilir; sonra asıl nedenin veri eşlemesi olduğu ortaya çıkabilir. İlk cümle imzalı bir olay olarak kalır. İmza, cümlenin doğru olduğunu değil, kimin söylediğini gösterir. Arama sonucunda ilk yorumu bulan bir ajan, onu son karar gibi alırsa olay günlüğü yanlış teşhisi daha hızlı yayar.

Önceki Buzz yazısında kayda geçmiş bir onay ile yetkili onayın ayrımını ele almıştık. Hafıza açısından benzer bir ayrım var: Arşivde bulunan bilgi ile güncel, doğrulanmış bilgi ayrı şeyler. Birincisi geçmişe bakmayı mümkün kılar. İkincisi bugünkü işlemi güvenle yönlendirmek için bağlam ve kontrol ister.

İkinci kez yaşanan bir olay

Bir web uygulamasında bazı kullanıcıların rapor indirme isteği zaman aşımına düşsün. İlk olayda ekip bir kanalda birkaç olası neden tartışmış, sorgu planını incelemiş ve bir yama göndermiş olsun. İkinci olayda görevli ajan Buzz’da “rapor zaman aşımı” araması yapıyor. Kanal mesajını, yamayı ve inceleme notunu bulabiliyor. Bu noktada aceleci bir otomasyon, önceki yamayı yeni olaya uygulamaya çalışır.

Oysa iki olayın koşulları farklı olabilir. İlkinde belirli bir sorgu ağırdı; ikincisinde dosya depolama hizmeti yanıt vermiyordur. Önceki yamanın kodda hâlâ bulunup bulunmadığı ve hangi sürümde dağıtıldığı da ayrıca kontrol edilmelidir. İyi bir ajan geçmişi emir olarak değil, araştırma yolu olarak kullanır. İlk olayın teşhisini okur, o teşhisin dayandığı ölçümleri bulur, yeni olayda aynı belirtilerin varlığını sınar. Sonra yeni kanala hangi bulgunun tekrarlandığını, hangisinin tekrarlanmadığını yazar.

Buzz bu araştırmanın izini aynı çalışma alanında tutmaya elverişli. Bir kişinin hatırladığını ayrı bir mesaja taşımak yerine olay, inceleme ve konuşmanın bağlantısı korunabilir. Fakat bağlantının varlığı otomatik olarak nedensellik kurmaz. Yama ile zaman aşımı aynı kanalda geçti diye o yamanın bugünkü arızayı çözeceğini söyleyemeyiz.

Arama sonucuna kaynak türü eklemek

Böyle bir çalışma alanında hafızayı kullanılabilir kılmanın ilk adımı kaynağın statüsünü açık yazmak. “Gözlem” ne görüldüğünü söyler. “Hipotez” olası açıklamadır. “Doğrulama” hangi testin veya ölçümün hipotezi desteklediğini kaydeder. “Karar” ise kimin, hangi değişiklik için, hangi koşullarda ilerleme izni verdiğini belirtir. Bunlar tek bir şablona sıkıştırılmak zorunda değil; kısa bir kanal özeti ve ilgili commit bağlantısı bile yeterli olabilir. Önemli olan yorumun sonuca dönüşürken nerede sınandığının görülebilmesidir.

Ajanın yanıtı da kaynak türünü korumalı. “Önceki olayda sorgu planı incelendi, ardından şu değişiklik yapıldı” demek, “zaman aşımını şu değişiklik çözer” demekten farklıdır. İlk cümle geçmişi aktarır. İkincisi bugünkü duruma yönelik bir öneridir ve yeni kanıt gerektirir. Arama sisteminin her iki cümleyi aynı güven düzeyinde sunması, ekipte yanlış bir kesinlik hissi yaratır.

Bir başka sınır erişim kapsamıdır. Ajanın geçmiş kanallarda arama yapabilmesi, her projenin konuşmasını okuması gerektiği anlamına gelmez. Müşteri verisi veya hassas olay ayrıntıları bulunan alanlarda, aramanın kapsamı göreve göre daraltılmalı. Buzz’ın ajanlara ayrı kimlik ve kanal üyeliği vermesi bu ayrımı ifade etmek için bir araç sağlar; çalışma ortamındaki dosya ve servis izinleri yine ayrı denetlenmelidir.

Küçük bir hafıza denemesi

Uygulanabilir bir başlangıç, tek bir tekrar eden hata türünü seçmek. İlk olayın kanalını, ilgili kod değişikliğini ve varsa dağıtım sonucunu birlikte inceleyin. Ardından bir kişiden, geçmişi hiç bilmeden, yalnızca bu kayıtlardan olayın teşhisini ve kesinleşen kararı çıkarmasını isteyin. Hangi adımda tahmin etmek zorunda kaldığını not edin. Eksik olan şey daha fazla sohbet mi, yoksa kararın dayandığı kanıtın bağlantısı mı?

Sonraki olayda ajanı aynı geçmiş üzerinde çalıştırırken yanıtından üç ayrı bölüm beklemek yararlı: geçmişte gözlenenler, bugün henüz doğrulanmayanlar ve kontrol edilmesi gerekenler. Böylece hız kazanımı, eski çözümü kopyalamaktan değil, araştırma yolunu kısaltmaktan gelir. Başarının ölçüsü aramada kaç sonuç bulunduğu değil, yeni kararın hangi kayıt ve hangi güncel ölçümle gerekçelendirildiğidir.

Buzz’ın ortak olay hafızası, bir ekibin geçmiş konuşma ile teknik değişiklik arasında gidip gelmesini kolaylaştırır. Hafızanın hangi rol tarafından kullanıldığı, kimin yorumu karara çevirebildiği ve hangi ajanın hangi kanalı görebileceği ise organizasyon düzeyinde tanımlanmalıdır. Bu ilişkiyi açık kurmak için agentic-organization, AI ajanlarını organizasyon şemasında birinci sınıf üye olarak yöneten self-hosted, dosya tabanlı bir platform sunar.