**
Yapay zeka topluluğunda yaygın olarak dolaşan bir mimari fikir, birçok ekibi yanlış yola sürüklüyor.
Önce Sonuç
Eğer birden fazla Yapay Zeka Ajanını "Ürün Yöneticisi", "Mimar" ve "Test Mühendisi" olarak adlandırıp, şirket departmanları gibi belgeler aktararak iş birliği yapmalarını düşünüyorsanız—lütfen durun.
Bu model sezgisel ve mantıksal olarak sağlam görünse de, mühendislik açısından temel kusurlara sahiptir. Daha da önemlisi, üç büyük sağlayıcı—Anthropic, OpenAI ve Google—kendi Ajan sistemlerini oluştururken bu modeli kullanmamaktadır.
Bu bir tesadüf değil.
"Üç Departman ve Altı Bakanlık" Mimarisi Nedir?
Bu metafor, toplulukta yaygın olarak bilinen ve çeşitli framework'lerde ve makalelerde farklı isimlerle anılan bir çoklu-ajan tasarım fikrini ifade eder: role dayalı ajanlar, sanal ekipler, CrewAI tarzı iş bölümü veya MetaGPT tarzı organizasyon. Bu makale, bunları topluca "Departmanlaştırılmış" model olarak adlandırmaktadır.
Temel desen şudur: karmaşık bir görevi birkaç fonksiyona ayırın ve her Ajan bir rol oynasın—PM gereksinimler için, Teknik Lider mimari için, Geliştirici uygulama için ve QA test için. Görevler, bir montaj hattı gibi Ajanlar arasında akar.
Bu model bir diyagram üzerinde harika görünür. "İş bölümü" konusundaki insan sezgisini tatmin eder ve "yapay zeka ekibi" kavramını somut ve açıklanabilir kılar. CrewAI gibi framework'ler bu nedenle birçok kullanıcı biriktirmiştir.
Sorun şu ki, insan darboğazlarını çözer, yapay zeka darboğazlarını değil.
Bu Benzetme Neden Temelde Yanlış?
İnsanların iş bölümüne ihtiyacı vardır çünkü:
- Tek bir kişinin dikkati sınırlıdır ve tüm bilgileri aynı anda işleyemez.
- İnsanların mesleki engelleri ve yüksek öğrenme/değiştirme maliyetleri vardır.
- İnsanların birbirleriyle koordinasyon için arayüzlere ihtiyacı vardır.
Ancak LLM özellikleri tamamen farklıdır:
- Aynı model hem PRD'ler hem de kod yazabilir; "mesleki sınırlar" yoktur.
- Modeller için darboğaz dikkat süresi değil, akıl yürütme derinliği ve bilgi bütünlüğüdür.
- Modeller, bilgi kaybını telafi edecek "kültür" ve "örtük anlayıştan" yoksundur.
Bir Ajana "Ürün Yöneticisi" etiketi vermek onu daha profesyonel yapmaz—onu sınırları aşmayı reddeden hale getirir. "Test Mühendisi" rolüne sıkıştırılmış bir Ajan, "bu benim kapsamımda değil" diyerek mimari bir sorunu atlayabilir. En değerli akıl yürütme genellikle sınırlarda gerçekleşir ve Departmanlaştırılmış model, bu olasılığı sistem düzeyinde kapatır.
Rol yapmak sahte sınırlar yaratır. Bu ilk sorun.
İkinci Sorun: Bilgi Aktarımda Ölür
Departmanlaştırılmış modelde, Ajan A bir belge üretir ve onu Ajan B'ye iletir.
Bu süreç sonuçları iletir, akıl yürütme sürecini değil.
B belgeyi alır, yeniden anlar ve bağlamı yeniden oluşturur. Orijinal niyet bozulur, gizli varsayımlar kaybolur ve her teslim hata biriktirir. İş akışı ne kadar uzun olursa, nihai çıktı o kadar "yerel olarak doğru ama küresel olarak sapmış" hale gelir—her düğüm makul görünür, ancak bütün orijinal hedeften sapmıştır.
İnsan organizasyonları bu bilgi kaybını telafi etmek için toplantılara, kültüre ve resmi olmayan iletişime güvenir. Ajanlar bu mekanizmalara sahip değildir.
Yaygın bir itiraz vardır: Üç büyük sağlayıcının çözümleri (progress.txt, spec dosyaları, runbook'lar) da "dosya aktarmak" değil mi? Fark ne?
Fark, kimin yazdığı, kimin için olduğu ve nasıl güncellendiğidir.
Departmanlaştırılmış bilgi akışı, roller arasında tek yönlü bir teslimdir: A bitirir ve B'ye verir; B geriye bakmaz ve A, B'nin belgeyi nasıl kullandığını bilmez. Bilgi sonuçlara sıkıştırılır, akıl yürütme süreci kaybolur ve teslim bir kırılma noktasıdır.
Harici durum dosyaları, aynı görevin artımlı günlükleridir: Yürüten varlık, her kontrol noktasında aynı kayda ekleme yapar ve bir sonraki oturum, önceki bir "meslektaşın" çıktı sonucunu değil, görevin tam geçmişini okur. Durumu yazan kişi ile durumu okuyan kişi aynı roldür, sadece farklı zamanlarda. Bilgi "sıkıştırılıp iletilmez"; "sürekli olarak biriktirilir."
Bu fark, akıl yürütme zincirinin oturumlar arasında sürekli kalıp kalamayacağını belirler.
Çok sayıda token, gerçek akıl yürütme yerine Ajanlar arasındaki "teslim dosyalarına" harcanır. Şirket davranışını simüle eden bir sistem elde edersiniz, sorunları çözen bir sistem değil.
Üç Büyük Sağlayıcı Bunu Gerçekte Nasıl Yapıyor?
Anthropic, OpenAI ve Google, üretim kalitesinde Ajan sistemlerini oluştururken, mühendislik belgelerinde neredeyse hiç "rol yapma" veya "departman bölümü"nden bahsetmemeleri dikkat çekicidir.
Anthropic: Bağlam Mühendisliği + Açık Durum Dosyaları
Anthropic, "Prompt Mühendisliği"ni "Bağlam Mühendisliği"ne yükseltmiştir: Sorun iyi bir prompt'un nasıl yazılacağı değil, hangi token yapılandırmasının istenen davranışı en iyi şekilde ürettiğidir.
Claude Code ve Araştırma sistemlerini oluştururken temel zorlukları şuydu: Ajanlar ayrı oturumlarda çalışmalıdır ve her yeni oturumun daha önce olanlarla ilgili hafızası yoktur. Metaforları "vardiya mühendisleri"dir—her yeni vardiya mühendisi, önceki vardiyanın çalışması hakkında hiçbir şey bilmez.
Çözüm, Ajanların farklı roller oynaması değil, şudur:
- claude-progress.txt: Oturumlar arası bir çalışma günlüğü, Ajan her oturumun sonunda günceller ve bir sonrakinin başında okur.
- Git geçmişi: Durum çapaları olarak hizmet eder, her artımlı değişikliği kaydeder.
- Başlatıcı Ajan: Yalnızca ilk oturumda çalışır, ortamı kurar, özellik listesini genişletir ve sonraki tüm oturumlar için runbook'u yazar.
Anahtar içgörü: Akıl yürütme zincirinin sürekliliği, modelin "hatırlamasına" değil, onu sabitlemek için açık harici duruma dayanır.
Ayrıca, "model yetenek varsayımlarını" koşum takımına sabit kodlamanın tehlikeli olduğunu buldular. Sonnet 4.5'te "bağlam kaygısı" vardı—bağlam sınırına yaklaştığında erken toparlanıyordu, bu yüzden koşum takımına bir bağlam sıfırlama eklediler. Ancak Opus 4.5'te bu davranış kayboldu ve sıfırlama ölü ağırlık haline geldi. Bu, koşum takımının modelle birlikte gelişmesi gerektiğini gösterir; herhangi bir "kalıcı çözüm", yalnızca mevcut aşama için bir mühendislik uzlaşmasıdır.
Çoklu-ajan Araştırma sistemlerinde, Anthropic'in mimarisi orkestratör-işçidir: bir lider ajan görevleri parçalara ayırır ve alt ajanları koordine eder, bunlar farklı yönleri paralel olarak keşfeder ve sonuçlar sentez için lider ajana geri akar. Token tüketiminin tek başına performans farklılıklarının %80'ini açıkladığını buldular—çoklu-ajanların değeri "iş bölümü" değil, daha büyük bir arama alanını kapsamak için daha fazla token kullanmaktır.
Burada bir kafa karışıklığı noktası var: Anthropic'in alt ajanları "iş bölümü" gibi görünebilir, ancak öz farklıdır. Departmanlaştırma, işlevsel bölümdür—farklı roller farklı iş türlerini halleder (PM'den Geliştiriciye, QA'ya). Anthropic'in alt ajanları, işlevsel paralelliktir—birden fazla özdeş ajan aynı anda farklı yönleri araştırır, "sonraki teslim" yoktur ve tüm sonuçlar aynı orkestratöre geri döner. Birincisi bir bayrak yarışıdır; ikincisi geniş bir ağ atmaktır.
OpenAI: Sıkıştırma + Beceriler + Yapılandırılmış Spec Dosyaları
OpenAI'nin uzun vadeli görevler için ilkeleri daha da doğrudandır: görevin başında süreklilik için plan yapın.
Codex deneylerinde, mühendisler ajana bir spec dosyası verdi (hedefi dondurarak ajanın "etkileyici ama yanlış yönde" bir şey yapmasını önlemek için), kilometre taşı tabanlı bir plan oluşturmasını sağladı ve ardından ajana nasıl çalışacağını söylemek için bir runbook dosyası kullandı. Bu runbook aynı zamanda paylaşılan bir hafıza ve denetim günlüğüdür.
Sonuç: GPT-5.3-Codex yaklaşık 25 saat boyunca sürekli çalıştı, tüm süreç boyunca tutarlılığı koruyarak tam bir tasarım aracını tamamladı.
Sunucu tarafı sıkıştırma, acil durum yedeği değil, varsayılan bir temel işlem olarak hizmet eder. Çok adımlı görevlerde, previous_response_id, modelin her seferinde bağlamı yeniden oluşturmak yerine aynı iş parçacığında çalışmaya devam etmesini sağlar.
Ayrıca Beceriler kavramını tanıttılar—konteynerlere monte edilmiş, yeniden kullanılabilir, sürümlü talimat setleri, ajanlara belirli görevler için istikrarlı çalışma standartları verir. Bunlar "roller" değildir; bunlar araçlar ve çalışma prosedürleridir, ki bu temelde farklıdır.
Google: 1M Bağlam + Bağlam Odaklı Geliştirme
Google'ın yönü, pencereyi zorlamaktır: Gemini'nin 1M token bağlamı, açık bir farklılaşma stratejisidir. Mantıkları, daha önce zorunlu olan RAG dilimleme ve eski mesajları atma gibi tekniklerin, yeterince büyük bir pencere verildiğinde "hepsini koymak" ile değiştirilebileceğidir.
Ancak bunun bile yeterli olmadığını kabul ediyorlar. Google, Gemini CLI için Conductor uzantısını başlattı ve temel fikri Anthropic'inkiyle aynı: proje niyetini sohbet penceresinden çıkarıp kod tabanındaki kalıcı Markdown dosyalarına taşımak. Felsefe: "Kararsız sohbet geçmişine değil, resmi spec ve plan dosyalarına güvenin."
Gemini 3 ayrıca Düşünce İmzalarını tanıttı: uzun oturumlarda akıl yürütme zincirinin ana düğümlerini kaydederek "akıl yürütme kaymasını"—uzun bağlamlarda mantıksal tutarsızlık sorununu—önler.
Gerçek Mimari İlkeler Nelerdir?
Bu üç şirketin mühendislik uygulamalarından birkaç ortak ilke çıkarılabilir:
Akıl yürütme zinciri kırılamaz; yalnızca dallanabilir ve birleşebilir. Çoklu-ajanların doğru kullanımı bir montaj hattı değil, tam niyeti tutan bir ana ajandır, alt çağrılar alt sorunları derinlemesine incelemek için kullanılır ve sonuçlar bir sonraki ajana değil, ana ajana geri akar.
Açık harici durum, model hafızasına güvenmeyin. İster progress.txt, ister git geçmişi, spec dosyaları veya veritabanları olsun—biçim önemli değil. İlke şudur: akıl yürütme zincirinin ana düğümleri kalıcı depolamaya dışsallaştırılmalıdır.
Çoklu-ajanların değeri paralel kapsama alanıdır, iş bölümü değil. Anthropic'in Araştırma sistemi sonucu açıktır: performans kazanımları "daha fazla token harcamaktan" gelir, "daha iyi iş bölümünden" değil. Çoklu-ajanlar, genişlik öncelikli görevler için uygundur—bağımsız yönlerin eşzamanlı olarak keşfedilmesini gerektiren senaryolar. Sürekli akıl yürütme ve derin bağlam bağımlılığı gerektiren senaryolar için uygun değildirler.
Doğrulayıcı Ajan bir inkarcıdır, bir bayrak yarışçısı değil. Kalite kontrol için çoklu-ajanlar kullanılıyorsa, doğru tasarım, bir Ajanın diğerinin çalışmasında özellikle sorun bulmasıdır, "iş sonucunu devretmek" değil. Düşmanca test, montaj hattı transferi değil.
Araçlar araçtır, roller değil. Bir Ajanı hangi araçlarla donattığınız (bash, dosya G/Ç, arama, kod yürütme), ona hangi etiketi yapıştırdığınızdan çok daha önemlidir. Araçlar, bir Ajanın yapabileceklerini belirler; rol etiketleri yalnızca yapmaya istekli olduklarını sınırlar.
"Departmanlaştırılmış" Model Neden Popüler?
Çünkü açıklaması kolaydır.
"Bu Ajan PM, şu QA"—herkes bunu anlayabilir. Yapay zeka sistemi açıklanabilirliğine yönelik insan arzusunu ve yönetimin "yapay zekanın bir ekip gibi çalışması" hayalini tatmin eder.
Ayrıca göstermesi kolaydır. Departmanlar, oklar ve teslimlerle bir akış şeması olarak çizildiğinde çok sezgiseldir.
Ancak açıklaması ve göstermesi kolay olmak, mühendislik açısından sağlam olmaktan farklıdır.
Daha derin bir neden, bu modeli benimseyen çoğu ekibin "çoklu-ajan transferi sırasında bağlam kaybı" sorunuyla gerçekten yüzleşmemiş olmasıdır. Görevleri yeterince karmaşık olmayabilir veya sorun diğer faktörler tarafından maskeleniyor olabilir. Görev karmaşıklığı arttığında ve sistem "yerel olarak doğru ama küresel olarak yanlış" hatalar göstermeye başladığında, sorun ortaya çıkar.
Pratik Tavsiyeler
En iyi çoklu-ajan sistemi bir şirkete benzemez. Daha çok bir düşünürün birden fazla taslağına benzer—aynı beyin, akıl yürütmeyi farklı boyutlarda genişletir ve sonunda bunları tutarlı bir sonuçta birleştirir.
Bu ilkeye dayanarak:
"Kaç Ajana ihtiyacım var?" diye sormayın; "Bu görevin bilgi bağımlılığı yapısı nedir?" diye sorun.
Bir görev sürekli akıl yürütme ve yüksek bağlam bağımlılığı gerektiriyorsa (örneğin, karmaşık bir özellik için tasarım belgesi yazmak), tek bir Ajan + iyi bağlam mühendisliği genellikle çoklu-ajanlardan üstündür.
Bir görev, bağımsız yönlerin eşzamanlı olarak keşfedilmesini gerektiriyorsa (örneğin, 10 rakibi aynı anda araştırmak), çoklu-ajan paralelliği mantıklıdır—her alt ajanın görevi bağımsızdır ve bilgi kaybının maliyeti en aza indirilir.
Bir görev birden fazla oturuma yayılıyorsa, harici durum dosyaları zorunludur. Etkili bir durum dosyası dört tür bilgi içermelidir:
- Görev Hedefi (Değişmez, kaymayı önlemek için oturum başında okunur)
- Tamamlanan Adımlar (Eklenir, üzerine yazılmaz, tam geçmişi korumak için)
- Mevcut Durum (Üzerine yazılır, en son ilerlemeyi yansıtmak için)
- Bilinen Tuzaklar (Eklenir, bir sonraki oturumda hataları tekrarlamamak için)
Bu dört bilgi türü, ayrı ayrı tutulur ve birleştirilir, "sonraki ben" tarafından ihtiyaç duyulan tam bağlamı sağlar.
Bir doğrulama adımı ekleniyorsa, Doğrulayıcı Ajan'ın tek görevini sorun bulmak yapın, "bayrağı alıp devam etmek" değil. Düşmanca test, montaj hattı transferi değil.
Son olarak: Model yetenekleri hızla gelişiyor. Bugün koşum takımında ihtiyaç duyulan geçici çözümler, altı ay içinde ölü ağırlık haline gelebilir. Anthropic bunu zaten kanıtladı—Sonnet 4.5'in bağlam kaygısı Opus 4.5'te kayboldu. Mimari evrilebilirliği korumak, "mükemmel bir mimari" seçmekten daha önemlidir.
Departmanlaştırma, iyi hissettiren ancak mühendislik açısından pahalı bir yanılsamadır. Gerçek maliyeti doğrudan başarısızlık değil, sisteminizin karmaşıklık arttıkça teşhis edilmesi zor şekillerde bozulmasına neden olmasıdır—her düğüm "çalışıyor gibi görünür", ancak bütün kayar.
Sorunu bulduğunuzda, montaj hattı zaten çok uzundur.
Referanslar: Anthropic Mühendislik Blogu (Etkili Ajanlar Oluşturma, Etkili Bağlam Mühendisliği, Çoklu-Ajan Araştırma Sistemi, Uzun Süreli Ajanlar için Etkili Koşum Takımları, Yönetilen Ajanlar); OpenAI Geliştiriciler Blogu (Codex ile Uzun Vadeli Görevler Çalıştırma, Shell + Beceriler + Sıkıştırma); Google Geliştiriciler Blogu (Verimli Bağlam Duyarlı Çoklu-Ajan Framework'ü Mimari Oluşturma, Conductor: Gemini CLI için Bağlam Odaklı Geliştirme)
