"Prompt mühendisi" hiçbir zaman net bir iş unvanı olmadı, ama bir süre buna gerek de yoktu. Tüm işiniz tek bir çıkarım çağrısından tek bir iyi yanıt almaktan ibaretse, tek bir beceri seti bu işi görüyordu: talimatı iyi ifade et, birkaç örnek ver, belki biraz alınmış metin ekle, tamam. Bu beceri seti hâlâ önemini koruyor. Ama artık 2026 ortasında "bir ajan inşa etmek"in ne anlama geldiğini kapsamıyor ve bu boşluk kendini belirli, tanınabilir bir hata türü olarak gösteriyor: bir demoda harika çalışan ama sonra sessizce bozulan, kendisiyle çelişen ya da kullanıcının iki oturum önce söylediklerini unutan ajanlar.

Machine Learning Mastery'den yakın tarihli bir yazı bu boşluğu doğrudan adlandırıyor ve üzerinde durmaya değer, çünkü gerçekten işe alınabileceğiniz iki farklı işe net biçimde denk düşüyor. Bağlam mühendisliği, tek bir çıkarım çağrısı içinde olup bitenlerdir: bağlam penceresine neyin gireceğine, yapısal olarak nereye gireceğine ve modelin ilgisiz token'lara boğulmaması için nelerin sıkıştırılıp nelerin atılacağına karar vermek. Bellek mühendisliği ise sadece çağrılar arasında var olan farklı bir problemdir: bir oturum bittikten sonra nelerin kaydedileceği, nerede saklanacağı, bir sonraki sefer nasıl geri getirileceği ve çürümemesi için (güncellenerek, tekrarları ayıklanarak, süresi doldurularak) nasıl bakımının yapılacağı. O yazıya göre, uzun, çok oturumlu ajan iş akışlarında ortaya çıkan hatalar çoğunlukla bu iki işi birbirine karıştırmaya ya da ikisinden birini atlamaya kadar izlenebiliyor — özellikle de "retrieval boundary" (geri getirme sınırı) dedikleri şeyde: bir ajanın ihtiyaç duyduğu bir şeyin önünde mi durduğuna yoksa depodan mı getirilmesi gerektiğine karar vermek zorunda kaldığı an.

Bunları birbirine karıştırmak neden bir ayrıntı değil, asıl hatanın kendisi

Her bir disiplinin neyi optimize ettiğini düşünün. Bağlam mühendisliği, tek, sınırlı ve tek kullanımlık bir pencereyi optimize eder — doğru bilgi dilimini şu an, bu tek alışveriş için modelin önüne koy, sonra gerisini at. Bellek mühendisliği ise oturumlar arasında hayatta kalması, yeni bilgi geldikçe tutarlı kalması gereken kalıcı bir depoyu optimize eder ve çok daha zor bir soruyu yanıtlar: "bu prompt için ne alakalı" değil, "genel olarak neyin saklanmaya değer olduğu ve ne kadar süreyle."

Bunlar farklı hata türlerine sahip farklı tasarım problemleridir. Bir bağlam mühendisliği hatası tek bir yanıtı kötüleştirir. Bir bellek mühendisliği hatası ise katlanarak büyür — kötü yazımlar birikir, güncelliğini yitirmiş bilgiler sanki güncelmiş gibi geri getirilir ve ajan üç oturum önce düzeltilmiş bir şeyi kendinden emin biçimde tekrarlayana kadar kimse fark etmez. Eğer tek bir kişi (ya da tek bir prompt şablonu) bu iki işi ayırt etmeden sessizce yürütüyorsa, bellek katmanı sahip olmaması gereken bağlam mühendisliği alışkanlıklarını devralma eğilimindedir: bir pencereyi aşırı doldurur gibi depoyu aşırı doldurmak, ya da geri getirmeyi aslında bir küratörlük-ve-bakım problemiyken bir alaka-sıralama problemiymiş gibi ele almak. Araştırma özetinin işaret ettiği karıştırma tam olarak budur ve bu, uygulayıcıların zaten anekdot olarak anlattığı bir şeyle örtüşür: tek bir oturumda etkileyici olan ama beşinci oturuma gelindiğinde güvenilmez hâle gelen ajanlar.

Her iş günlük hayatta gerçekte neye benziyor

Bunlardan hangisini zaten yaptığınızı ya da hangisine doğru ilerlemek istediğinizi anlamaya çalışıyorsanız, günlük iş, ikisini birbirinden ayırt edebilecek kadar farklı görünüyor:

Pratikte bağlam mühendisliği: mevcut bilginin (dokümanlar, araç çıktıları, önceki turlar) hangi alt kümesinin gerçekten bu çağrıya ait olduğuna karar vermek; konumun modellerin bilgiyi nasıl ağırlıklandırdığını etkilemesi nedeniyle promptun neresine gireceğini seçmek; uzun bir araç izinin tüm bütçeyi yiyip bitirmemesi için sıkıştırma ya da özetleme adımları yazmak; ve bunu göreve göre ayarlamak, çünkü bir hata ayıklama ajanı ile bir yazma ajanı, aynı temel modelde bile farklı bağlam biçimleri ister.

