Yapay Zeka Ajanlarını Ekip Rolleri Olarak Tasarlamak

Orkestratör, Değerlendirici, Uzman ve Dokümantasyon.

Bir yapay zeka ajanı, ona yalnızca bir meslek unvanı verdiğimiz için kullanışlı bir ekip üyesine dönüşmez. “Artık proje yöneticisisin”, “Eleştirel değerlendiricisin” ya da “Araştırma uzmanımızsın” ifadeleri rol netliği varmış gibi görünür; ancak sistemin gerçekte nasıl çalışması gerektiği hakkında hâlâ çok az şey söyler. Hangi kararı kim verebilir? Hangi kaynaklar geçerlidir? Hangi araçlara izin vardır? Sonuçta hangi doğrulanabilir artefakt teslim edilmelidir? Hangi belirsizlik görünür kalmalıdır? Rol ne zaman durmalı ve kontrolü bir insana devretmelidir?

Birden fazla yapay zeka rolünün sağlam bir çalışma mimarisi mi oluşturduğu, yoksa sadece farklı adlar verilmiş birkaç sohbet mi olduğu tam olarak bu sorularda belli olur.

Bu nedenle profesyonel rol tasarımı kişilikten değil, sorumluluktan başlar. Rol, sınırlandırılmış bir karar alanı için çalışma sözleşmesidir. Bir ajanın görevin hangi bölümünü üstlendiğini, hangi bağlama ihtiyaç duyduğunu, hangi yetkilere sahip olduğunu, hangi çıktıları teslim etmesi gerektiğini ve çalışmasının neye göre değerlendirileceğini tanımlar.

Bu bakış açısı önemli bir perspektif değişimine yol açar: Mümkün olduğunca insana benzeyen yapay iş arkadaşları tasarlamıyoruz. Bir çalışma sistemi içinde doğrulanabilir işlevler tasarlıyoruz.

Rol, karakter değildir

İnsanlar rolleri sosyal beklentiler üzerinden sezgisel biçimde anlar. Bir editör farklı, bir geliştirici farklı kontrol eder; bir proje yöneticisiyle bir uzman denetçi farklı düşünür. Yapay zeka sistemlerinde bu benzetme, insanlaştırmaya dönüşmediği sürece yararlı olabilir.

Bir dil modelinin mesleki kimliği yoktur. Ona talimatlar, bağlam, araçlar ve izin verilen bir hareket alanı verilir. Bu nedenle “değerlendirici ajan” dediğimizde kişilik özelliklerine sahip yapay bir kişiden söz etmiyoruz. Belirlenmiş kriterlere ve kanıta göre bir çıktıyı incelemekle görevli, işlevsel olarak sınırlandırılmış bir örnekten söz ediyoruz.

Bu ayrım yalnızca kelime seçimi değildir. Rol ne kadar insan benzeri ifadelerle tanımlanırsa kritik teknik sorular o kadar kolay görünmez kalır. “Eleştirel ol” bir değerlendirme kriteri değildir. “Kıdemli mühendis gibi davran” hangi depo yollarına erişilebileceğini tanımlamaz. “Dokümantasyonu üstlen” hangi kararların sürümleneceğini, hangi kaynakların referans gösterileceğini veya hangi değişikliklerin izlenebilir biçimde kayda alınacağını açıklamaz.

İyi bir ajan rolü meslek metaforu olmadan da anlatılabilir:

Girdiyi al → sınırlandırılmış işlevi yürüt → tanımlı çıktıyı üret → kanıt ekle → belirsizliği işaretle → belirlenmiş sınırlarda eskale et.

Meslek adı daha sonra anlaşılır bir etiket olarak eklenebilir. Ancak hiçbir zaman işlevsel sözleşmenin yerini almamalıdır.

Görev listelerinden sorumluluk alanlarına

Ajan tasarımındaki ilk hatalardan biri görevleri yalnızca bölüştürmektir: Ajan A yazar, Ajan B kontrol eder, Ajan C dokümante eder. Bu bir başlangıçtır ama henüz rol mimarisi değildir. Görev listesi yalnızca ne yapılacağını söyler. Rol ise ayrıca neden sorumlu olduğunu ve nelerin açıkça sorumluluk alanı dışında kaldığını netleştirmelidir.

Küçük projelerde bir kişi çoğu zaman üretim, kontrol, dokümantasyon, önceliklendirme ve karar verme gibi birden çok işlevi aynı anda üstlenir. Yapay zeka bu işleri hızlandırdığında bu karışım riskli hâle gelir. Bir taslak üreten sistem, kendi taslağını yeterli ilan eden tek merci olmamalıdır. İş dağıtan bir örnek aynı zamanda her yüksek riskli işlemi gerçekleştirme yetkisine sahip olmak zorunda değildir. Dokümantasyon işlevi de ancak sorun çıktıktan sonra bir sohbetten geriye dönük olarak ne olduğunu tahmin etmeye çalışıyorsa kontrol değerini büyük ölçüde kaybeder.

