Herkesin kendi ajanı olunca ekip neden kötüleşiyor? Anthropic'in çok kullanıcılı ajan deneyinden çıkan dersler

Yapay zeka ajanlarını konuşurken genellikle tek bir kullanıcıyı ve onun ajanını düşünüyoruz: Ben bir görev veriyorum, ajan araçları kullanıp işi bitiriyor. Oysa gerçek hayatta ajanlar giderek ortak alanlarda çalışıyor. Aynı repoya PR açan, aynı CI kuyruğunu kullanan, aynı bulut bütçesinden harcayan ya da aynı ekip takvimine toplantı koyan birden fazla ajan düşünün. Her biri farklı bir kişiyi temsil ediyor ve o kişilerin öncelikleri çatışabiliyor.

Anthropic'in hizalama (alignment) ekibinin 11 Kasım'da yayımladığı "Worse Together" çalışması tam olarak bu senaryoyu ölçüyor. Sonuç kısaca şöyle: Her kullanıcıya ayrı bir ajan verdiğinizde grup, herkese hizmet eden tek bir koordinatör ajana göre daha kötü sonuç alıyor. Ajanlar birbiriyle konuşabildiğinde bile.

Deney nasıl kurulmuş?

Araştırmacılar, ortak bir kaynağın herkesin isteğini karşılamaya yetmediği dört ortam tasarlamış:

• API key: 4, 8 veya 16 araştırmacı, tüm işlerine yetmeyen ortak bir token bütçesini paylaşıyor. Ajanların bazı işleri iptal edip ya da küçültüp diğerlerini teslim tarihine yetiştirmesi gerekiyor.
• Clinic: Acil hastaların paylaştığı bir klinik takvimi.
• Personal assistant: Kullanıcılar ortak bütçeyle grup yemek siparişi, ön ödemeli rezervasyon ya da seyahat planlıyor. Bir kullanıcının özel bir isteği var; örneğin çölyak hastası birinin glütensiz yan yemeğe ihtiyacı.
• Merge queue: Sürüm kesim zamanı olan ortak bir merge kuyruğu.

Her ortam, tek bir koordinatörün genellikle iyi sonuç alacağı şekilde kurulmuş. Böylece ölçülen şey modelin görevi yapabilmesi değil, koordinasyon. Karşılaştırılan düzenler şunlar: tek ajan, herkese hizmet eden koordinatör, kullanıcı başına bir ajan (iletişimsiz) ve kullanıcı başına bir ajan (aralarında mesajlaşma kanalı olan). Test edilen modeller Claude Opus 5, Claude Sonnet 5, GPT-5.6-sol, GPT-5.6-terra ve Qwen3.8-max.

Bulgular: Fark küçük değil

İki Claude modeli için koordinatör, dört ortamın hepsinde mesajlaşabilen ajan ekibini geride bırakıyor. Fark yaklaşık 10 ile 45 puan arasında. En çarpıcı rakamlar API key ortamından geliyor: Opus 5 koordinatör olarak en iyi olası sonucun %64'üne ulaşırken, ekip halinde %30'da kalıyor. Sonnet 5 için bu rakamlar %32 ve %12.

Rakamlardan daha öğretici olan, hataların türü:

1. Ekip büyüdükçe ajanlar susuyor

Ajan sayısı 4'ten 16'ya çıktığında, en az bir kez harekete geçen ajanların oranı Opus 5'te %84'ten %57'ye, GPT-5.6-sol'da %82'den %25'e, Sonnet 5'te ise %66'dan %10'a düşüyor. İnsan ekiplerinden tanıdığımız "başkası halleder" davranışının ajan versiyonu gibi.

2. Başkasının işini sormadan iptal etmek

Bazı modeller diğer kullanıcıların işlerini onay almadan iptal ediyor ya da durduruyor. GPT ve Qwen modellerinde bu, bölüm başına 3,9 ile 7,1 arasında gerçekleşmiş; Sonnet 5'te 0,59, Opus 5'te hiç görülmemiş. Önemli bir not: Puanlama yalnızca toplam tamamlanan değere bakıyor, yani bu davranış skorda cezalandırılmıyor. Sadece sonuca bakan bir değerlendirme bu sorunu tamamen kaçırırdı.

3. Mesaj ulaşıyor ama bağlamda kalmıyor

Personal assistant ortamında koordinatör, özel isteği ekibe göre yaklaşık iki kat daha sık yerine getiriyor. Nedeni ilginç: İstek, siparişi tamamlayan ajana bölümlerin %94-99'unda ulaşıyor ama ödeme anında bağlamında olma oranı yalnızca %47-67. Ajanlar, tüm mesajları okumadan ödemeye geçtiği bir yarış durumu (race condition) yaşıyor. Dağıtık sistemlerle uğraşan herkesin tanıdığı bir sorun.

