Tek ajan mı, çok ajan mı?

Bir yapay zekâ sistemine ofisiniz için üç dizüstü bilgisayardan hangisini almanız gerektiğini sorun; yanıtı ezberinden verebilir. Ona bunu araştırmasını söyleyin, her şey değişir: arama yapması, sayfa okuması, not tutması ve sırada ne yapacağına karar vermesi gerekir. Bu biçimde çalışan modele ajan denir; “çok ajanlı sistemler” etrafındaki kafa karışıklığının çoğu tam burada başlar.

Bu yazı küçük bir işi beş şekil boyunca izliyor: beş kişilik bir ofis için üç dizüstüyü karşılaştırmak ve birini önermek. Tek bir ajanın bunu yapışını ve bağlamında yer kalmadığını görecek, işi bir ekibe üç biçimde bölecek, iki çalışanın birbiriyle çelişmesine tanık olacak ve ajan sayısı arttıkça hataların neden artabildiğini hesaplayacaksınız. Bu sistemleri kuranların yayımladığı anlatımlara dayanıyoruz; yararlı biçimlerde ayrışıyorlar. Şekillerdeki dizüstüler, sayfalar ve her token sayısı uydurmadır ve her şekil bunu söyler: bir çalıştırmanın biçimini gösterirler, bir ölçümü değil. Dışarıdan gelen her şey adıyla, tarihiyle ve bağlantısıyla yer alır.

Bu yazının sonunda şunları bileceksiniz:

• ajanın ne olduğunu ve uzun bir işin onu neden yavaş, pahalı ve unutkan yaptığını;
• yönetici ve çalışanlar, uzmanlar zinciri ve yazar ile gözden geçirenin her birinin neyi kazandırıp neyden vazgeçirdiğini;
• ikinci bir ajanın ne zaman değdiğini, ne zaman değmediğini ve kanıtların iki yönde ne söylediğini.

Bir sohbet yanıtı tek adımdır: bir soru girer, metin çıkar. Ajan ise bir modeli araçlarla birlikte bir döngüde çalıştırır. Model her turda o ana kadar yazılanların hepsini okur, sırada ne yapacağına karar verir ve ya yanıt verir ya da bir web araması ya da veritabanı sorgusu gibi bir aracı çağırır. Aracın sonucu aynı metne eklenir ve döngü yeniden başlar. Anthropic’in Building effective agents rehberi (Aralık 2024) çizgiyi aynı yerden çeker: ajanda model, kendi sürecini ve araç kullanımını kendisi yönlendirir.

Araç herhangi bir şey olabilir: RAG yanıtları nasıl bulur? yazısındaki gibi bir belge araması ya da Veritabanınıza Türkçe sorun yazısındakiler gibi bir veritabanı sorgusu. Bizim işimizde araç, uzun sayfalar getiren bir web araması.

Yani ajan, arama düğmesi olan bir sohbet botu mu? Neredeyse. Onu ajan yapan döngü: yeniden arayıp aramayacağına, başka bir şey sorup sormayacağına ya da yanıt verip vermeyeceğine sizin kodunuz değil model karar verir. Model işin bittiğine karar verene kadar bu tekrarlanır.

İş şu: Kestrel 14, Heron 15 ve Plover 13’ü beş kişilik bir ofis için karşılaştırmak. Ajan bunu altı soruya böler: fiyat, pil ve ağırlık, garanti, kullanıcıların bildirdiği arızalar, stok ve teslimat, bir de ofisin muhasebe yazılımının çalışıp çalışmadığı. Her soru bir arama tutar ve bir sayfa getirir. “Sonraki tur”a basın. Her turda model önce kaydın tamamını okur (üzerinden bir tarama geçer), sonra kısa bir not ve bir arama yazar ve bir sayfa gelir. Üstteki çubuk kayıttır; altındaki çubuk, modelin şimdiye kadar okuduğu her şeydir, aynı ölçekte. Modelin yazdığı her şey ve dönen her sayfa aynı kayda eklenir; kayıt yalnızca görevle ve ajanın sabit talimatlarıyla (300 token) başlamıştı.