Bu nedenle en güçlü tasarım ilkelerinden biri orkestrasyon, uzmanlaşmış yürütme, değerlendirme, dokümantasyon ve insan karar yetkisinin işlevsel olarak ayrılmasıdır.

Bu ayrım ilk günden beş ayrı teknik ajan kurulması gerektiği anlamına gelmez. Önce beş sorumluluk işlevini tanımlar. Daha sonra bunların ayrı örneklerde mi, aynı model üzerinde sıralı biçimde mi yoksa kısmen deterministik yazılımla mı uygulanacağı ikinci bir tasarım sorusudur.

Roller organizasyon ile teknoloji arasında sınır nesneleridir

İyi bir rol tanımı iki amacı aynı anda yerine getirir. İnsanlar için organizasyonel olarak anlaşılır, yapay zeka sistemi için ise teknik olarak uygulanabilir olmalıdır.

Organizasyon tarafında soru sorumluluktur: Hangi iş türünden kim sorumludur? Kim onay verebilir? Kim reddedebilir? Kim bilgilendirilmelidir? Teknik tarafta ise somut sınırlar vardır: Rol hangi verileri görebilir? Hangi araçları çağırabilir? Hangi dosyaları değiştirebilir? Hangi çıktıları yapılandırılmış biçimde üretmelidir? Hangi koşullar zorunlu duruş yaratır?

Bu nedenle ajan rolü bir sınır nesnesidir. Organizasyon mantığını çalıştırılabilir sistem mantığına çevirir.

Bu çeviri özellikle önemlidir çünkü doğal dil belirsizliğe çok toleranslıdır. İnsanlar “bunu eleştirel biçimde kontrol et ve değişiklikleri dokümante et” gibi bir cümleden birçok söylenmemiş teamülü tamamlayabilir. Yapay zeka sistemi ise bu teamülleri ancak bağlam, kriter veya yetki olarak görünür hâle getirildiğinde güvenilir biçimde dikkate alabilir.

Süreç riski yükseldikçe rolün sessiz varsayımlara dayanma payı azalmalıdır.

Rol sözleşmesi: Tek bir rol promptu yerine sekiz alan

Rol promptu çoğunlukla tek bir metin bloğudur. Rol sözleşmesi daha yapılandırılmıştır. Daha sonra davranışı, değerlendirmeyi ve sorumluluğu belirleyecek unsurları görünür kılar.

1. Görev

Rol hangi işlevi yerine getirir? Görev, belirsiz bir faaliyet olarak değil sonuç sorumluluğu olarak yazılmalıdır. “Konuyu araştır” ifadesi, “Üç tanımlı soruya ilişkin kanıta dayalı bir durum raporu hazırla; doğrulanmış ifadeleri, açık noktaları ve çelişkili kaynakları ayır” ifadesinden daha zayıftır.

2. Geçerli girdi

Rol hangi sürüm, kaynak ve veri alanıyla çalışabilir? Bu soru, eski taslakların, rastgele sohbet geçmişinin veya onaylanmamış kaynakların karara sessizce karışmasını engeller.

3. Scope ve Non-Scope

Role açıkça neler dahildir ve neler dahil değildir? Non-Scope çoğu zaman uzun bir yetenek listesinden daha değerlidir. Uzmanın kendiliğinden komşu strateji kararlarını üstlenmesini veya değerlendiricinin tüm çözümü yeniden tasarlamasını engeller.

4. Karar yetkileri

Rol hangi kararları kendisi verebilir? Hangilerini yalnızca önerebilir? Hangileri saklıdır? Örneğin bir ajan bir kaynağı yetersiz olarak işaretleyebilir ancak risk tasarımına göre bütün bir belgenin yayımlanmasını tek başına durdurma yetkisine sahip olmayabilir; veya bunun tersi geçerli olabilir.

5. Araç yetkileri

Hangi veri kaynakları, API'ler, dosya yolları, iletişim kanalları ya da eylem araçları kullanılabilir? Okumak, yazmak, silmek, göndermek ve ödeme yapmak farklı risk sınıflarıdır. Araç yetkileri rolü teknik olarak gerçek kılar.

6. Çıktı sözleşmesi

Rol ne teslim etmelidir? Serbest metin çoğu zaman yeterli değildir. Çıktı sözleşmesi sonuç, kaynak, belirsizlik, testler, değişiklikler, açık sorular ve sıradaki karar gibi zorunlu alanlar içerebilir.

7. Kalite ve kanıt kriterleri

Rolün görevini yerine getirdiğini nasıl anlarız? Değerlendirici kriterlere, araştırma ajanı kaynak kurallarına, kod uzmanı testlere, dokümantasyon rolü ise tamlık şartlarına ihtiyaç duyar.

8. Durdurma ve eskalasyon sınırı

Rol ne zaman bağımsız biçimde devam edemez? Zorunlu verilerin eksikliği, çelişkili kanıtlar, belirsiz izinler, geri döndürülemez eylemler veya hedef çatışmaları durdurma koşulları olabilir.

Rol sözleşmesi bu nedenle yalnızca daha uzun bir prompt değildir. Bir işlevin doğrulanabilir en küçük spesifikasyonudur.

Orkestratör hedef ile durumu bir arada tutar

Orkestratör kolayca “baş ajan” olarak yanlış anlaşılır. Oysa temel görevi diğer rollerden daha çok şey bilmek değildir. Hedefi, mevcut proje durumunu ve sıradaki anlamlı işi birbirine bağlamaktır.

Bu nedenle bir uzmandan farklı bağlama ihtiyaç duyar. Hedefi, tamamlanmış işleri, bağımlılıkları, açık engelleri ve çözülmemiş kararları bilmelidir. Her uzmanlık kaynağını ayrıntılı okumak zorunda değildir.

İyi bir orkestratör esas olarak beş soruya yanıt verir: Şu anda hangi duruma ulaşıldı? Bir sonraki anlamlı duruma geçmek için hangi koşul eksik? Bundan hangi rol sorumlu? Bu rol hangi girdilere ihtiyaç duyuyor? Ve sonraki adım öncesinde bir insan kararı gerekiyor mu?

Böylece orkestrasyon mikro yönetim yerine durum yönetimine dönüşür.

Sorun, orkestratörün süper ajana dönüşmesiyle başlar: Bütün kaynaklara, bütün araçlara, bütün yazma yetkilerine sahiptir; görev dağıtır, uzman çalışmasını düzeltir, sonucu onaylar ve ardından kendisi yayımlar. Bu pratiktir ama rol mimarisinin büyük kısmını etkisizleştirir. Tek bir hata veya yanlış yorum en geniş etki alanına ulaşır.

Bu nedenle daha iyi soru “Orkestratör ne kadar güçlü olabilir?” değil, “İşi doğru yönlendirmek için en az hangi yönetim bilgisine ihtiyaç duyar?” sorusudur.

Uzman, sınırlama sayesinde derinleşir

Ajanlarda uzmanlaşma otomatik olarak daha güçlü bir modelden gelmez. Esas olarak daha dar bir problem alanından gelir.

Bir araştırma uzmanı yalnızca belirli bir arayüzün teknik uygulanabilirliğini inceleyebilir. Hukuk uzmanı yalnızca sınırları belirlenmiş bir hukuki soruyu değerlendirebilir. Frontend ajanı yalnızca tanımlanmış bir arayüzü uygulayabilir. İçerik rolü onaylanmış materyalden taslak üretir ve kendi başına yeni stratejik olgusal iddialar eklemez.

Sınırlama kaliteyi iki nedenle artırır. Birincisi, ilgisiz bağlamın kararı sulandırma ihtimali azalır. İkincisi, rolün neden sorumlu olduğu ve neden sorumlu olmadığı açık olduğu için çıktı daha kolay kontrol edilir.

Bu nedenle uzman rolünde açıkça net bir uzmanlık sorusu, tanımlı kaynak veya veri alanı, izin verilen araçlar, bir Non-Scope, beklenen çıktı biçimi ve işin hangi şartlarda tamamlanmış sayılacağı bulunması gerekir.

Non-Scope yoksa tipik bir ajan sorunu ortaya çıkar: yerel optimizasyon. Uzman kendi bölümünü o kadar agresif iyileştirir ki genel hedefi değiştirir. Geliştirici kullanım senaryosu doğrulanmadan zarif bir teknik mimari kurar. Araştırma ajanı karar sorusu çoktan yanıtlanmış olsa da yeni başlıklar eklemeye devam eder. Editoryal ajan yalnızca kontrol edilmesi gereken olguları “iyileştirir”.

Uzmanlaşma sınırsız maksimum uzmanlık değil, bilinçli olarak sınırlandırılmış sorumluluk alanında derinliktir.

Değerlendirici, ölçütü olmayan ikinci görüş değildir

“Bir ikinci model de baksın” hiç kontrol olmamasından iyidir; ancak henüz sağlam bir değerlendirici rolü değildir. Değerlendiricinin kontrol edeceği bir referans noktası olmalıdır.

Bu referans kabul kriterleri, kaynaklar, testler, spesifikasyon, şema ya da tanımlı risk sınıfları olabilir. Böyle bir ölçüt yoksa değerlendirici çoğu zaman yalnızca ikinci bir makul yorum üretir. O zaman elimizde iki görüş olur, daha güçlü kanıt değil.

Profesyonel bir değerlendirici için beş kural çıkarılabilir:

Birincisi: Stil tercihine göre değil, kriterlere göre kontrol eder.

İkincisi: Bulguyu onarımdan ayırır. İyi bir değerlendirici sapmayı belirtir; onu anında değiştirip ilk sorunu görünmez hâle getirmek zorunda değildir.

Üçüncüsü: Hata sınıflarını ayırır. “Yanlış”, “kanıtsız”, “belirsiz”, “test edilmemiş” ve “scope dışında” farklı durumlardır.

Dördüncüsü: Bulgusu için kanıt sağlar: test sonucu, kaynak bölümü, şema çatışması veya kabul kriterinden somut sapma gibi.

Beşincisi: Çıktısı tanımlı bir durumla biter: kabul et, yeniden çalış, eskale et veya bloke et.

Anthropic ajan örüntülerinde benzer bir prensibi evaluator-optimizer olarak tanımlar: Bir örnek üretir, diğeri açık kriterlere göre değerlendirir ve hedefli geri bildirim verir. Buradaki önemli nokta sağlayıcı ya da kalıbın adı değil, üretim ile değerlendirmenin ayrılmasıdır.^[1]

Bu ayrım özellikle “değerlendirici amigo” etkisini önler: Model kulağa iyi gelen bir çıktıyı över fakat onay için bağımsız bir temeli yoktur.

Değerlendirme bağımsızlığı bir tasarım değişkenidir

Sık sorulan bir itiraz şudur: Üretici ve değerlendirici aynı temel model üzerinde çalışıyorsa gerçekten bağımsız sayılırlar mı? Yanıt siyah-beyaz değildir.

İşlevsel bağımsızlık; farklı talimatlar, bağlamlar, yetkiler ve başarı kriterleriyle başlar. Bu bile ciddi değer yaratabilir. Yalnızca spesifikasyonu ve kontrol edilecek artefaktı gören bir değerlendirici, aynı model türü olsa bile üretim sürecinin bütün yaratıcı geçmişini görmüş bir örnekten farklı davranır.

Daha yüksek risklerde teknik veya epistemik bağımsızlık artırılabilir: Farklı model aileleri, deterministik testler, dış kaynaklar, biçimsel doğrulayıcılar veya insan uzman kontrolü kullanılabilir.

Temel ilke şudur: Bağımsızlık, hata riskine orantılı tasarlanmalıdır. Her blog taslağı tamamen ayrı model altyapısı gerektirmez. Fakat güvenlik açısından kritik bir onay, aynı olasılıksal sistemin kendi gerekçesini bir kez daha okumasına bırakılamaz.

Bu deneme bilinçli olarak rol mantığında kalıyor. Tam onay ve gate mimarisi ayrı bir disiplindir.

Dokümantasyon kontrol rolüdür, sekreterlik değildir

Yapay zeka projelerinde dokümantasyon çoğu zaman çok geç devreye girer. Bir sorun çıktıktan sonra hangi sürümün, promptun, kaynağın veya kararın mevcut duruma yol açtığı geriye dönük olarak anlaşılmaya çalışılır.

Dokümantasyon rolü bu mantığı tersine çevirir. İzlenebilirliği çalışmanın sürekli bir parçası olarak ele alır.

Görevi sürümleri işaretlemek, kararları gerekçeleriyle kaydetmek, kaynak referanslarını korumak, iki durum arasındaki değişiklikleri görünür kılmak ve açık belirsizliklerin kaybolmasını engellemek olabilir. Dokümantasyon ajanının her tokeni kaydetmesi gerekmez. Daha sonra anlayış, değerlendirme veya sorumluluk açısından önemli olacak durum değişikliklerini yakalaması gerekir.

İyi dokümantasyon en az altı soruya cevap verir: ne değişti, hangi temelde değişti, değişikliği hangi rol önerdi, hangi kontrol yapıldı, hangi belirsizlik açık kaldı ve şimdi hangi durum geçerli.

Böylece dokümantasyon sorumluluğun hafızasına dönüşür. Projenin yalnızca güncel sohbet daha önce ne olduğunu hatırladığı için tutarlı görünmesini engeller.

Organizasyonel bir avantaj da vardır: Roller değişebilir, modeller yenilenebilir ve oturumlar bitebilir. Çalışma durumu iyi dokümante edilmişse süreç yine de devredilebilir kalır.

Human Authority sürekli gözlem değil, karar hakkıdır

Güçlü derecede ajanlı bir mimaride bile hangi kararların insanda kaldığı net olmalıdır. Bunu “insan en sonda bir kez daha bakar” şeklinde genellemek çoğu durumda çok geç ve çok belirsizdir.

Human Authority, belirli karar sınıflarının açık biçimde devredilmediği anlamına gelir. Proje hedefinin değiştirilmesi, risk kabulü, yüksek maliyet, harici yayımlama, hassas erişim, geri döndürülemez eylemler veya eşdeğer hedefler arasındaki çatışmalar buna dahil olabilir.

Burada bunu yalnızca sorumluluk değil, bir hak olarak tanımlamak önemlidir. İnsan sorumlu tutuluyor ancak sistem ilgili kararların tamamını teknik olarak onsuz gerçekleştirebiliyorsa insan yetkisi yalnızca kâğıt üzerinde kalır.

Sağlam rol mimarisi bu nedenle karar hakkını teknik imkânla bağlar: İnsanın vermesi gereken karar, ajan rolü tarafından sessizce tamamlanamamalıdır.

Bu, insanların her mikro adımı izlemesi gerektiği anlamına gelmez. İyi rol ayrımı insanı bütün model hareketlerinin sürekli seyircisi yapmak yerine doğru noktalarda devreye sokar.

Bağlam erişimi rol tasarımının parçasıdır

Sık görülen hata şudur: Bağlam değerliyse her ajan mümkün olduğunca çok şeyi görmelidir. Profesyonel tasarımda bunun tersi daha iyi olabilir.

Değerlendirici ile üretici aynı bilgilere ihtiyaç duymaz. Dokümantasyon ajanı sürüm ve karar verilerine ihtiyaç duyar ancak her yaratıcı düşünceyi görmek zorunda değildir. Uzman kendi alt problemine ilişkin derin materyale ihtiyaç duyar fakat projenin diğer alanlarının tüm sohbet geçmişine ihtiyaç duymayabilir. Orkestratör güvenilir proje durumuna ihtiyaç duyar ama bütün ham kaynaklara değil.

Role özel bağlamın üç avantajı vardır:

Odak: İlgili bilgi, yan konularla daha az rekabet eder.

İzlenebilirlik: Daha sonra kararın hangi bilgi tabanına dayandığı daha kolay anlaşılır.

Veri minimizasyonu: Hassas bilgiler, işi için gerekmeyen rollere ulaşmak zorunda kalmaz.

Bu nedenle bağlam erişimi sonradan yapılan prompt ayarı değildir. Sorumluluk mimarisinin parçasıdır.

Yararlı bir kural şudur: Her role görevi tam çözmek için gereken en küçük bağlamı ver; ayrıca eksik bağlamı fark etmesini sağlayacak metaveriyi ekle.

Çok az bağlam da çok fazla bağlam kadar tehlikelidir. Rolün boşluğu makul bir tahminle doldurmak yerine ne zaman sorması veya eskale etmesi gerektiğini bilmesi gerekir.

Araç yetkileri rolleri gerçek kılar

Araç sınırları olmayan rol sözleşmesi soyut kalır. Aynı talimata sahip fakat farklı araç yetkileri bulunan iki ajan fiilen farklı rollerdir.

OpenAI de ajanları yalnızca talimatların değil, kullanılabilir araçların, guardrail'lerin ve onayların şekillendirdiği sistemler olarak tanımlar. Rol mimarisi açısından bunun anlamı, araç erişiminin göreve ve riske göre dağıtılması gerektiğidir.^[3]

Araştırma uzmanı web araması ve okuma yetkisi alabilir ancak harici mesaj gönderemez. Değerlendirici test çalıştırabilir ve dosya okuyabilir fakat kontrol ettiği artefaktı sessizce değiştiremez. Dokümantasyon ajanı değişiklik günlüğüne ekleme yapabilir ancak onaylanmış kararı ezemez. Orkestratör iş emirleri üretebilir ancak onaysız maliyetli bir dış işlem başlatamaz.

Böylece Least Privilege üretken bir tasarım ilkesine dönüşür: Her rol yalnızca görevini tam yerine getirmek için gereken araç yüzeyini alır.

Basit bir yetki matrisi bile önemli netlik sağlar:

Somut matris projeye göre değişir. Önemli olan yetkilerin kullanılan aracın tesadüfi özelliklerinden doğmamasıdır.

Ajan adı henüz bir arayüz değildir

Roller birlikte çalışmaya başladığında her rol okunabilir bir arayüze ihtiyaç duyar. Bunun için hemen karmaşık sürü mimarisi gerekmez. İki rol bile neyin devredildiğine dair ortak bir anlayışa ihtiyaç duyar.

Yararlı bir devir nesnesi örneğin şunları içerebilir:

Bu yapı ajanların birbirine yalnızca uzun serbest metin yanıtları aktarmasını engeller. Devir, sohbet artığı değil çalışma durumu olur.

Burada da sınır önemlidir: Devir, sonraki rolün güvenle devam etmesi için yeterli bağlamı taşımalıdır ancak bütün geçmişi otomatik olarak kopyalamamalıdır. Aksi hâlde her devir büyüyen bir bağlam arşivine dönüşür.

Bir sistemde kaç ajan, kaç devir veya kaç paralel yol gerektiği daha sonraki mimari seviyeye aittir. Bu deneme için temel ilke yeterlidir: Rol, giriş ve çıkış arayüzü kadar nettir.

Roller yalnızca metin talimatlarına değil, durum modellerine ihtiyaç duyar

Bir rol kusursuz tanımlanmış olsa bile çalışmanın hangi durumda olduğunu bilmiyorsa hata yapabilir.

Değerlendirici ilk taslak, düzeltilmiş sürüm ve onaylanmış yayın arasındaki farkı bilmelidir. Uzman analizinin keşif amaçlı mı yoksa uygulama kararına hazırlık mı olduğunu anlamalıdır. Dokümantasyon rolü değişikliğin önerildiğini, kabul edildiğini veya reddedildiğini ayırt etmelidir.

Birkaç açık durum değeri uzun sohbet geçmişinden daha yararlı olabilir. Örneğin:

DRAFT → IN REVIEW → REWORK → READY FOR DECISION → APPROVED / BLOCKED

Bu durumlar evrensel standart değildir. Bir ilkeyi gösterir: Roller konuşma metninden mevcut durumun ne anlama geldiğini tahmin etmek zorunda kalmamalıdır.

Durum netliği üç hata sınıfını azaltır: rol eski sürüm üzerinde çalışır, rol öneriyi karar zanneder, ya da rol durdurma veya değerlendirme durumu aktifken çalışmaya devam eder.

Bu nedenle durum netliği iyi rol tasarımının görünmeyen altyapısıdır.

Roller gözlemlenebilir olmalıdır

Rol sözleşmesi ancak daha sonra rolün buna uyup uymadığını anlayabiliyorsak profesyonel hâle gelir. Bu, modelin gizli düşüncelerinin tamamını kaydetmek demek değildir. İlgili davranışı görünür kılmak demektir.

Farklı roller için farklı gözlemlenebilir sorular yararlı olabilir:

İlk günden karmaşık dashboard gerekmez. Yapılandırılmış loglar, değerlendirme alanları ve birkaç tekrarlanabilir test rol kaymasını görünür kılabilir.

Temel fikir basittir: Gözlemlenemeyen davranışı yönetmek ve geliştirmek zordur.

Rol, bir çalışma süreci gibi test edilmelidir

Rol tanımı kulağa iyi geldiği için iyi değildir. Temsili vakalarda denenmelidir.

Dört test türü yararlıdır:

Normal durum

Rol eksiksiz girdilerle temel görevini doğru tamamlayabiliyor mu?

Sınır durumu

Eksik, çelişkili veya belirsiz bilgiyi fark edip hedefli ek bilgi istiyor mu?

Durdurma durumu

Yetkisi veya scope'u dışındaki bir eylemi reddediyor ya da eskale ediyor mu?

Revizyon durumu

Hedefli geri bildirimi uygularken kendi sorumluluk sınırlarını koruyabiliyor mu?

Bu testler rol tasarımını tekrarlanabilir bir öğrenme döngüsüne çevirir: Rolü tanımla, yeni bir çalışma bağlamına yerleştir, gerçek bir alt görev yaptır, çıktıyı kriterlere göre değerlendir ve rol tanımını keskinleştir.

OpenAI Workspace Agents için de gerçekçi normal ve “messy” durumlarla test yapılmasını, eksik bağlamın görünür hâle getirilmesini, talimatların ve guardrail'lerin iteratif biçimde iyileştirilmesini önerir.^[5] Anthropic'in güncel ajan değerlendirmeleri çalışması da çok adımlı ve durum değiştiren ajan davranışlarında sistematik eval yaklaşımının önemini vurgular.^[2]

Kazanan en şık rol promptu değil, davranışı öngörülen sınırlar içinde tekrarlanabilir kalan roldür.

Roller gelişir ve kayabilir

Ajan rolü bir kez yazılıp sonsuza kadar değişmeden kalacak bir doküman değildir. Modeller değişir, araçlar yeni yetenekler kazanır, veri kaynakları dönüşür ve ekipler hatalardan öğrenir. Buna bağlı olarak rolün gözlenen davranışı da kayabilir.

Bu nedenle rolleri küçük operasyon standartları gibi sürümlemek yararlıdır. Bir değişiklik en azından rol sözleşmesinde ne değiştiğini, hangi gözlenen problemin bu değişikliğe yol açtığını, hangi testlerin yeniden çalıştırılması gerektiğini ve değişikliğin scope'u, yetkileri veya eskalasyon mantığını değiştirip değiştirmediğini cevaplamalıdır.

Görünüşte küçük eklemeler özellikle kritik olabilir: “Değerlendirici artık hataları doğrudan düzeltebilir”, “Araştırma ajanı artık e-posta da gönderebilir” veya “Orkestratör bütün proje klasörlerine erişebilir.” Bu tür değişiklikler yeni bir prompt stilinden çok daha fazla mimari etki yaratabilir.

Rol bakımı bu nedenle davranış değişikliklerini prompt büyümesi içinde saklamak yerine bilinçli olarak yönetmek demektir.

Ek bir rol ne zaman gereksizdir?

Rol ayrımı kendi başına amaç değildir. Bir görevi beş ajana bölmek sistemi otomatik olarak daha profesyonel yapmaz.

Ek bir rol özellikle ayrı bir uzman bakışı farklı bağlam gerektiriyorsa, üretim ile değerlendirme ayrılmalıysa, farklı araç yetkileri gerekiyorsa, sorumluluk sınırının organizasyonel olarak görünmesi gerekiyorsa, alt süreç kendi kalite veya kanıt mantığına ihtiyaç duyuyorsa, ya da işlev bağımsız biçimde test edilmek veya ileride değiştirilebilmek isteniyorsa anlamlıdır.

Bu farkların hiçbiri yoksa yeni ajan yalnızca koordinasyon maliyeti yaratabilir. Net bir iç rutine sahip tek ajan veya hatta deterministik workflow daha iyi mimari olabilir.

Bu yaklaşım yeni bir araç bağımlılığını önler: ajan kullanmak için ajan kullanmak.

Yedi tipik tasarım hatası

Yetkisiz persona

“Sen kıdemli değerlendiricisin” ifadesi net görünür ancak kaynak, kriter, araç yetkisi ve durdurma koşulları yoktur. Model güvenilir bir işlev yürütmek yerine rol yapar.

Non-Scope'u olmayan uzman

Güçlü uzman rolü komşu kararları da almaya başlar. Yerel optimizasyon yapar ve fark edilmeden genel projeyi değiştirir.

Her şeyi düzelten değerlendirici

Değerlendirici her bulguyu anında yeniden yazarsa kontrol ile üretim arasındaki sınır kaybolur. Sonradan asıl sorunun ne olduğu zor anlaşılır.

Mesai sonrası dokümantasyon

Kararlar ancak daha sonra sohbetlerden yeniden çıkarılır. Belirsizlikler, reddedilen alternatifler ve değişiklik gerekçeleri kaybolur.

Süper ajan orkestratör

Merkezdeki tek örnek bütün kaynakları, araçları ve karar haklarını alır. Ajan adları vardır ancak işlevsel güçler ayrılığı yok denecek kadar azdır.

Kaynak netliği olmayan ortak hafıza

Bütün roller aynı dev bağlamı görür. Sonradan hangi bilginin kararı etkilediği ya da o rol için onaylı olup olmadığı anlaşılamaz.

Teknik kilidi olmayan insan onayı

Kâğıt üzerinde insanın karar vermesi gerekir. Teknik olarak sistem eylemi zaten gerçekleştirebilir. Sorumluluk ile gerçek kontrol ayrışır.

Bu hataların ortak nedeni rolün kontrol edilebilir bir sistem bileşeni olarak değil, metinsel persona olarak düşünülmesidir.

Örnek: Bir uzmanlık makalesini yayımlamak

Basit bir yayın projesi, hemen karmaşık bir multi-agent sistem kurmadan rol ayrımının nasıl uygulanabileceğini gösterir.

Orkestratör: Makale hedefini, onaylı scope'u, çalışma durumunu ve açık kararları tutar. Araştırma, taslak veya değerlendirme görevleri verir ancak olgusal iddiaları kendi başına değiştirmez.

Araştırma Uzmanı: Onaylanmış kaynaklardan net olgusal soruları yanıtlar. İddia, kaynak, tarih, belirsizlik ve varsa çatışmaları teslim eder. Editoryal tezi belirlemez.

Editoryal Uzman: Onaylı materyalden yazar. Yapı kurabilir, yoğunlaştırabilir ve açıklayabilir ancak yeni olgusal iddia uyduramaz.

Değerlendirici: Tezi, kaynak dayanağını, çelişkileri, sınırları ve yayımlama kriterlerini kontrol eder. Bulgular ve iade gerekçeleri üretir; düzeltmeler görünür revizyon olarak yapılır.

Dokümantasyon: Kaynak durumu, sürümler, değişiklikler ve yayımlama durumunu tutar.

Human Authority: Tartışmalı iddialar, önemli editoryal yön değişiklikleri ve dış yayımlama konusunda karar verir.

Bu ayrımın değeri altı “dijital çalışanın” gösterişli biçimde yan yana çalışması değildir. Değer, üretim, değerlendirme, izlenebilirlik ve kararın artık birbirine karışmış tek bir faaliyet olmamasıdır.

Rol kartı: kompakt çalışma formatı

Pratikte rol sözleşmesinin sayfalarca uzun olması gerekmez. Kompakt rol kartı yeterli olabilir:

İyi rol kartının ilginç bir yan etkisi vardır: İnsan tasarımcıyı çalışma süreci hakkında netleşmeye zorlar. Başta “yapay zeka sorunu” gibi görünen pek çok problem aslında belirsiz sorumluluk, tanımsız kalite ölçütü veya eksik karar yetkisidir.

Bu nedenle rol tasarımı yalnızca prompt engineering değildir. Çalıştırılabilir biçimde organizasyon tasarımıdır.

Altı adımlı uygulama yolu

Gerçek bir projede ajan rolleri kullanmak için hemen karmaşık altyapı kurulması gerekmez.

1. İşlevleri görünür kıl. Bugün hangi işler üretiliyor, kontrol ediliyor, dokümante ediliyor, koordine ediliyor ve karara bağlanıyor?

2. Sorumlulukları ayır. Aynı örneğin her şeyi birden yapması nerede riskli?

3. Rol kartını yaz. Görev, girdi, scope, yetki, çıktı, kalite ve durdurma koşullarını tanımla.

4. Gerçek bir görev test et. Mükemmel demo yerine tipik bir iş vakası kullan.

5. Sınır ve durdurma durumlarını dene. Eksik veri, çelişkili kaynak ve izinsiz eylemleri özellikle test et.

6. Ancak bundan sonra otomatikleştir veya çoğalt. İyi çalışan rol daha sonra daha büyük ajanlı akışa bağlanabilir. Belirsiz rol ise daha fazla orkestrasyonla yalnızca daha hızlı belirsizleşir.

Bu yol genel bir tasarım kuralına dayanır: Daha basit yapı hem yararını hem sınırlarını göstermeden karmaşıklık ekleme.

Gerçek ekip yeteneği sınırlardan doğar

İnsan ekiplerinde ekip çalışması denince iletişim, esneklik ve işbirliği akla gelir. Yapay zeka ajanlarında bunlara bir özellik daha eklenir: sınırlandırılmış sorumluluk.

Ajan her şeyi yapabildiği için daha iyi ekip üyesi olmaz. Diğer roller onun ne yaptığını, ne yapmayacağını ve çıktısının nasıl görüneceğini öngörebildiğinde ekip üyesi olur.

Orkestratör uzmanın scope'u sessizce değiştirmeyeceğine güvenebilmelidir. Uzman hangi sürümün geçerli olduğunu bilmelidir. Değerlendirici bağımsız kriterlere göre kontrol edebilmelidir. Dokümantasyon durum değişikliklerini izlenebilir tutmalıdır. İnsan, saklı kararların gerçekten saklı kaldığından emin olmalıdır.

Böylece tekil modeller iş bölümü yapan bir sisteme dönüşür.

Bu nedenle temel soru “Kaç ajana ihtiyacımız var?” değildir.

Asıl soru şudur: “Hangi sorumlulukları işi devredilebilir, doğrulanabilir ve geri alınabilir kılacak kadar net ayırmamız gerekiyor?”

Ancak roller netleştiğinde sonraki seviye anlamlı olur: Birden fazla ajanın handoff'lar, manager örüntüleri ve paralel yürütme üzerinden koordinasyonu. Sonraki makalenin mimarisi tam olarak orada başlar.

Daha fazla okuma için kamuya açık kaynaklar