Pratikte bellek mühendisliği: bir yazma politikası tanımlamak (bir oturumdan sonra neyin kalıcı hale getirilmeye değer olduğu — her şey değil); bir depolama katmanı seçmek (bir vektör deposu, yapılandırılmış bir veritabanı, düz dosyalar, bir hibrit) ve her birinin ödünleşimleri konusunda dürüst olmak; neyin ne zaman geri getirileceğine karar veren geri getirme stratejisini kurmak; ve sürekli bakım yapmak — budama, yinelenen bilgileri birleştirme, kullanıcı fikrini değiştirdiğinde çelişkileri ele alma. Bakım denen o son kısım, insanların en sık atladığı kısımdır, çünkü bir ajan haftalarca çalışana kadar görünür olmaz.

Sektörün bu kaygıları yalnızca kavramsal olarak değil, yapısal olarak da ayırmaya başladığını görebilirsiniz. Lenny's Newsletter'ın Claude Agent SDK üzerinde bir hata ayıklama iskeleti inşa etme anlatısı, izinleri, araç bağdaştırıcılarını ve çevredeki "harness"i, içindeki promptlamadan ayrı kendi mühendislik yüzeyleri olarak ele alıyor — aynı içgüdü, farklı bir eklem noktasına uygulanmış. Google'ın daha yeni Gemini API "Managed Agents" özellikleri de — arka planda yürütme, etkileşimler arasında kimlik bilgisi yenileme — platform sağlayıcısının, oturum boyunca kalıcı durumun artık tasarlanması gereken bir altyapı olduğunu, yeterince uzun bir bağlam penceresinin yan etkisi olmadığını fiilen kabul etmesidir. Birilerinin bu tasarımın sahibi olması gerekir. Şu anda birçok ekipte bunu açıkça üstlenen kimse yok.

Bunun sadece kodunuz için değil, iş unvanınız için de neden önemli olduğu

Kariyerinizin erken ya da orta aşamasındaysanız ve özgeçmişinizde "prompt mühendisi" ya da "AI mühendisi" yazıyorsa, bu iki işten hangisini yaptığınıza dair gerçekten kanıt gösterebileceğinizi sormaya değer — çünkü genel amaçlı AI-ajan rolleri, tıpkı "webmaster"ın zamanla frontend, backend ve DevOps'a bölünmesi gibi, daha spesifik rollere ayrılmaya başlıyor. Bu bir başlık değil, bir ihtiyati kayıt: "bellek mühendisi"ni bağımsız bir unvan olarak doğrulayan sağlam işe alım verisi henüz görmedim, bu yüzden bunu işin nereye doğru gittiğine dair bir okuma olarak ele alın, iş ilanlarının şimdiden bu şekilde sınıflandığına dair bir iddia olarak değil. Ama altta yatan baskı gerçek ve yukarıdaki özete kadar izlenebilir: ajan ekipleri, belirli ve adlandırılabilir bir nedeni (iki disiplini birbirine karıştırma) olan belirli ve adlandırılabilir bir hatayla (çok oturumlu bozulma) karşılaşıyor ve bu kombinasyon genellikle bulanık bir rolü iki keskin role dönüştüren şeydir.

Pratik hamle kendinize bir unvan uydurmak değildir. Gerçekte hangi problemi çözdüğünüzü somut olarak yanıtlayabilmektir. Bir yazma politikası tasarladığınız bir şey hayata geçirdiniz mi — bir ajanın belleğe neyi kaydedeceğine ve neyi atacağına dair bir kural? Bir ajanın depodan bir şeye ihtiyaç duyduğu ama ya onu getirmediği ya da yanlış sürümünü getirdiği bir geri getirme-sınırı hatasını hata ayıkladınız mı? Bunlar bir mülakatta, bir repo ya da bir olay-sonrası analiziyle desteklenerek yapabileceğiniz kontrol edilebilir iddialardır ve genel bir "iyi promptlar yazarım" ifadesinin söylemediği bir şeyi söylerler: tek bir yanıtı iyileştirmek ile bir ajanı zaman içinde güvenilir kılmak arasındaki farkı anladığınızı.

Bir uyarı

Bir projeye bir kez vektör veritabanı eklemiş olmanın gücüyle kendinizi "bellek mühendisi" olarak yeniden etiketlemeyin. Araştırmanın işaret ettiği disiplin, o pek de gösterişli olmayan yarıyı da içerir — bakım, süre dolumu, çelişki yönetimi — ve yukarıda tarif edilen hata türünü asıl önleyen kısım da budur. Portföy çalışmanız belleğe yazan ama hiçbir şeyin budanmadığı ya da düzeltilmediği bir sistemse, bir bellek mühendisinin işinin yalnızca yarısını inşa etmişsiniz demektir ve üçüncü-oturumdan-sonra-bozulma problemi diğer yarıda sizi beklemeye devam ediyor.