Ajanlarıma Proje Hafızasını Okutmayı Bıraktım: Artık Bunu Sunucu Yapıyor

Paralel çalışan 9 Claude Code oturumuyla ilgili deneyimlerimin devamı niteliğindeki bu yazıda, asıl darboğazın modelin zekâsı değil hafıza olduğunu anlatmıştım. Bu makale ise devreye aldığım çözümü ve modelleri "yönlendirmek" (prompting) konusunda bana öğrettiği rahatsız edici dersi ele alıyor.

Kurulum (The Setup)

İsviçre merkezli bir iş platformunu, çeşitli web sitelerini ve altyapılarını yaklaşık 9 Claude Code oturumunu paralel çalıştıran bir kokpitle yönetiyorum. Her oturum bağımsız bir görevi temsil ediyor; panoda sürüklenen bir kanban kartı doğrudan çalışan bir ajana dönüşüyor.

Karşılaştığım tekrarlayan başarısızlık hiçbir zaman zekâ eksikliği değildi; tamamen hafıza kaybıydı (amnezi). Örneğin 7 numaralı oturum, haftalar önce standardize ettiğimiz bir hata formatını kolaylıkla sıfırdan yeniden yazabiliyordu; çünkü hiçbir şey ona bu kararın varlığını bildirmemişti. Oysa karar bir Markdown notunda, proje hafızasında mevcuttu; fakat ajan oraya asla bakmıyordu.

v1: Kibarca İstedim

İlk çözümüm en belirgin olanıydı. Bir oturum başlatıldığında ilk istemin sonuna şu talimatı ekledim:

{Görev tanımı}
İlgili proje bağlamını yüklemek için memory_search aracını çağırarak başla.
Bir plan öner ve benim onayım olmadan hiçbir şeyi çalıştırma.

Çoğu "ajan hafızası" kurgusu tam olarak bunu yapar: bir sistem prompt'u, bir araç ve modelin bunları kullanacağına duyulan güven. Bu yöntem çoğunlukla işe yarar. Ancak paralel 9 oturumunuz olduğunda "çoğunlukla", 9 oturumdan birinin talimatı görmezden gelmesi demektir. Bu da sessiz ve kaçınılmaz bir hata üreticisidir. Model hafızayı atladığını söylemez; koda dalar, yerel olarak makul görüneni yapar ve standartları çiğner. Talimatı daha ısrarcı kılmaya çalıştım (daha sert ifadeler, en sona yerleştirme, yalvaran araç açıklamaları). İşte o an fark ettim: Deterministik olmayan bir süreci daha sert rica ederek güvenilir kılamazsınız. Yanlış katmandaydım.

v2: İstemeyi Bıraktım

Hafızayı geri çağırma işi prompt'a değil, mimari tesisata (plumbing) aittir. Artık bir oturum açıldığında, model tek bir adım dahi atmadan önce sunucu semantik aramayı deterministik olarak yürütüyor ve sonuçları doğrudan ilk mesaja enjekte ediyor (_memory_preseed):

Modelin aldığı görev artık şu şekilde görünüyor:

Fix the healthcheck flapping on staging.
=== Project memory (auto-recalled) ===
- ★ [staging-stack] Staging API 6443 portundadır, dağıtımlar "callisto" ana makinesine yapılır.
- [deploy-ritual] Dağıtımlar yalnızca make ship-v2 üzerinden yapılır, asla ham rsync kullanılmaz.

Modelin bu bağlamı görmezden gelme şansı artık yok; bu opsiyonel bir araç değil, okuduğu ilk token'lardır. Eski yöntem ise hafızanın boş olduğu durumlar için yedek plan (fallback) olarak korunmaktadır.

Pratik Çıkarımlar

Deterministik Ön Yükleme: Kritik proje kurallarını modelin araç çağırma inisiyatifine bırakmayın; sunucu tarafında deterministik olarak bağlama enjekte edin.
Doğru Katmanda Mühendislik: Modelden istemek yerine altyapıyı sağlam kurun. Güvenilirlik prompt mühendisliğiyle değil, doğru mimari katmanla sağlanır.

[Orijinal kaynağa buradan ulaşabilirsiniz.](https://dev.to/nicolas_micaud_20671fb4f2/i-stopped-asking-my-ai-agents-to-read-the-project-memory-now-the-server-does-it-for-them-238n)

Bu konuyu derinlemesine öğrenmek isterseniz: Production'da Agent Güvenilirliği modülüne göz atın.