4. Bilgi boşluğunu uydurmayla doldurmak

Her ajan yalnızca kendi kullanıcısının notlarını gördüğü için, diğer kullanıcılar hakkında desteksiz iddialar üretebiliyor. Claude ekiplerinde bölümlerin %53-58'inde en az bir uydurma iddia bulunurken, tek ajanda bu oran %17-20.

Neler işe yaradı?

Araştırmacılar birkaç önlem denemiş ve etkilerinin ortama göre değiştiğini görmüş:

• Ekip lideri: API key ortamında, yüksek değerli işlere öncelik vermesi ve bütçeyi tam kullanması söylenen ayrı bir lider ajan sonucu belirgin biçimde iyileştirmiş.
• Açık prosedür talimatları: İşleri değere göre sıralamak, ayrılan bütçeyi zamanında serbest bırakmak, liderin dağılımına uymak.
• Platform seviyesinde koruma: En dikkat çekici sonuç bu. Ajanın, okunmamış mesajları okuyana kadar ödemeyi tamamlamasını engelleyen basit bir kontrol, başarısız bölümlerin Opus 5'te %73'ünü, Sonnet 5'te %62'sini kurtarmış. Yalnızca liderin ödeme yapabilmesi ise çok daha sınırlı bir iyileşme sağlamış.

Geliştiriciler için ne anlama geliyor?

Bu çalışma simüle edilmiş kullanıcılarla yapılmış, yani rakamları doğrudan kendi sisteminize taşımamak gerekiyor. Ama ortaya koyduğu desen, ekiplerde ajan kullanmaya başlayan herkes için tanıdık olacak.

Koordinasyonu modele bırakmayın, platforma koyun. En etkili düzeltme daha akıllı bir prompt değil, bir kilit oldu. Ortak kaynağa yazan her ajan aksiyonu için klasik eşzamanlılık araçlarını düşünün: Okunmamış olayları işlemeden commit etmeyi engelleyen kontroller, iyimser kilitleme, sürüm numaralı kaynaklar. Bir merge kuyruğunda ya da bütçe sisteminde bu kontrolleri yazmak, ajana "lütfen önce mesajları oku" demekten çok daha güvenilir.

Başkasının kaynağına dokunmayı açık izne bağlayın. Bir ajan başka bir kullanıcının işini iptal edebiliyorsa, bunu yetki modelinde ayrı bir işlem olarak ele alın. Örneğin CI'da bir ajanın kendi başlattığı job'ları iptal edebilmesi ile başkasınınkini iptal edebilmesi aynı izin olmamalı.

Sadece sonuca bakarak değerlendirmeyin. Çalışmanın en güçlü mesajlarından biri bu: Toplam çıktı iyi görünürken ajanlar onaysız iptaller yapıyor veya uydurma bilgi aktarıyor olabilir. Ajan loglarında "kimin adına, kimin kaynağına dokundu" sorusunu ayrıca izlemek gerekiyor.

Mümkünse tek koordinatör, ama tek güvence olarak değil. Paylaşılan bir kaynağı yöneten tek bir ajan pek çok senaryoda daha iyi sonuç veriyor. Ancak yazarlar da bunun her zaman uygulanabilir olmadığını ve çok kullanıcılı riskleri tek başına çözmediğini vurguluyor.

Kendiniz deneyebilirsiniz

Ekip, ortamların üçünü (API key, clinic, personal assistant) ve 74 senaryoyu MAMUBench adıyla MIT lisansıyla GitHub'da yayımladı; merge queue ortamı da repoda çalıştırılabilir halde ama bu 74 senaryonun içinde değil. Kurulum uv ile yapılıyor ve hem Anthropic hem OpenAI hem de OpenRouter modelleriyle çalışabiliyor:

uv sync --python 3.12
.venv/bin/python run.py api_key --print-info

Varsayılan arka uç Modal, ama --backend local ile kendi makinenizde de çalıştırabilirsiniz. Ekibinizde ajanlar ortak bir kaynağa erişmeye başladıysa, kendi modelinizi ve prompt yapınızı bu ortamlarda denemek, sorunlar üretimde ortaya çıkmadan önce iyi bir ön test olabilir.

Çok ajanlı sistemler genelde paralellik ve hız vaadiyle anlatılıyor. Bu çalışma, ajanlar farklı insanları temsil ettiğinde bu sistemlerin dağıtık sistemlerin bildik sorunlarını da beraberinde getirdiğini hatırlatıyor: yarış durumları, tutarsız durum bilgisi ve sahiplik belirsizliği. İyi haber şu ki bu sorunların çoğu için elimizde onlarca yıllık mühendislik birikimi var.