Subagent’lar ne zaman ana ajan döngüsüne katılmalı?

Anthropic’in Applied AI ekibi, Claude Platform üzerinde ajan geliştiren kurumlara yönelik yeni bir rehber yayımladı. Ana fikir şu: Birçok kurumsal ajanda, birden fazla subagent yerine bağlamı ve araçları aşamalı olarak açan (progressive disclosure) tek bir ajan döngüsü kullanmak kaliteyi artırırken maliyeti ve gecikmeyi düşürebiliyor. Rehber bunun ne zaman ve nasıl yapılacağını anlatıyor.

Anthropic, mevcut çok ajanlı sistemlerini değerlendirmek isteyenler için GitHub’da bir geçiş kiti (migration kit) de yayımladı. Kit, kullanılan kalıpları belirleyen, alternatifleri değerlendiren ve en iyi yaklaşımı doğrulayan rehberli bir iş akışı çalıştırıyor; gerçek sisteme uygulamadan önce denenebilecek bir demo da içeriyor.

Subagent’lar neden sorun olabiliyor?

Kendi bağlam penceresi, araçları ve talimatları olan ve bir koordinatör tarafından yönetilen subagent’lar ajan tasarımının temel bileşenlerinden biri. Doğrulama, paralel iş ve modüler yetkilendirme için etkililer; Anthropic de çok ajanlı araştırma sistemi gibi kendi ajanlarında kullanıyor.

Ancak ekip, kurumsal dağıtımlarda yönlendirici (router), planlayıcı ve alan subagent’larını ana ajan döngüsüne katmanın fayda sağladığı bir örüntü fark etmiş. Birkaç kurumsal dağıtımdaki karşılaştırmalarda, skill’lerle donatılmış tek bir ajan hem “her şey için tek prompt” tasarımından hem de subagent tasarımından kalite açısından sıklıkla daha iyi sonuç vermiş; çoğu zaman görev başına daha düşük maliyet ve gecikmeyle.

Örneğin bir şirket, müşteriye dönük ajanındaki bir düzine uzman subagent’ın tutarlı bir marka deneyimini korumayı zorlaştırdığını ve kullanıcı deneyimini bozan gecikme eklediğini görmüş. Anthropic sık sık şu tanıdık tasarımla karşılaştığını söylüyor: bir niyet sınıflandırıcı, sabit çok adımlı bir akıl yürütme hattı, kullanıcı segmenti grupları, ayrı öneri dalları ve en üstte çok ajanlı bir orkestratör. Bu durumlarda yapının büyük kısmının modelin artık ihtiyaç duymadığı işi yaptığı; tek bir net sistem prompt’u, 4-5 yalın veri aracı ve sağlam çıktı korumalarının kullanım senaryosunun çoğunu karşılayacağı görülüyor.

Subagent’ların hâlâ yeri var. Şu durumlarda kullanılmaları öneriliyor:

• Tek bir ajan döngüsü, bağlam şişmesi nedeniyle ölçülebilir performans kaybı yaşıyorsa,
• Birden fazla görevin, iş bitince atılabilecek temiz bağlam pencereleriyle paralel yürütülmesi gerekiyorsa,
• Tek bir ajan doğru aracı seçmekte zorlanıyorsa ya da sistem prompt’unda çelişen talimatlar varsa.

Ama Anthropic’e göre kurumlar çoğu zaman her ekibe ya da problem tipine kendi subagent’ını veriyor ve ajan mimarisi şirketin organizasyon şemasının bir kopyasına dönüşüyor (iş başındaki Conway yasası).

Büyük kurumlarda ajan geliştirmenin tuzakları

Şirketler genellikle birden fazla ürün ve yeteneği tek bir müşteri arayüzünde birleştiren bir ajan istiyor. Her yetenek ayrı bir ekibe ait olduğu için önce her ekip kendi ajanını yapıyor, ardından merkezi bir platform ekibi üstüne bir orkestratör kuruyor. Bu en basit çözüm gibi görünse de şu sorunları getiriyor:

• Bağlam yönetimi: Ajanlar arasında hangi bağlamın aktarılacağına karar vermek gerekiyor ve gidip gelen aktarımlarda ayrıntılar kayboluyor.
• Subagent yayılması: Her ekip kendi subagent’ını çıkarıyor; sonunda zorunlu standartları ve belirli bir sahibi olmayan yüzlerce örtüşen subagent oluşuyor.
• “Frankenprompt”: Her ekip sistem prompt’una bir cümle ekliyor; sonuç çelişen kurallar ve tutarsız bir ses.
• Denetlenmemiş, fazla yerel eval’ler: Herkes kendi alt görevine aşırı optimize edilmiş eval’ler ekliyor. Bütün seti kimse sahiplenmiyor ve yönetim sulandırılmış, fazla yerel skorlara göre karar veriyor.
• Gecikme: Çok ajanlı mimari gecikme ekliyor. Çok ajanlı yapısını tek ajan döngüsüyle karşılaştıran bir müşteri, tek döngüde yaklaşık 2 kat daha hızlı çalışma süresi görmüş.

Aşamalı açılım ile tek ajan döngüsü

Orkestratör-subagent tasarımı, farklı ekiplerin geliştirdiği uzmanları koordine etmek için makul bir yaklaşım. Ancak çoğu zaman daha etkili olan, bağlamı skill’lerle ve araçları tool search ile aşamalı olarak açmak. Yani ajan, skill ve araçların yalnızca kısa açıklamalarını görüyor; tam içerikleri yalnızca gerektiğinde yükleniyor. Bunun üç nedeni var:

• Ortak bağlam daha iyi yanıt üretiyor: Uzun süre çalışan ajanlarda farklı görevlerin bağlamı ana pencerede durmalı. Önceki adımların sonuçlarını görmüş bir ajan bunları birbirine bağlayabiliyor; bu da subagent’ların geri verdiği özet setinden daha zengin çıktılar ve içgörüler sağlıyor. Ayrıca daha az bağlam penceresi ve daha az kayıplı aktarım demek.
• Aşamalı açılım bağlam şişmesini önlüyor: Bu teknik, tüm bağlamı tek uzun sistem prompt’una yüklemeden çok çeşitli görevleri yapabilen tek ajanlar kurmayı sağlıyor. Ekiplerin işi subagent’lara bölmesinin ana nedeni ortadan kalkıyor. Anthropic, skill ve araçların aşamalı açılımı dahil kesintilerle Claude Code’un gelişmiş modeller için sistem prompt’unu %80’in üzerinde küçülttüğünü söylüyor.
• Modeller daha yetenekli: Opus 4.5’ten itibaren modeller tek bir döngüde çoğu ekibin beklediğinden çok daha fazlasını yönetebiliyor. Opus 5.5 ve Fable 5.1’de thinking kapatılamıyor; yeni modeller ilerlemelerini giderek daha çok anlatıyor ve işlerini yaparken kontrol ediyor, bu da bazı harness öğelerini gereksiz kılıyor. Daha basit bir döngü bir sonraki modele geçişi de kolaylaştırıyor; Anthropic’in yardım ettiği geçişlerde katı çok ajanlı yapılar çoğu zaman yeni modelin daha fazla iş yapmasını engelleyen şey olmuş.

Tek ajan döngüsü disiplin gerektiriyor: dikkatle yönetilen bir sistem prompt’u, doğru zamanda tetiklenen skill ve araç açıklamaları ve bağlam pencereleri, bellek ve not alma konusunda bilinçli bir yaklaşım. Tek bir merkezi ekip uçtan uca kaliteyi ve sistem prompt’unu sahiplenmeli, her yeni aracı ve eval’i yayına çıkmadan önce denetlemeli. Bu ekibi küçük tutmak iterasyonu hızlandırıyor ve büyük bir organizasyonda koordinasyon maliyetini düşürüyor.

