Multi Agent Sistem Nedir? Çok Ajanlı AI Ne Zaman Mantıklı?

Her yeni ajan demosu aynı vaadi tekrarlıyor: "Bir ajan araştırsın, biri yazsın, biri kontrol etsin, siz sadece izleyin." Kulağa küçük bir ekip kurmak gibi geliyor. Peki gerçekten öyle mi, yoksa üç ajanı yan yana koymak çoğu zaman sadece üç kat fatura mı demek?

Bu yazı, çok ajanlı sistem (multi agent sistem) kavramını karar verici diliyle açıyor: ne olduğu, hangi işlerde tek ajanı gerçekten geçtiği, hangi işlerde gereksiz karmaşıklık olduğu ve bir teklifte bu ifadeyi gördüğünüzde sormanız gereken sorular. Yazı, AI altyapısı kararlarının patron özeti serisinin parçası; ajan kavramına sıfırdan başlıyorsanız önce gerçek bir ajan kurulumunu anlattığımız yazıya göz atmanız faydalı olur.

Peşin söyleyelim: sahada incelediğimiz "çok ajanlı" tekliflerin çoğunda ikinci ajan, birinci ajana bir araç eklemekle çözülebilecek bir sorun için kurulmuştu. Bunun neden böyle olduğunu ve istisnaların nerede başladığını anlatacağız.

Multi agent sistem nedir?

Çok ajanlı sistem, tek bir büyük dil modelinin (LLM) bütün işi tek başına yapması yerine, her biri kendi görev tanımına, araçlarına ve bağlam penceresine sahip birden fazla yapay zeka ajanının aynı işi paylaşarak yürüttüğü kurulumdur. Ajanlar birbirine mesaj gönderir; biri genellikle yönetici ya da planlayıcı rolü üstlenir, diğerleri alt görevleri çalıştırıp sonucu geri döndürür.

Tanım basit, ama "ajan" kelimesi sektörde o kadar gevşek kullanılıyor ki önce bir ayrım yapmak gerekiyor. Tek bir model, arama yapıp veritabanına bakıp e-posta taslağı hazırlayabiliyorsa bu zaten bir ajandır: araç kullanan, adım adım ilerleyen tek bir zeka. Çok ajanlı sistemde ise bu zekadan birkaç tane vardır ve asıl mesele aralarındaki iletişimdir.

Pratikte dört desen öne çıkıyor:

• Yönetici-işçi (orchestrator-worker): Bir ajan planı yapar, alt görevleri işçi ajanlara dağıtır, sonuçları toplar. Anthropic'in araştırma asistanı böyle çalışıyor.
• Planlayıcı-uygulayıcı (planner-executor): Bir ajan yalnızca "ne yapılacak" listesini üretir, diğeri o listeyi tek tek uygular. Plan ile eylemin ayrılması denetimi kolaylaştırır.
• Sıralı devir (handoff): Ajan A işi belli bir noktaya getirip bağlamıyla birlikte ajan B'ye devreder. OpenAI'ın Agents SDK'sının çekirdek fikri bu.
• Hiyerarşik: Yönetici ajanların altında başka yönetici ajanlar; büyük kurumsal iş akışlarında görülür, KOBİ ölçeğinde nadiren gerekir.

Bu desenlerin hiçbiri "daha akıllı model" anlamına gelmiyor; hepsi aynı modelleri farklı biçimde örgütlüyor. Sorunun özü de burada: örgütlenme tek başına zeka üretmez, sadece belli işlerde mevcut zekayı daha iyi kullandırır.

Çok ajanlı sistem tek ajandan gerçekten daha iyi mi?

Bazen, ve o "bazen"in bedeli var. Anthropic'in kendi araştırma asistanında yönetici-işçi kurulumu, iç değerlendirmelerinde tek ajana göre yüzde 90 daha iyi sonuç verdi; ama aynı sistem sıradan bir sohbetin yaklaşık 15 katı token harcadı. Eşit hesaplama bütçesiyle yapılan bağımsız bir karşılaştırmada ise çok ajanlı mimari 4 kat maliyetle yalnızca yüzde 4 kazanım sağladı.

İki rakam arasındaki uçurum tesadüf değil. Anthropic'in ölçtüğü iş, geniş bir araştırma taramasıydı: onlarca kaynağı aynı anda okumak, her birinden özet çıkarmak, sonra birleştirmek. Bu iş doğal olarak paralel. Üç işçi ajan üç kaynağı aynı anda okuyunca hem hız hem kapsam artıyor. Anthropic'in kendi analizinde performans farkının yaklaşık yüzde 80'ini kullanılan token miktarı açıklıyordu; yani kazanımın kaynağı ajan sayısından çok, okunan kaynak miktarıydı.

