Buzz’da kayıtlı karar ile yetkili karar arasındaki fark

Bir hata düzeltmesi tamamlandığında ekip genellikle şu cümleyi duyar: “İnceleme yapıldı, üretime alabiliriz.” Fakat bu cümlenin gerisinde birbirinden ayrı üç soru vardır. İncelemeyi kim yaptı? Hangi değişikliği gördü? Üretime alma kararını verme yetkisi var mıydı? Sohbet kaydı ilk iki soruyu yanıtlayabilir; üçüncüsü için organizasyonun açık bir kuralına ihtiyaç vardır.

Buzz, Block tarafından geliştirilen açık kaynak bir çalışma alanı. İnsanlar ve ajanlar aynı kanallarda, aynı iş akışlarında ve aynı proje geçmişinde yer alabiliyor. Temeli bir Nostr relay’i: mesajlar, inceleme onayları, iş akışı adımları ve Git olayları imzalı olaylar olarak tutuluyor. Masaüstü istemcisi, ajan odaklı komut satırı aracı ve Goose, Codex, Claude Code gibi ajan çalışma ortamları için ACP köprüsü var. Buzz’ı bir model ya da tek başına bütün işleri yapan bir ajan sanmamak gerek. Bu altyapı, birlikte çalışmayı ve o çalışmanın kaydını düzenliyor.

Önceki Buzz yazılarında ortak çalışma alanını ve ajan kimliğinin taşınabilirliğini ele almıştık. Bu kez daha gündelik bir ayrımı açalım: Bir kararın kayda geçmiş olması ile doğru kişi tarafından verilmiş olması aynı şey değil.

İmza neyi gösterir?

Bir ajan kanalda inceleme yorumu yazdığında, Buzz bu olayı kendi kimliğiyle ilişkilendirir. Bir insan bir iş akışı adımına tepki verdiğinde veya Git değişikliğine dair görüş belirttiğinde aynı olay modeli devrededir. Böylece sonradan “Bu görüş nereden çıktı?” sorusunu yanıtlamak kolaylaşır. Bir konuşmayı ayrı bir sohbet aracında, ilgili yamayı ayrı bir depoda ve onayı da bir eposta zincirinde aramak yerine ilişkili olaylara aynı çalışma alanından ulaşabilirsiniz.

Yine de imza yalnızca olayın belirli bir anahtar tarafından üretildiğine dair kanıttır. İmzalanmış bir “uygundur” mesajı, değişikliğin test edildiğini ya da o anahtarın üretim ortamında karar verme yetkisine sahip olduğunu tek başına kanıtlamaz. Bir inceleme yorumu, incelemeyi yapanın hangi dosyalara baktığını da kendiliğinden söylemez. Kullanışlı bir kayıt için değişiklik kimliği, test sonucu ve kararın kapsamı ayrıca yazılmalıdır.

Buzz belgeleri kanalları, denetim günlüğünü, Git olaylarını ve YAML iş akışlarını bugün çalışan özellikler arasında sayıyor. Buna karşılık iş akışı onay kapılarının henüz bağlanma aşamasında olduğunu da açıkça belirtiyor. Dolayısıyla “Buzz’da onay verdik” ifadesini otomatik olarak çalışan, zorunlu bir dağıtım engeli varmış gibi okumamak gerekir. Aracın gösterdiği olay ile sistemin gerçekten engellediği işlem farklı şeylerdir.

Küçük bir yayın senaryosu

Bir ekip, müşteri panelindeki hesaplama hatasını düzeltiyor olsun. Geliştirici ajan bir yama hazırlıyor; ikinci ajan inceleme yapıp kenar durumda eksik bir test olduğunu söylüyor. İnsan geliştirici testi ekliyor. Ürün sorumlusu kanaldaki açıklamayı okuyup düzeltmenin kullanıcı davranışı açısından doğru olduğunu belirtiyor. Dağıtımı yapacak kişi ise testlerin hangi commit üzerinde çalıştığını görmek istiyor.