Çok ajanlı yolu seçenler için öneri, işe yarayabilecek en basit kalıpla (generator-verifier, orchestrator-subagent ya da başka) başlamak ve sınırları bağlama göre çizmek. Her subagent’a sistemin geri kalanından az şey gerektiren bir iş verilmeli ve kompakt bir sonuç döndürmesi sağlanmalı. Bağımsız araştırma yolları, temiz arayüzlü ayrı bileşenler ya da kara kutu doğrulama iyi adaylar. Ajanlar problem tipine göre bölündüğünde her aktarımda bilginin bozulduğu bir “kulaktan kulağa” oyunu ortaya çıkıyor.

Subagent’lar ana döngüye nasıl katılır?

Rehberin önerdiği hedef tek döngü tasarımı şöyle:

• Harness’te belirlenen sınırlarla (tur ve maliyet bütçeleri, yazma kapıları) açık uçlu bir araç döngüsü çalıştıran tek model ve tek bağlam penceresi.
• Her turda model bir grup araç çağrısı üretiyor. Harness bunları paralel çalıştırıp ham sonuçları aynı modele döndürüyor; model bir sonraki adıma karar veriyor: yeni bir çağrı grubu, kullanıcıya bir soru ya da bir yanıt.
• Döngü model yanıt verdiğinde ya da bir bütçeye ulaştığında duruyor. İsteğe bağlı olarak yanıttan sonra bir hedef ya da doğrulayıcı kontrolü çalışabiliyor.
• Model ilk turda planını bağlama yazıyor ve sonuçlar geldikçe güncelliyor. Orkestratör ve uzman ajan yapısından temel fark bu: Planı yazan model aynı zamanda onu uygulayan model olduğu için planı tur ortasında değiştirebiliyor.
• Bağlam yine yükleniyor ama ajanın kendisi yönetiyor. Kural kataloğundan planı yeniden yazan bir kod adımına artık gerek yok; sıralama ve alan prosedürü skill’lere, katı limitler (doğrulama, onay kapıları) ve konuşma ortasında çıkan işler (ör. bellek sorgusu) araçlara taşınıyor.
• Kod yine ucuz ve neredeyse her zaman gerekli olan şeyleri yüklemek (ör. varlık eşleştirme adımı) ve döngünün çağırdığı araçlardaki mekanik kısımları (payload oluşturma, stream ayrıştırma, bir netleştirmeye devam etme) yürütmek için kullanılabiliyor.

Bu tasarım, birçok ekibin hedeflediği son duruma da, yani kullanıcının üst düzey hedeflerini anlayıp onun adına hareket eden bir ajana da yardımcı oluyor; çünkü ajanın öğrendiği her şey tek bir bağlamda kalıyor.

Görev tamamlama eval’leri

İlk adım, bir subagent’ın ana döngüye katılıp katılmaması gerektiğine karar vermeyi sağlayacak bir eval seti oluşturmak. İşe yaradığı görülen yapı: merkezi ekibin sahiplendiği ortak bir uçtan uca set ve her skill’le birlikte o skill’in sahibi ekibin gönderdiği daha küçük setler. Başlamak için 10 altın örnek bile yeterli.

Ajanın son mesajını bir rubrike göre puanlamak yanıt kalitesini izlemek için iyi bir başlangıç. Orkestratör varken yönlendirme doğruluğu da (doğru subagent seçildi mi?) izlenmeli. Bir subagent katıldıktan sonra ise ajanın doğru skill’i yükleyip yüklemediğine ya da doğru aracı çağırıp çağırmadığına bakılmalı. Zamanla görev tamamlama eval’lerine geçmek, mimarileri karşılaştırırken en çok işe yarayan şey. İç sistemlerin tekrar oynatılmasının ve kullanıcı etkileşiminin simüle edilmesinin zor olduğu ortamlarda Anthropic’in kendi içinde işe yarayan yöntem, önemli olaylara zaman damgası koyup bunları daha sonra hedefli eval’ler olarak tekrar oynatmak.

Subagent’ları zamanla azaltmak