Bu şekil JavaScript gerektirir. Tek bir ajanın üç uydurma dizüstü hakkındaki altı soruyu yanıtlamasını gösterir. Kayıt 300 token (görev) ile başlar ve yedi turdan sonra 12.990 token’a büyür. Model her turda kaydın tamamını yeniden okur; bu yüzden yedi turda toplam 46.160 token okur, yani biten kaydın uzunluğunun yaklaşık 3,6 katı. Sayılar uydurmadır.

Kelimelere değil iki çubuğa bakın. Son turda kayıt 12.990 token uzunluğunda, ama model toplam 46.160 token okudu, yani yaklaşık 3,6 kat fazla; çünkü her tur bütün hikâyeden yeniden başladı. (Token, kelimenin kısa bir parçasıdır; modelin okuduğu ve ücretlendirildiği birimdir.) Burada yanlış giden bir şey yok. Bir döngü böyle çalışır ve uzun işlerin göründüğünden yavaş ve pahalı olmasının nedeni de budur.

Neden her şeyi yeniden okuyor? Önceki turları hatırlamıyor mu? Kendi başına hayır. Model yalnızca o turda kendisine verilen metni bilir. Hafıza gibi görünen şey, kaydın yeniden gönderilmesidir. Bazı sağlayıcılar tekrar eden baş kısmı daha ucuza saklamanıza izin verir, ama model yine de hepsini içine almak zorundadır ve hepsinin sığması gerekir.

Sorun “sığmak”. Bir model aynı anda ancak belli bir miktarı okuyabilir; bu sınıra bağlam penceresi denir. Bizim penceremiz bir oyuncak: 8.000 token, etki ekrana sığsın diye. Gerçek pencereler çok daha büyük, gerçek işler de öyle: Anthropic’in çok ajanlı araştırma sistemini kuran ekip (How we built our multi-agent research system, Haziran 2025) yönetici ajanın planını belleğe kaydettiğini söylüyor, çünkü 200.000 token’ı aşan bağlam kesiliyor.

Pencere dolunca ne olacağı sisteme bağlı. En basit yöntem, ki burada çizilen de bu, yer açmak için en eski içeriği atmaktır. “Tek ajan”la başlayın: şekil ekrana girerken bir kez oynar ve kesikli bir çizgi pencereyi işaretler. Sonra “Yönetici ve çalışanlar”a geçin. Burada bir yönetici her soruyu kendi çalışanına verir. Çalışan neredeyse boş bir bağlamla başlar, tek aramasını yapar ve yaklaşık yüz token uzunluğunda bir özet gönderir; yönetici uzun sayfaları hiç görmez. İki resim de aynı ölçeği kullanıyor.

Bu şekil JavaScript gerektirir. Aynı dizüstü işini, örnek niteliğinde 8.000 tokenlık bir pencerede, tek bir ajanla ve bir yönetici ile altı çalışanla karşılaştırır. Tek ajan en büyük turunda 12.660 token’a ihtiyaç duyar; bu yüzden en eski üç adımı (fiyat, özellik, garanti) öneriyi yazmadan önce pencereden düşer ve toplam 33.860 token okur. Ekip hiçbir turda 2.960 token’dan fazlasına ihtiyaç duymaz, hiçbir şeyi unutmaz ve toplam 17.120 token okur. Sayılar örnek niteliğindedir.

Tek ajanın penceresinden üç şey düştü: fiyatlar, özellikler ve garanti koşulları. Önerisini bunlar olmadan yazdı. Kayıtta bir şeyin eksik olduğunu söyleyen hiçbir iz yok. Ekipte hiçbir model aynı anda 2.960 token’dan fazlasına ihtiyaç duymuyor ve hiçbir şey kaybolmuyor; çünkü her çalışan özetini sayfası hâlâ önündeyken yazıyor. O özet, tek ajanın kaybettiği notun ta kendisi.

Şekilde tek ajan ilk üç yanıtını unuttu. Ona en çok ne yardım ederdi?

1. Doğru bilgiyi aldığından emin olmak için her sayfayı iki kez okumak.
2. Her notu kayıt dışına kaydetmek, düşen sayfalar zarar vermesin.
3. Önceki turları kendisine gösterilmeden hatırlayan bir model.

Yanıtı göster

Değerli olan notlardı ve sayfalarla birlikte düştüler. Düşmeyecek bir yere kaydedilmiş bir not (bir dosya, bir bellek deposu ya da bir çalışanın yöneticiye verdiği özet) sayfa gittikten sonra da bilgiyi korur.

A değil: ikinci bir okuma kayda daha fazla token ekler; pencere daha çabuk dolar ve daha çok şey düşer.

C değil: model yalnızca o turun metnindekini bilir. Hafıza gibi görünen şey, yeniden gönderilen kayıttır.

Şimdi ikinci sayı ve adil bir karşılaştırma. Pencere altında tek ajan 33.860 token okudu, ilk şekildeki 46.160 değil; çünkü attığı adımlar artık yeniden okunmuyor: bu tasarruf unutarak ödeniyor. Adil karşılaştırma, her şeye yeri olan tek ajanın okuduğu miktar, yani 46.160. Ekip 17.120 okudu, bunun yaklaşık yüzde 37’si; çünkü tek ajan büyüyen bir kaydı yeniden yeniden okuyor. Yani sabit bir işi bölmek, kendi başına bir ekibi pahalı yapmıyor. Pahalı yapan başka bir şey. Anthropic, ajanların bir sohbetin yaklaşık dört katı, çok ajanlı araştırma sisteminin yaklaşık on beş katı token kullandığını ve tek bir kıyaslamada başarım farklarının yaklaşık yüzde 80’ini yalnızca token kullanımının açıkladığını bildiriyor. Özeti: bu sistemler esas olarak soruna yetecek kadar token harcamaya yardım ettikleri için işe yarıyor. Benim yorumum, onların değil: bir ekip, hiçbir bağlam taşmadan çok daha fazla token’ı paralel harcamanıza izin veriyor; bu hem daha iyi çalışmasının hem de daha pahalı olmasının nedeni olabilir.

Yani ekip daha mı ucuz? Okuduklarım bunu söylemiyor. Yalnızca bu küçük senaryoda, o da ekip fazladan iş almadığı için. Gerçek ekipler fazlasını alır: daha geniş arar, her çalışana görev tanımı yazar, sonuçları birleştirir, bazen birbirlerinin işini tekrarlar. Anthropic’in ilk sürümleri basit sorular için bile onlarca çalışan başlatmış. Dürüst yanıt şu: ekibin ne kadar fazla iş yaptığına bağlı.

Bir işi böldükten sonra bir biçim seçmeniz gerekir. Üçü yaygın. Yönetici ve çalışanlar düzeninde bir model planlar, parçaları dağıtır ve sonuçları birleştirir; Anthropic’in rehberi buna orchestrator-workers (yönetici-çalışan) kalıbı diyor. Uzmanlar zincirinde her ajan bir aşamayı yapıp notlarını sıradakine verir; yani sıra baştan belli. Yazar ve gözden geçirende bir model işi yapar, bir başkası bir döngüde kontrol eder; aynı rehber buna evaluator-optimizer (değerlendirici-iyileştirici) diyor. O rehberde ilki ve sonuncusu iş akışıdır (workflow): kodda kurulmuş yollar; “ajan” sözünü adımlarını kendisi seçen model için ayırıyor. İş akışları iyi tanımlı ve öngörülebilirlik isteyen işlere uyar, ajanlar açık uçlu işlere uyar ve daha pahalıdır.

Bir düzen seçin, sonra bitene kadar “Sonraki aşama”ya basın ve bunu üçü için de yapın. İki sayaca bakın: art arda tur sayısı (kaç adımın birbirini beklemesi gerektiği) ve gönderilen ileti sayısı.

Bu şekil JavaScript gerektirir. Aynı dizüstü işinin üç biçimde yürütüldüğü hazır bir senaryodur. Altı çalışanlı bir yönetici art arda 3 tur sürer ve 12 ileti gönderir. Bir araştırmacı, bir analist ve bir yazardan oluşan zincir art arda 8 tur sürer ve 2 ileti gönderir. Bir yazar ve bir gözden geçiren art arda 9 tur sürer ve 2 ileti gönderir.

Üç düzen yaklaşık aynı miktarda iş yapıyor: yönetici ve zincir için sekiz ajan turu, yazar ve gözden geçiren için dokuz. Değişen biçim. Yönetici ve çalışanlar, altı çalışan aynı anda aradığı için art arda üç turda bitiyor, ama on iki ileti gönderiyor ve her ileti belirsiz ya da kayıp olma ihtimali taşıyor. Zincir yalnızca iki ileti gönderiyor, ama ilk aşaması art arda altı tur. Yazar ve gözden geçiren, iki ileti için art arda dokuz tur harcıyor; bunun karşılığında taslağa ikinci bir bakış alıyor.

Bu ikinci bakışın bir miktar desteği var. Mayıs 2023’te ilk kez yayımlanan ve 2024’te ICML’de sunulan bir makalede Du ve arkadaşları, tek bir modelin birkaç kopyasının her birinin bir yanıt önermesini, ötekilerinkini okumasını ve düzeltmesini sağladı; kendi testlerinde tek bir modele göre daha iyi akıl yürütme ve daha az yanlış bilgi bildiriyorlar. Bu, tek bir modelin kopyaları arasındaki bir tartışma; araç kullanan ajanlardan oluşan bir ekip değil. Yani ikinci bir bakışın işe yarayabileceğini gösteriyor, ekiplerin her zaman kazandığını değil.

O zaman her şeye neden bir gözden geçiren koymayalım? Gözden geçiren de bir model: kendi hataları ve kendi faturası var. Bu yazının son şekli, bir denetçinin neyi satın aldığını ve neye mal olduğunu gösteriyor.

Yönetici-çalışan düzenine karşı en güçlü itiraz, Devin kodlama ajanının arkasındaki şirket Cognition’dan geldi. Don’t Build Multi-Agents (12 Haziran 2025) yazısında Walden Yan, bir modelin attığı her adımın kimsenin yazmadığı kararlar taşıdığını ve birbirinin kararlarını göremeyen çalışanların çelişen kararlar verdiğini savunuyor. Örneği: iki çalışana bölünen bir Flappy Bird kopyası; biri Super Mario tarzı bir arka plan yaptı, öteki Flappy Bird’ünkine hiç benzemeyen, öyle de hareket etmeyen bir kuş yaptı; ikisini uzlaştırmak son ajana kaldı.

Aynı sorun bizim dizüstü hikâyemizde de var; hazır ve uydurma. İki çalışan aynı görev tanımını alıyor. Önce “Ayrı çalışıyorlar” ile bölümlerini okuyun, sonra “Ortak not sayfası kullanıyorlar”a geçin.

Bu şekil JavaScript gerektirir. Hazır bir senaryodur. İki çalışan aynı raporun maliyet ve destek bölümlerini yazıyor. Ayrı çalışırken maliyet çalışanı “en iyi”yi satın alması en ucuz olan diye anlayıp Plover 13’ü, destek çalışanı en güçlü destek diye anlayıp Heron 15’i öneriyor; rapor kendiyle çelişiyor. Ortak bir not sayfası kullandıklarında ikisi de onarımlar dahil üç yıllık maliyete göre sıralıyor (Kestrel 1.300, Heron 1.320, Plover 1.380) ve ikisi de Kestrel 14’ü öneriyor. Dizüstüler, fiyatlar ve onarım maliyetleri uydurmadır.

İki çalışan da yanlış bir şey yapmadı. Her biri görev tanımını yanıtladı ve her biri kendi ölçütüne göre haklıydı. Farklı olan, hiçbirinin yazmadığı bir seçimdi: “en iyi”nin ne demek olduğu. Burada tek satırlık ortak bir not sorunu çözmeye yetti, ama gerçek işler bu tür seçimlerle dolu (adlar, biçem, birimler, neyin varsayılacağı) ve çoğu hiç yazılmıyor.

Yönetici ikisine de “en iyi”nin ne demek olduğunu söyleyemez miydi? Çoğu zaman söyleyebilir ve iyi görev tanımları çok önemli. Anthropic, çalışanlara verilen belirsiz yönergelerin işin tekrarlanmasına yol açtığını söylüyor. Ama yönetici yalnızca önemli olacağını bildiği seçimleri yazabilir; asıl can yakanlar kimsenin görmediği olanlar.

Şekildeki çelişkiye ne yol açtı?

1. Maliyet çalışanı, destek çalışanının yapmadığı bir hesap hatası yaptı.
2. Yönetici iki çalışandan farklı öneriler istedi.
3. Her çalışan “en iyi”ye sessizce kendi anlamını verdi.

Yanıtı göster

İki bölüm de kullandıkları ölçüt için doğru. Çelişki, kimsenin yazmadığı bir seçimde duruyor. Ölçüt hakkında tek bir ortak not olunca aynı iki çalışan anlaşıyor.

A değil: iki bölümdeki aritmetik de tutuyor. Diğer çalışanın ölçütüyle yeniden hesaplarsanız onun yanıtını bulursunuz.

B değil: görev tanımı ikisi için kelimesi kelimesine aynıydı. Fark sonradan, her çalışanın neyi varsaydığında ortaya çıktı.

Cognition’ın 2025’teki önerisi, varsayılan olarak tek, doğrusal bir ajan kullanmak, tek bir bağlama sığmayacak kadar uzun işlerde de geçmişi önemli ayrıntılara sıkıştıran bir adım eklemekti; Cognition bu adımın doğru yapılmasının zor olduğunu söylüyor. Hikâye burada bitmedi. Nisan 2026’da Yan bir devam yazısı yayımladı: Multi-Agents: What’s Actually Working. Aynı anda yazan birden çok ajan için uyarısını koruyor ve işe yarayan daha dar kalıpları anlatıyor: birkaç ajan zekâ ekliyor, yazma işini ise tek bir ajan yapıyor; örneğin temiz bir bağlamla başlayıp kodlama ajanının çıktısını kontrol eden bir gözden geçiren. Büyük bir işi bölüp parçaları alt ajanlara dağıtan bir yöneticiyi de anlatıyor ve bunu sürmekte olan bir çalışma olarak sunuyor.

Sıradaki maliyet düz aritmetik. Her aktarımın işi yüzde 90 olasılıkla doğru aktardığını varsayın. Son yanıtın doğru olması için her aktarımın doğru olması gerekir ve olasılıklar çarpılır: altı aktarım, 0,9’u altı kez çarpmak demek, yani yüzde 53. Anthropic’in rehberi hataların birikmesini ajanların maliyetleri arasında sayıyor; araştırma ekibi de ajanların durum taşıdığını ve hataların biriktiğini söylüyor, bu yüzden sistemi baştan başlamak yerine ajanın kaldığı yerden devam edecek biçimde kurmuşlar.

“Aktarım sayısı” ve “Aktarım başına doğruluk” kaydırıcılarını oynatın. Kesikli çizgi uydurma bir taban: tek başına bir ajan işi yüzde 70 doğru yapıyor. İlk çubuğun onun altına nerede düştüğünü bulun. Sonra ikinci çubuğa bakın; orada bir denetçi hataların yüzde 70’ini yakalayıp geri gönderiyor.

Bu şekil JavaScript gerektirir. Bir modeldir: her biri yüzde 90 oranında doğru altı aktarımda son yanıt, denetçi olmadan yüzde 53 oranında doğrudur. Hataların yüzde 70’ini yakalayan bir denetçi bunu yüzde 82’ye çıkarır; 6 yerine yaklaşık 13 ajan turu gerekir. Tek başına bir ajanın yüzde 70 doğru olduğu varsayılır.

Aktarım başına yüzde 90’da bir zincir tabanı üç aktarıma kadar geçiyor (0,9’un küpü 0,729) ve dörtte altına düşüyor (0,656). Bir denetçi çok şey kurtarıyor: altı aktarımda yüzde 53’ü yüzde 82’ye çıkarıyor, ama işi iki katından fazla artırıyor: 6 yerine 13 tur; çünkü her deneme ayrıca kontrol ediliyor ve yakalanan her hata yeniden yapılıyor. Şeklin neyi varsaydığına da bakın. Hatalar bağımsız, denetçi doğru işi hiç işaretlemiyor ve “yüzde 70” benim seçtiğim bir sayı, tek bir ajanın kendi hataları dahil bütün çalıştırmasını temsil ediyor. Gerçek hayatta ölçmeniz gereken şeyler bunlar.

Denetçi de bir model. Ya o da yanlışsa? O zaman bazı hataları kaçırır; gerçek bir denetçi ayrıca doğru işi de bazen işaretler, bu da daha çok tur demek. Şekildeki yüzde 70 bir varsayım ve bütün mesele o: ölçün.

Art arda altı aktarım, her biri yüzde 95 oranında doğru, denetçi yok. Son yanıt yaklaşık ne sıklıkla doğrudur?

1. Yaklaşık yüzde 74.
2. Yaklaşık yüzde 95, tek aktarımla aynı.
3. Yaklaşık yüzde 30, çünkü altı çok.

Yanıtı göster

Her aktarımın doğru gitmesi gerekir; bu yüzden olasılıklar çarpılır: 0,95’in altı kez çarpımı yaklaşık 0,735, yani yüzde 74.

B değil: yüzde 95, tek bir aktarımın olasılığı. Her ek aktarım, yanlış gitmek için bir şans daha ekler.

C değil: bunun için aktarımların yüzde 95’ten çok daha kötü olması gerekir. Her biri yüzde 82 olsa art arda altısı gerçekten yaklaşık yüzde 30 verir.

Önce lehte olan, yazarların anlattığı haliyle. Anthropic’in çok ajanlı araştırma sistemi, yönetici olarak bir Claude Opus 4 ve çalışan olarak birkaç Claude Sonnet 4 ile, ekibin kendi araştırma değerlendirmesinde tek bir Claude Opus 4’ü yüzde 90,2 oranında geçti (Haziran 2025). Yönetici aynı anda üç ila beş çalışan başlatıyor ve her çalışan birkaç aracı aynı anda kullanıyor; yazıya göre bu, karmaşık sorgularda araştırma süresini yüzde 90’a kadar kısalttı. Kimin ölçtüğüne dikkat edin: sistemi kuran şirket, kendi testinde.

Aynı yazı kalıbın nerede uyduğunu ve nerede uymadığını da söylüyor. Yoğun paralel iş, tek bir bağlam penceresine sığmayan bilgi ve çok sayıda karmaşık araç olan yüksek değerli işlere uyuyor. Bütün ajanların aynı bağlama ihtiyaç duyduğu ya da birbirine çok bağımlı olduğu işlere uymuyor; örnek olarak çoğu kodlamayı veriyor, çünkü kodlamanın paralel koşabilen parçaları araştırmadakinden azdır.

Şimdi aleyhte olan. Cognition’ın savını gördünüz. Bir de Berkeley’den Cemri ve arkadaşlarının çalışması var (ilk kez Mart 2025’te yayımlandı, son sürüm Ekim 2025). Yedi yaygın çok ajanlı çerçevenin 1.600’den fazla açıklamalı çalıştırma kaydı (iz) topladılar ve hataları üç grupta 14 türe ayırdılar: sistem tasarımı sorunları, ajanlar arası uyumsuzluk ve sonucun zayıf denetlenmesi. Çok ajanlı çerçevelerin yaygın kıyaslamalarda sağladığı kazançların çoğu zaman çok az olduğunu belirtiyorlar daha iyi tasarımla iyileştirme fırsatları gördüklerini, ama hataların daha sofistike çözümler gerektirdiğini söylüyorlar.

Peki kim haklı, Anthropic mi Cognition mı? Farklı işleri anlatıyorlar. Anthropic’in çalışanları çoğunlukla okuyor: arıyor ve rapor ediyor, yanıtı yönetici yazıyor. Cognition ise aynı şeyi aynı anda değiştiren çalışanlardan endişe ediyordu. Benim yorumum, onların değil: ikisini birleştirince iki tarafın da bugün anlattığı şey daha çok “çok okuyucu, tek yazar”a benziyor; Cognition’ın 2026 yazısı alt ajanlara iş dağıtan bir yöneticiye de yer bırakıyor.

Bu kaynaklardan çıkan kısa bir karar listesi. İkinci bir ajan şu durumlarda anlam kazanmaya başlar:

• iş, ayrı ayrı yanıtlanabilen sorulara bölünüyorsa ve her biri çok okuma gerektiriyorsa;
• bilgi tek bir bağlama sığmayacaksa ya da tek bir bağlam yalnızca özetine ihtiyaç duyduğunuz sayfalarla doluyorsa;
• ikinci bir bakış, yazabileceğiniz ölçütlere göre denetlenebiliyorsa;
• ve iş, ek token’ların bedelini ödemeye değecek kadar değerliyse: Anthropic, maliyetin ancak görevin değeri bunu haklı çıkardığında anlamlı olduğunu söylüyor.

Parçalar birbirine bağlıysa, iş çoğunlukla tek bir şeyi değiştirmekse (çoğu kodlama) ya da ikinci bir ajanın hangi sorunu çözeceğini adlandıramıyorsanız tek ajanla kalın. Anthropic’in rehberi, işe yarayan en basit çözümü bulmanızı söylüyor; bu hiç ajan kullanmamak anlamına da gelebilir: erişimle desteklenmiş tek bir model çağrısı çoğu zaman yeter.

Bir ekip kurarsanız, iki çalışanın anlaşamadığı gün ihtiyacınız olacak şeyleri kaydedin: kim kime ne gönderdi, her çalışana verilen görev tanımı, ne döndürdü, kaç token kullandı ve hangi araç başarısız oldu. Anthropic ekibi her çalıştırmayı izliyor ve yaklaşık yirmi test sorusuyla başlamayı öneriyor; bir şeyleri değiştiren ajanlar için son durumun kontrol edilmesini tavsiye ediyor.

Bir döngüdeki model çok şey yapabilir. Birkaçı daha fazlasını yapabilir, daha pahalıya, ve tek bir modelin yapamayacağı biçimlerde anlaşamayabilir. Tek ajanla başlayın. Bir başkasını yalnızca çözdüğü sorunu adlandırabildiğinizde ekleyin: taşan bir bağlam, yan yana yanıtlanabilen sorular, tarif edebildiğiniz hataları yakalayan bir denetim. Sonra gerçekten çözüp çözmediğini ölçün.

14 Ekim 2026’da okundu. Bu alan hızla değişiyor; tarihlere bakın.

• Anthropic Engineering, Building effective agents, 19 Aralık 2024. Şirket mühendislik blogu.
• Anthropic Engineering, How we built our multi-agent research system, 13 Haziran 2025. Şirket mühendislik blogu, sonuçları yazarlarının kendisi ölçmüş.
• Walden Yan (Cognition), Don’t Build Multi-Agents, 12 Haziran 2025. Şirket blogu.
• Walden Yan (Cognition), Multi-Agents: What’s Actually Working, 22 Nisan 2026. Şirket blogu.
• Yilun Du, Shuang Li, Antonio Torralba, Joshua Tenenbaum ve Igor Mordatch, Improving Factuality and Reasoning in Language Models through Multiagent Debate, arXiv 2305.14325, 23 Mayıs 2023 (ICML 2024, hakemli).
• Mert Cemri ve arkadaşları, Why Do Multi-Agent LLM Systems Fail?, arXiv 2503.13657, ilk kez 17 Mart 2025’te yayımlandı, son sürüm 26 Ekim 2025. Ön baskı.