AI Ajanları İçin Şirket İçi Bağlam Mimarisi

Wiki'ler, onboarding dökümanları, runbook'lar, "tek doğru kaynağı" projeleri. Otuz yıldır aynı şeyi deniyoruz ve hep aynı yerde ölüyor: kimse okumuyor.

Confluence'ta güzel bir sayfa vardır, kimse açmaz. Yeni gelen yine yan masadaki adama sorar. Döküman altı ay sonra yalan söylemeye başlar, kimse fark etmez, zaten kimse bakmıyordur.

Bu denklemde bir şey değişti: artık okuyan biri var.

Agent, sen "şuna bak" demeden bakıyor. Yazdığın policy'yi gerçekten uyguluyor, verdiğin kaynak sırasını gerçekten takip ediyor, beğenmediğin cümleyi bir daha kurmuyor. Dökümantasyonun asıl problemi yazma maliyeti değildi, okunmama maliyetiydi. İlk kez o maliyet sıfırlandı.

Bu yazı o boşluğu neyle dolduracağını anlatıyor. Adına "company brain" diyorlar; ben ortak bağlam katmanı demeyi tercih ediyorum ama isim önemli değil.

Şirketin zekası şu an nerede duruyor

Satış lideri hangi itirazın anlaşmayı bitirdiğini anlatıyor. Pazarlamacı eski bir ürün iddiasını düzeltiyor. Kurucu aynı cümleyi beşinci kez yeniden yazıyor.

Hiçbiri o sohbetin dışına çıkmıyor. Herkes hızlanıyor, orası doğru — ama herkes şirketin biraz farklı bir sürümüyle çalışıyor. Bir agent eski kampanyayı güncel sanıyor, bir başkası kimsenin onaylamadığı bir tercihi takip ediyor.

Şirket her yerde öğreniyor, hiçbir yerde hatırlamıyor.

Tek bir işle başla

Başta tüm şirketi sisteme sokmaya çalışma. Ekibin anlatmaktan yorulduğu işi seç.

Şunlara bak:

• ekip bunu sık yapıyor
• "iyi" neye benzediğini biliyor
• sonucu hızlı gözden geçirebiliyor

Sonra şunu sor: bu işi gerçekten iyi yapan biri neyi biliyor, neye göre karar veriyor, ne yapıyor?

İçerik brief'i örneğinde cevap aşağı yukarı şu: güncel konumlandırma, onaylı iddialar, hedef kitlenin dertleri, ses tonu, birkaç iyi örnek ve çıktının formatı.

Süreci 4 Katman olarak ele al

Çoğu "şirket bilgi projesi" toplantı notlarını, eski kampanyaları, dökümanları bir yere yığıp üstüne bir arama kutusu koyuyor. Bu AI'ın eline daha çok bilgi verir ama daha iyi karar vermesini sağlamaz.

Asıl iş dördüncü katmanda. O olmazsa elinde sadece bir arşiv olur.

Agent'a önce harita ver

Her agent'ın açtığı ilk dosya küçük bir harita olsun. İçinde tüm şirket olmasın; nerede olduğunu, şu an neyin önemli olduğunu ve gerisi için nereye bakacağını söylemesi yeterli.

# Şirket haritası

## Ne yapıyoruz
[Şirket, müşteri, teklif ve konumlandırma — tek kısa paragraf.]

## Şu an ne önemli
1. [Öncelik 1]
2. [Öncelik 2]
3. [Öncelik 3]

## Kaynak sırası
1. [Güncel gerçeklerin sahibi olan sistem]
2. [Proje durumunun sahibi olan sistem]
3. [Müşteri taahhütlerinin sahibi olan sistem]

## Navigasyon
- decisions/   → ne karar verdik, neden
- people/      → sahiplik ve onay sınırları
- projects/    → devam eden iş ve durumu
- policies/    → her seferinde geçerli kurallar
- skills/      → kanıtlanmış yapma biçimleri
- workers/     → agent'ın çalıştırabileceği tekrar eden işler
- learnings.md → onaydan geçmiş düzeltmeler

## Kurallar
- En yeni onaylı bilgiyi kullan.
- İki kaynak çelişirse kaynak sırasına uy.
- Cevap yoksa neyi bulamadığını söyle.
- Tahmini asla şirket bilgisine dönüştürme.

İçerik agent'ı konumlandırmayla ses tonunu alır, müşteri agent'ı hesap geçmişiyle eskalasyon kurallarını, kod agent'ı mimari kararlarla güvenlik politikasını. Aynı beyin — herkes ihtiyacı olan odaya giriyor.

Şuna dikkat: context'i şişirmek her zaman işe yaramıyor. Eski bir kampanya güncel konumlandırmanın önüne geçebiliyor, gelişigüzel bir toplantı notu onaylı kararla karışabiliyor. Yani mesele daha çok bilgi yüklemek değil, agent'ın doğru yeri bulabilmesi.

Asıl mesele: düzeltmeyi nereye yazdığın

Agent iyi bir teklif yazdı ama geçen çeyreğin konumlandırmasını kullandı. Çoğumuz o cümleyi düzeltir, teklifi gönderir, işine devam eder. Teklif düzeldi ama sistem aynı kaldı — aynı hata yarın yine çıkacak.

Sorulması gereken şu: o eski konumlandırma neden hâlâ oradaydı? Brief mi güncellenmemişti, yeni karar hiç yazılmamış mıydı, yoksa eski kampanya metni onaylı dilin önüne mi geçiyor?

Her düzeltmeyi doğru katmana yönlendir:

Döngü: iş → düzeltme → yönlendir → review → paylaş → daha iyi iş

Review'ı atlama. Kontrolden geçmemiş bir "öğrenme" yanlışsa, o yanlışı da herkese yaymış olursun.

Bunun tek bir evi olmalı

Klasör yapısı tek kişiyken gayet iyi çalışıyor. İkinci kişi girince biri policy'yi güncelliyor, öbürü eski sürümle çalışıyor; işe yarayan bir skill birinin laptop'ında kalıyor. Üstüne Claude Code, Cursor ve Codex'i de ekle — tek beyin yeniden beş kişisel beyne bölünüyor.

O yüzden bu katmanın tek bir evi olması lazım. Herkes istediği aracı kullanmaya devam etsin ama ortak bilgi tek yerde dursun, değişiklikler oraya gözden geçirilerek girsin.

Bunun için ürün almana gerek yok. Paylaşılan bir repo, pull request akışı ve her araçtan o repoya bakan bir link işi görüyor. Önemli olan tek kaynak ve gözden geçirme adımının olması; nerede durduğu ikinci mesele.

Salı günü bir kişi bir şey çözer. Çarşamba günü tüm ekip onun üstünden başlar.

Bu sistemler nerede ölür

Bu tür yazıların çoğu tam burada susuyor, halbuki asıl risk burada. Hiçbir bilgi tabanı bilgi eksikliğinden ölmüyor — bakım maliyetinden ölüyor.

Dikkat edilecek dört şey:

• Sahipsiz dosya üç ay sonra yalan söyler. Her klasörün bir sahibi olsun; sahibi yoksa o klasörü hiç açma.
• Eklemek kadar silmek de işin parçası. Yeni karar eskisini geçersiz kılıyorsa eskisini sil ya da açıkça işaretle. İki geçerli cevabın olması, hiç cevabın olmamasından kötü.
• Şişen dosya işe yaramaz. learnings.md 400 satıra çıktığında ne insan okur ne de agent'ın işine yarar; sadece context'i doldurur. Belli aralıklarla içindekileri policy'ye veya skill'e terfi ettir, gerisini at.
• Ölçü basit: son 60 günde ne okunmuş ne güncellenmiş bir dosya, sistemin parçası değil, yükü.

Bu işin görünmeyen maliyeti bu. Sürdüremeyeceksen hiç başlama; yarım kurulmuş bir sistem, hiç kurulmamıştan daha çok hataya sebep oluyor.

İlk 60 dakika

• [ ] Ekibin anlatmaktan yorulduğu bir workflow'u seç
• [ ] O workflow için minimum bilgi listesini çıkar (fazlasını değil)
• [ ] company-map.md haritasını yaz, boşlukları doldur
• [ ] Girdisi, adımları, çıktısı ve durma koşulu belli tek bir worker tanımla
• [ ] Yukarıdaki düzeltme yönlendirme tablosunu kopyala
• [ ] Gerçek bir işte çalıştır — nerede takılıyor, nerede uyduruyorsa eksik orası
• [ ] Sürdüremeyeceğin her klasörü boş bırak

Haftalık bir hatayı ortadan kaldıran küçük bir yapı, kimsenin açmadığı düzgün bir arşivden iyidir.

Kaynak ve bir not

Bu yazının çıkış noktası J.B.'nin bir yazısıydı. Dört katman ayrımı ve düzeltmeyi katmana yönlendirme fikri oradan geliyor; iyi fikirler, hakkını vermek lazım.

İki şeyi de açık söyleyeyim. O yazı kendi ürününe çıkıyor, yani problem tanımı bir ölçüde ürüne göre şekillenmiş. Ve içinde tek bir ölçüm yok: ne önce/sonra, ne vaka, ne bir başarısızlık hikayesi.

Benim de elimde sayı yok, o yüzden vermiyorum. Burada okuduğunuz bir çerçeve, deney raporu değil. Gerçek testi tek bir workflow'da kendiniz çalıştırınca çıkıyor, zaten önerim de o.