Tek ajan döngüsüne geçiş, subagent’ları araçlara ve skill’lere dönüştürmek demek. Bu üç yolla yapılabiliyor: alan subagent’larını birleştirmek, onları araç olarak çağırmak ya da yerlerine skill ve araçlar koymak.

Alan ajanlarını birleştirmek: İlk birleştirmeden önce küçük bir uçtan uca eval kurun, sonra ortak bağlama göre, en çok kullanılan subagent’lardan başlayarak birleştirin. Birbirinin çıktısına bağlı çalışan, aynı veriye dokunan ya da sık sık birlikte çağrılan uzmanları birleştirin. Örneğin üretim trafiğinin önemli bir kısmı bir uzmanın ardından ikinci bir uzmana gidiyorsa bu sıkı bağlı bir çift ve tek bir alan ajanında birleştirmek için aday.

Subagent’ları araç olarak çağırmak: Yukarıdaki üç koşuldan biri geçerliyse ve bir subagent’ı tutuyorsanız, ana ajanın subagent’ları araç olarak çağırması etkili olabiliyor; böylece kullanıcıyla konuşmayı ana ajan sürdürüyor. Subagent’ın konuşmayı tamamen devraldığı bir aktarım yalnızca kullanıcıyla doğrudan konuşması gerekiyorsa öneriliyor. Bu yaklaşım subagent’lar için ortak bir yanıt şeması tanımlamayı, sonucu ana ajanla gerçek veriye karşı doğrulamayı ve son sentez adımının girdisini kırpmayı sağlıyor. Subagent’ları yeniden yazmak gerekmediği için iyi bir ilk adım. Yine de bazı sorunlar kalıyor: Her uzmanın kendi prompt’u, bağlamı, sahibi ekibi ve eval’leri var; her çağrı kayıplı bir özet döndürüyor ve her çağrı gecikme ekleyen iç içe bir model döngüsü.

Skill ve araçlarla ana ajana katmak: Subagent’ları birer birer, prompt’larını skill’lere ve API çağrılarını MCP araçlarına dönüştürerek katın. Subagent’lı ve subagent’sız eval performansını karşılaştırın, sonra hangisini tutacağınıza karar verin. Karşılaştırırken yalnızca son skora değil, hangi görevlerin sonucunun değiştiğine bakın. Anthropic bunu örnek bir destek ajanında test ettiğinde, bir subagent’ı diğerine katmak gecikmeyi düşürmüş ama daha önce geçen bir süreci bozmuş: Ana ajan sipariş sorgulama aracını tutuyor ve teslimat tarihi için kargo uzmanına sormadan kendi başına yanıt veriyormuş. Bu yüzden her değişiklikten önce eval’de üretimde birlikte çalışan her ajan zinciri ve ajanın asla çiğnememesi gereken her kural için bir görev olmalı ve her görev birden fazla kez çalıştırılmalı; bu örnekteki bozulma iki çalıştırmadan yalnızca birinde ortaya çıkmış.

Birden fazla ekip tek bir ajana nasıl katkı verir?

Alan bilgisi bilgi tabanlarından, skill’lerden ve MCP araçlarından alınabiliyor. Ekipler sahipliklerini ajanlardan skill ve araçlara kaydırabilir; küçük bir merkezi ekip ise sistem prompt’unu ve uçtan uca kaliteyi sahiplenir, yeni skill, araç ve eval’leri yayına çıkmadan önce denetler.