Bu akışta herkes aynı başlıkta konuşsa bile kararlar birbirinden ayrılmalı. İnceleme ajanı kodun belirli bir yönünü değerlendirmiştir; ürün sorumlusu davranış beklentisini onaylamıştır; dağıtım sorumlusu ise üretime çıkış koşullarını kontrol edecektir. Birinin “tamam” demesi diğer iki kararın yerine geçmez. Hatta aynı kişinin birden fazla şapka taşıdığı küçük bir ekipte bile, hangi şapkayla konuştuğunu belirtmek sonradan yanlış anlamayı azaltır.

Buzz’ın ortak olay modeli burada işe yarar. Yamanın ve konuşmanın aynı bağlamda görülmesi, “Hangi düzeltmeden söz ediyoruz?” karmaşasını azaltır. Fakat üretime alma kapısı yalnızca konuşmanın düzenli olmasına dayanamaz. Dağıtım hattında test ve yetkili insan onayı ayrı koşullar olarak uygulanmıyorsa, imzalı bir sohbet kaydı riskli bir geçişi durdurmaz. Yazılı karar, teknik kontrol ve yetki denetimi birbirini tamamlar; biri ötekinin yerine konmamalıdır.

Kanal üyeliği ile rol yetkisi

Buzz’ın yaklaşımında ajanların kendi anahtarları ve kanal üyelikleri var. Bir ajanı ilgili kanala eklemek, işe gereken bağlamı paylaşmanın makul bir yolu. Aynı zamanda erişimi sınırlandırmanın başlangıç noktası. Her ajanın her konuşmayı görmesi gerekmiyor; özellikle kişisel veri veya üretim sırrı içeren odalarda kapsam dar tutulmalı.

Ama kanala üye olmak, her işlemi yapabilmek anlamına gelmemeli. Hata ayıklamak için kaynak koda erişen bir ajan, müşteri verisini dışarı aktarma ya da canlı ortamda dağıtım yapma yetkisini otomatik almamalı. Bu ayrım yalnızca kanaldaki bir not olarak kalırsa kırılgandır. Gerçek erişim kontrolleri, ajanı çalıştıran ortamın ve bağlandığı servislerin izinlerinde de uygulanmalıdır. Projeyi açan, yamayı gönderen ve dağıtımı onaylayan rolleri farklı kişiler veya hesaplar üstlenebilir.

Bu noktada iki kayıt türünü ayırmak yararlı: olay kaydı ve yetki tanımı. Olay kaydı geriye dönük olarak ne olduğunu anlatır. Yetki tanımı ise olay gerçekleşmeden önce neyin yapılabileceğini söyler. Güvenilir bir iş akışında ikisi birlikte güncel tutulur. Yetki değişmiş ama eski açıklama kanalda kalmışsa, imzalı geçmiş bile bugünkü sınırı anlatmaya yetmez.

İlk uygulamada neyi ölçmeli?

Tüm iş akışlarını bir kerede Buzz’a taşımak yerine, düşük riskli bir değişiklik seçilebilir. Önce kararın nesnesini belirlemek gerekir: örneğin tek bir yama ve ona bağlı test sonucu. Ardından her katılımcının görevini kısa biçimde yazmak işe yarar. Ajan kod önerir; başka biri inceler; sorumlu insan karar verir; dağıtım hattı önceden belirlenmiş koşulları uygular. Olayların gerçekten aynı değişikliğe bağlanıp bağlanmadığına ve yetkisiz bir onayın süreci durdurup durdurmadığına bakılır.

Bu deneme sırasında yalnızca güzel görünen bir kanal geçmişini değil, olumsuz durumu da sınamak gerekir. İnceleme eksikse ne olur? Test başarısızsa kim durdurur? Sorumlu insan izinliyse yerine kim bakar? Bugün Buzz’ın kaydettiği bilgi ile henüz otomatik uygulamadığı onay mekanizmasını ayırmak, çözüm tasarımını daha dürüst kılar. Henüz çalışmayan bir özelliğin var olduğunu varsaymak yerine gerekli kontrolü mevcut dağıtım araçlarında tutmak mümkündür.

Buzz, insanların ve ajanların aynı çalışma geçmişini paylaşmasını sağlayarak bir kararın dayanağını görünür kılar. Ama kararın kime ait olduğunu ve hangi yetkiye dayandığını ayrıca tanımlamak gerekir. Bu ikinci katman için agentic-organization, AI ajanlarını organizasyon şemasında birinci sınıf üye olarak yönetmeye yönelik self-hosted, dosya tabanlı bir platformdur.