Eşit bütçeli karşılaştırma ise sıralı akıl yürütme görevlerinde yapılmış. Orada ikinci ajan birinciyi beklemek zorunda; paralellik yok, sadece aradaki mesaj trafiği var. Her ajanlar arası mesaj yeni bir model çağrısıdır. Maliyet ve gecikme kadro sayısıyla birlikte artar; görevin zorluğu ikinci planda kalır. Bu rakamlar tek bir çalışmaya dayanıyor, o yüzden kesin bir oran gibi okumayın; ama yön tutarlı.

Cognition ekibi 2025 ortasında "çok ajanlı sistem kurmayın" başlıklı bir yazı yayınladı. Bir yıl sonra görüşlerini şöyle daralttı: okuma işleri paralel ajanlara dağıtılabilir, yazma işleri tek bir hatta kalmalı.

Bu ayrım, bizce konunun en kullanışlı özeti. Rapor toplamak, kaynak taramak, rakip sitelerini incelemek: dağıtılabilir. Tek bir tutarlı sözleşme metni yazmak, bir yazılım modülünü baştan sona geliştirmek, bir müşteriye tek sesle cevap vermek: dağıtılmaz. İkincisini üç ajana bölerseniz üç farklı karar, üç farklı üslup ve birleştirme aşamasında çelişki alırsınız.

Çok ajanlı sistemler neden başarısız oluyor?

Berkeley'den bir ekibin 2025'te yayınladığı MAST çalışması, yedi popüler çerçevede 1.642 gerçek çalışma kaydını inceledi ve çerçeveye göre yüzde 41 ile yüzde 87 arasında başarısızlık oranı buldu. Başarısızlıkların yaklaşık yüzde 44'ü sistem tasarımından, yüzde 32'si ajanlar arası uyumsuzluktan, kalan yüzde 23'ü doğrulama eksikliğinden kaynaklanıyordu.

Rakamları bir kenara bırakıp modlara bakınca tablo daha öğretici. En sık görülen hatalar şunlar:

• Bir ajanın aynı adımı gereksiz yere tekrarlaması (kayıtların yüzde 16'sında).
• İşin ne zaman bittiğini bilmemek; ajanlar sonuç hazır olduğu halde konuşmaya devam ediyor (yüzde 12).
• Görev tanımının dışına çıkmak; ajan kendine verilmemiş bir işi yapmaya kalkıyor (yüzde 12).
• Bir ajanın diğerine verdiği bilgiyi yarım aktarması ya da diğerinin onu görmezden gelmesi.
• Sonucu kimsenin kontrol etmemesi; yanlış çıktı sisteme "tamamlandı" diye giriyor.

Listeye dikkatli bakın: hiçbiri "model yeterince zeki değildi" demiyor. Hepsi, insan ekiplerinde de gördüğümüz organizasyon hataları. Görev tanımı belirsiz, bitiş kriteri yok, kimse kimin ne yaptığını doğrulamıyor. Fark şu ki insan ekibinde bir kişi "dur, bunu zaten yaptık" der; ajan ekibinde bunu söyleyecek kimse yoksa fatura kabarmaya devam eder.

Bu yüzden çerçeve seçimi (LangGraph mı, CrewAI mı, Google ADK mı) çoğu projede sanıldığı kadar belirleyici değil. Aynı çalışma, sorunların büyük kısmının çerçeveden bağımsız tasarım ve doğrulama açığı olduğunu gösteriyor. Çerçeveyi değiştirmek, kötü görev tanımını iyileştirmez.

Hangi durumlarda çok ajanlı sistem mantıklı?

Çok ajanlı sistem, iş gerçekten paralel alt parçalara bölünebiliyorsa, tek bir bağlam penceresine sığmayacak kadar büyükse, alt görevler farklı araç setleri ya da farklı yetki seviyeleri gerektiriyorsa ve işin değeri 10 ila 15 kat token maliyetini karşılıyorsa mantıklıdır. Bu dört koşuldan en az ikisi yoksa tek ajan büyük olasılıkla yeterlidir.

Koşulları biraz açalım:

• Paralel okuma: On iki tedarikçinin teklif dosyasını aynı anda incelemek, elli rakip ürün sayfasını taramak, bir mevzuat değişikliğinin altı farklı sözleşmeye etkisini ayrı ayrı çıkarmak. Her parça bağımsız, sonuçlar sonunda birleşiyor.
• Bağlam sınırı: Tek modelin bir seferde okuyabileceği metin miktarı sınırlı. Bin sayfalık bir arşivden özet çıkarırken her ajanın kendi penceresiyle bir bölümü alıp özet döndürmesi, tek ajanın parça parça okuyup unutmasından iyi çalışıyor.
• Yetki ayrımı: Ödeme sistemine yazma yetkisi olan ajanla müşteriye e-posta yazan ajanın aynı zeka olması istenmez. Ayrı ajan, ayrı yetki, ayrı denetim izi. Burada ikinci ajan güvenlik aracıdır.
• Yüksek değerli iş: Hukuki inceleme, rekabet istihbaratı, teknik literatür taraması. Sonuç birkaç yüz bin liralık bir kararı etkiliyorsa 15 katı token, ölçeğe göre hâlâ küçük bir rakam.

Bir de şunu ekleyelim: ajanlar birbirini eleştirecek şekilde kurulduğunda (biri teklif yazar, diğeri yalnızca kusur arar) tek ajandan daha dengeli çıktı alınabiliyor. Ama bu da bir okuma ve denetleme işi; kural bozulmuyor.

Hangi durumlarda tek ajan yeter?

Adımlar birbirine sıralı bağımlıysa, iş tek bir tutarlı metin ya da kod üretmekse, süreç kullanıcıyla sık sık geri bildirim alışverişi gerektiriyorsa ya da işlem başına marj düşükse tek ajan hem daha ucuz hem daha güvenilirdir. Sektörde dolaşan bir tahmine göre "ajan" diye sunulan projelerin yaklaşık yüzde 70'i araç kullanan tek ajanla çözülebiliyor; rakam tek bir danışmanlık kaynağından geliyor, ama sahada gördüğümüzle uyumlu.

Tek ajanın gücü, çoğu zaman hafife alınan bir şeyde: araçlarda. Veritabanı sorgusu, hesap makinesi, web araması, e-posta gönderme, CRM'e yazma. Bunları tek bir ajana bağladığınızda o ajan zaten dört beş "uzman" gibi davranır, üstelik koordinasyon sorunu olmadan. İkinci ajanı kurmadan önce sorulacak soru şu: "Bu iş, birinci ajana bir araç ekleyerek çözülür mü?" Cevap çoğunlukla evet.

Müşteri hizmetleri chatbot'u, sipariş durumu sorgusu, fatura özeti çıkarma, toplantı notundan görev listesi üretme gibi işler bu sınıfa giriyor. Bunlara çok ajanlı mimari önerilmişse, önerinin arkasındaki gerekçeyi sorun. MCP gibi standart entegrasyon katmanları sayesinde tek ajana araç bağlamak artık büyük bir yazılım projesi de değil.

Somut senaryo: 30 kişilik bir ithalat firmasının iki denemesi

İzmir'de ithalat yapan 30 kişilik bir firmanın tedarikçi teklif değerlendirmesi için önce dört ajanlı bir sistem kurduğunu, sonra bunu tek ajan artı paralel okuyucu düzenine indirdiğini gördük. İkinci sürüm, birinciye göre değerlendirme başına yaklaşık üçte bir maliyetle çalıştı ve hatalı sonuç oranı belirgin düştü. Rakamlar yuvarlanmış, ama ders net.

İlk kurulum kâğıt üstünde mantıklıydı: bir ajan teklif dosyalarını okuyor, ikincisi fiyatları normalize ediyor, üçüncüsü teslim şartlarını karşılaştırıyor, dördüncüsü rapor yazıyor. Sorun, bu dört adımın sıralı olmasıydı. Fiyat ajanı, okuma ajanının çıktısına muhtaçtı; rapor ajanı üçünü birden bekliyordu. Bir teklif dosyasında birim "koli" yerine "adet" yazınca okuma ajanı bunu not etti, fiyat ajanı notu görmezden geldi, rapor ajanı iki tedarikçiyi yanlış sıraladı. Klasik MAST hatası: bilgi aktarımı yarım kaldı, kimse doğrulamadı.

İkinci kurulumda tek bir ana ajan var. Elinde üç araç: dosya okuyucu, birim dönüştürme tablosu ve rapor şablonu. Paralellik yalnızca bir yerde korundu: on iki teklif dosyası aynı anda on iki hafif okuyucuya dağıtılıyor, her biri yapılandırılmış bir özet döndürüyor. Ana ajan özetleri alıp fiyatı, şartları ve raporu tek başına, tek bağlamda hazırlıyor. Yazma tek hatta; okuma paralel. Cognition'ın söylediği kalıp, sahada da aynı sonucu verdi.

Firmanın satın alma müdürünün yorumu, bu yazının fikrini bizden iyi özetliyor: "Dört ajan dört kişi gibi değil, dört stajyer gibi davrandı. Birbirlerine not bırakıp gittiler."

Teklifte "çok ajanlı" ifadesi görürseniz sorulacak 6 soru

Bir tedarikçi size çok ajanlı mimari öneriyorsa, teknik detaya girmeden şu altı soruyla önerinin sağlamlığını ölçebilirsiniz. Cevaplar belirsizse, büyük olasılıkla mimari ihtiyaçtan değil modadan seçilmiştir.

1. Hangi alt görevler birbirinden bağımsız çalışıyor? (Paralellik yoksa ikinci ajanın gerekçesi nedir?)
2. Yazma işini kaç ajan yapıyor? (Cevap birden fazlaysa tutarlılık nasıl sağlanıyor?)
3. Bir ajanın çıktısını kim doğruluyor, hangi kriterle?
4. Bitiş koşulu ne? Sistem işin bittiğini nereden anlıyor?
5. Tek ajan artı araçlarla aynı iş denendi mi, sonuç neydi?
6. Değerlendirme başına ortalama token maliyeti ne, en kötü durumda kaça çıkıyor?

Sık sorulan sorular

Multi agent sistem ile agentic AI aynı şey mi?

Hayır. "Agentic" ya da ajan tabanlı yapay zeka, modelin araç kullanıp adım adım hedefe ilerlemesini anlatır; tek ajan da agentic olabilir. Çok ajanlı sistem ise bu ajanlardan birden fazlasının birlikte çalışmasıdır. Türkçe kaynaklarda iki terim sık sık birbirinin yerine kullanılıyor, teklif okurken ayrımı netleştirin.

Çok ajanlı sistem ne kadar daha pahalı?

Anthropic'in kendi ölçümünde araştırma tipi bir görev için sıradan sohbetin yaklaşık 15 katı token harcandı. Sıralı görevlerde paralellik olmadığı için maliyet artar ama kazanım artmaz. Kesin çarpan işe göre değişir; teklifte "işlem başına tahmini maliyet" satırı yoksa isteyin.

KOBİ ölçeğinde çok ajanlı sisteme ihtiyaç olur mu?

Nadiren, ama olur. Çok kaynaklı araştırma, toplu belge inceleme ve yetki ayrımı gerektiren işlemler KOBİ'de de var. İhtiyaç, şirket büyüklüğünden bağımsız olarak işin yapısına göre doğar.

LangGraph, CrewAI, OpenAI Agents SDK, Google ADK: hangisi?

Karar verici için asıl soru bu değil. MAST çalışması başarısızlıkların büyük kısmının çerçeveden bağımsız olduğunu gösteriyor. Ekibinizin bildiği dil ve mevcut sistemlerinizle uyum (örneğin Microsoft ekosistemindeyseniz Agent Framework) yeterli seçim kriteri. Görev tanımı ve doğrulama katmanı, çerçeveden çok daha önemli.

Ajanlar birbirini kontrol ederse hata azalır mı?

Bir ajanın diğerinin çıktısını eleştirmesi, özellikle rapor ve teklif metinlerinde kaliteyi artırabiliyor. Ama bu "kontrol" de bir model çağrısı; deterministik bir doğrulama (şema kontrolü, sayısal tutarlılık testi, insan onayı) yerine geçmez. İkisini birlikte kurun.

Önce tek ajanla başlayıp sonra çoklu ajana geçmek mümkün mü?

Mümkün ve önerilen yol da bu. Tek ajanla üretime çıkın, nerede tıkandığını ölçün (bağlam sınırı mı, süre mi, yetki ayrımı mı), ancak ölçülmüş bir açık varsa ikinci ajanı ekleyin.

Peki siz ne yapmalısınız?

Çok ajanlı sistem, ölçülmüş bir sorunun cevabı olduğunda anlam kazanır. Sorunu ölçmeden cevabı satın almayın.

• Tek ajan artı araçlarla başlayın. İkinci ajanı ancak ölçülmüş bir açık (bağlam sınırı, paralellik ihtiyacı, yetki ayrımı) gösterdiğinde ekleyin.
• Okuma ile yazmayı ayırın. Kaynak tarama, belge okuma ve karşılaştırma paralel ajanlara verilebilir; nihai metin, karar ve kayıt tek bir hatta kalsın.
• Bitiş koşulu ve doğrulama yazılı olsun. "İş ne zaman bitti sayılır" ve "çıktıyı kim, neyle kontrol eder" sorularının cevabı teklifte yer almıyorsa sistem üretime hazır değildir.
• İşlem başına maliyeti izleyin. Ortalama ve en kötü durum token harcamasını ilk haftadan itibaren panele koyun; ajan sayısı arttıkça sürpriz fatura riski de artar.
• Çerçeve tartışmasına zaman harcamayın. Görev tanımı ve doğrulama katmanı doğruysa çerçeve ikincil; yanlışsa hiçbir çerçeve kurtarmaz.

Sektörün "ajan ekibi" hikayesi güzel anlatılıyor; ama çoğu şirketin ihtiyacı, iyi araçlarla donatılmış tek bir ajan ve onu denetleyen sade bir kural seti. Elinizde çok ajanlı bir teklif varsa yukarıdaki altı soruyu birlikte üzerinden geçebiliriz; hangi ajanın gerçekten gerekli olduğu genellikle yarım saatte ortaya çıkıyor.