• MCP araçları: Ajanın bir eylem yapması, bir sistemden canlı veri okuması ya da sabit formatta sonuç döndürmesi gerektiğinde doğru seçim. Geçiş sürecinde subagent’ları çağırmaya devam etmek için de kullanılabilirler. Araçları API başına değil kullanıcı niyetine göre gruplamak öneriliyor; sistem prompt’unda 30-50 araç tanımını aşınca araç seçimi kötüleşme eğiliminde. Ertelenmiş yüklemeyle tool search kullanın, katı ön koşulları sınırlayın ve gerekenleri araçların içine taşıyın. Örneğin Y, X’in çıktısına ihtiyaç duyuyorsa Y’nin aracı bunu kontrol edip modelin uygulayabileceği bir talimat döndürsün. Kullanıcı bazlı yetkiler de aynı şekilde çalışıyor: Her araç çağıran kullanıcının neyi görüp yapabileceğini kontrol edip modelin okuyabileceği düz bir ret döndürüyor; böylece tek döngü, her yetki seviyesi için ayrı ajan gerekmeden farklı erişimli kullanıcılara hizmet verebiliyor.
• Skill’ler: Ajanın bir ekibin işi nasıl yaptığını, yani eskiden bir uzman subagent’ın prompt’unda duran adımları, kuralları ve muhakemeyi bilmesi gerektiğinde doğru seçim. Skill yayılmasını önlemek için her ekipte skill’lerinden sorumlu bir kişi (DRI) olmalı. /skill-creator iyi yapılandırılmış yeni skill’ler yazmayı ve mevcutları kırpmayı, tekrarları ayıklamayı ve yeniden yapılandırmayı sağlıyor. /skill-doctor ise her skill’in maliyetini ve ne sıklıkla kullanıldığını gösterip ölü yükün silinmesine yardım ediyor.
• Bilgi tabanları: Ajanın yalnızca zaman zaman ihtiyaç duyduğu referans materyal için doğru seçim. Politikalar, metrik tanımları ve ürün özellikleri gibi bilgiler, modelin çağırdığı bir arama ya da sorgu aracının arkasında durabilir veya bir skill içinde referans dosyası olarak gelebilir. Bu bağlamın kod tarafından alınıp prompt’lara yapıştırılmasından kaçınılmalı.

İşi hızlandıran araçlar

Anthropic, yukarıdaki işlerin çoğuna yardımcı olan bir dizi Claude API skill’i yayımladı. Geçiş kiti bu skill’leri çok ajanlı sistemleri değerlendirip tek ajan döngüsüne taşımak için tek bir rehberli akışta birleştiriyor:

• /claude-api build-eval: Merkezi ekibin sahiplendiği ilk uçtan uca seti ya da her ekibin skill’iyle birlikte gönderdiği küçük eval’leri oluşturmaya yardım ediyor.
• /claude-api prompt-audit: Prompt’larda, skill’lerde ve araç açıklamalarında eski modeller için yazılmış talimatları işaretleyip düzeltmeleri diff olarak öneriyor. Eski bir model için eklenmiş ve artık ajanı yavaşlatan ya da katılaştıran kuralları bulmak için sistem prompt’larında çalıştırılabiliyor.
• /claude-api hillclimb: Bir uygulamayı mevcut bir eval’e karşı yinelemeli olarak iyileştiriyor. “Katılmış mı, ayrı mı tutulmalı” karşılaştırması için kullanılabiliyor: Bir subagent’ı skill ve araçlara dönüştürdükten sonra açıklamalar üzerinde iterasyon yapıp katılmış versiyonun subagent’ı yakalayıp yakalamadığına bakılıyor.
• /claude-api cost-optimize: Çağrıların nereye gittiğini profilleyip prompt caching, gereksiz girdi ve çıktı token’larını kırpma, effort ve model seçimi gibi seçeneklerden tasarruf önerileri getiriyor; her seferinde tek bir değişiklik.

Anthropic’e göre modeller geliştikçe en iyi kullanım şekline dair anlayış da değişiyor; bu da herhangi bir mimariyi, arkasındaki ilkeden daha az önemli kılıyor: ölç, her seferinde tek bir şeyi değiştir ve işe yarayanı tut.

Rehberin özeti: Modeller yetenekleştikçe ve ajanlar daha uzun çalıştıkça subagent’ların daha fazlası skill ve araçlara dönüşebilir. Bunu tek adımda yapmak gerekmiyor. Küçük bir uçtan uca eval kurun, bir subagent’ı katın; katılmış versiyon daha kötü skor alırsa subagent olarak tutun, sonra bir sonrakine geçin.

Kaynak: https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop