Yapay zeka ajanı mı, sabit iş akışı mı? Üç mimari, dört soru ve ajan tasarım kartı

"Ajan" kelimesi neden bulanık?

Yapay zeka ajanı kelimesi bugün iki farklı şeyi birden anlatıyor: kendi kararlarını veren özerk bir sistemi ve yalnızca önceden yazılmış adımları izleyen bir akışı. Anthropic bu karışıklığı mimari bir ayrımla çözüyor. Anthropic'e göre iş akışları, LLM'lerin ve araçların önceden yazılmış kod yolları üzerinden yönetildiği sistemlerdir; ajanlar ise LLM'in kendi süreçlerini ve araç kullanımını dinamik olarak yönlendirdiği, görevi nasıl tamamlayacağı üzerindeki kontrolü elinde tuttuğu sistemlerdir (Anthropic, "Building effective agents", 19 Aralık 2024; çeviri bize ait). Anthropic ajanın uygulamasının çoğu zaman basit olduğunu da ekliyor: ajanlar tipik olarak ortamdan gelen geri bildirimle bir döngü içinde araç kullanan LLM'lerdir. Yani fark zekâda değil, kontrolü kimin yürüttüğünde: kodunuz mu, model mi.

Microsoft Learn aynı konuyu başka bir ölçekle sınıflıyor: doğrudan model çağrısı, araçlı tek ajan ve çok ajanlı orkestrasyon. İki sınıflama aynı şeyi ölçmüyor; aşağıda yan yana okuyacağız.

Sohbet botu ile ajan arasındaki fark ayrı bir soru; onu yapay zeka entegrasyonu sayfamızdaki ilgili yanıtta anlattık, burada yinelemiyoruz. Bir yapay zeka özelliğinin canlıya çıkıp çıkamayacağı da ayrı bir soru; onu canlıya çıkmadan önce kontrol listesi yanıtlıyor. Bu yazı bir önceki adımı ele alıyor: bu iş ajan olmalı mı, olacaksa neye yetkili olmalı?

Üç yapı, tek tablo

Tablo üç mimariyi aynı boyutlarla karşılaştırıyor. Hücrelerdeki yargılar bizim mühendislik okumamızdır; Anthropic ve Microsoft sayfaları bunları tablo olarak vermez.

Haritalama da bizim okumamız: Microsoft'un seviye tablosunda doğrudan model çağrısı ilk sütuna, araçlı tek ajan ve çok ajanlı orkestrasyon son sütuna denk gelir; sabit iş akışı ortadaki sütundur ve o tabloda ayrı bir seviye olarak geçmez.

Her iki kaynak da aynı yöne bakıyor. Microsoft, gereksinimlerinizi güvenilir biçimde karşılayan en düşük karmaşıklık seviyesini kullanmanızı söylüyor ve istem mühendisliği sorunu çözebiliyorsa ajana ihtiyacınız olmadığını ekliyor. Anthropic, mümkün olan en basit çözümü bulmayı ve karmaşıklığı yalnızca gerektiğinde artırmayı öneriyor; bunun "hiç ajan sistemi kurmamak anlamına gelebileceğini" de yazıyor. Aynı sayfa, ajan sistemlerinin çoğu zaman gecikme ve maliyeti daha iyi görev başarımıyla takas ettiğini belirtiyor ve birçok uygulamada tek LLM çağrısını bilgi getirme ve bağlam içi örneklerle iyileştirmenin genellikle yettiğini ekliyor.

İş akışı desenleri: birçok iş burada biter

Ajan döngüsüne geçmeden önce sabit akışın neler yapabildiğine bakın. Anthropic, iş akışı sınıfında beş desen sayıyor; her biri tek cümleyle ve "ne zaman" sorusuyla:

• İstem zincirleme. Görev sabit alt görevlere bölünür, her çağrı öncekinin çıktısını işler, ara adımlara programatik kontrol konabilir. Görev temiz biçimde sabit parçalara bölünebiliyorsa.
• Yönlendirme. Girdi sınıflanır ve uzman bir sonraki adıma gönderilir. Birbirinden ayrı kategoriler varsa ve sınıflandırma doğru yapılabiliyorsa.
• Paralelleştirme. Bağımsız alt görevler aynı anda çalışır ya da aynı görev birkaç kez çalıştırılıp sonuçlar kodla birleştirilir. Hız ya da daha yüksek güven için birden çok bakış gerekiyorsa.
• Orkestratör ve işçiler. Merkezdeki bir model alt görevleri çalışırken belirler ve işçilere dağıtır. Anthropic bunu da iş akışı sayıyor; alt görevleri önceden öngöremediğiniz yerde işe yarıyor, yani ajana en yakın desen bu.
• Değerlendirici ve iyileştirici. Bir çağrı üretir, bir diğeri döngüde geri bildirim verir. Net bir değerlendirme ölçütünüz varsa ve yinelemeyle ölçülebilir iyileşme geliyorsa.

Desenler birleştirilebilir; Anthropic bunları buyurucu kalıplar değil ortak desenler olarak sunuyor ve karmaşıklığın ancak sonucu ölçülebilir biçimde iyileştirdiğinde eklenmesini söylüyor. Sabit akışı hazır bir araçla mı kuracağınız, ayrı bir karar: n8n ve Zapier ne zaman yetmez yazımız eşikleri belgeleriyle birlikte anlatıyor.

Dört soruda karar: yapay zeka ajanı mı, iş akışı mı?

Aşağıdaki dört soru sizin işinizde sizin cevaplayacağınız sorulardır. Bir ürünü, bir süreci ya da bir teklifi bu sorulara tutarak okuyabilirsiniz. Birinci soruda "evet" ajandan uzaklaştırır; diğer üç soruda "evet" ajanı mümkün kılar.

Dört cevabı birlikte okumak için ikinci bir tablo:

Bu tablo mühendislik yargımızdır, standart değildir. Sonuç ne olursa olsun karar sizin işinizin ölçüsüne göre verilir.

Dört sorunun en sık yanlış okunan yerleri şunlar (bizim yargımız):

• 1. soru. Çok adımlı olmak ajan gerekçesi değildir; ölçüt adım sayısı değil, adımların önceden yazılabilmesidir.
• 2. soru. "Teknik olarak geri alınabilir" ile "sonucu geri alınabilir" aynı şey değildir: gönderilmiş bir ileti silinse bile okunmuş olabilir.
• 3. soru. "Kullanıcı şikâyet ederse anlarız" bir ölçüm yöntemi değildir.
• 4. soru. Bütçeyi tek bir istek için değil, beklediğiniz tüm kullanım için düşünün.

Dört soruyu üç kurgusal işe uygulamak

Aşağıdaki üç iş kurgusaldır; hiçbiri bir müşterimiz ya da projemiz değildir. Amaç, soruların nasıl okunduğunu göstermek.

Gelen faturaların kayda işlenmesi. Adımlar önceden yazılabilir: belgeyi oku, alanları çıkar, kuralla doğrula, kaydı oluştur. Birinci soru "evet", sonuç sabit iş akışı. Model en fazla alan çıkarma adımında yer alır; kaydı oluşturan kod sizindir.

Serbest metinli müşteri talebine yanıt ve iade. Yanıt taslağı hazırlamak geri alınabilir ve örnek talepler ile beklenen yanıtlarla ölçülebilir. İade başlatmak ise geri alınamayan, para içeren bir eylem. Birçok talep için kategoriye yönlendirme ve taslak yetiyor, yani iş akışı. İade önerisi bir ajandan gelse bile ikinci soru "hayır" olduğu için karar insan onaylı ajanın ötesine geçmez.

Bilinmeyen bir hata kaydının araştırılması. Gereken adımlar önceden bilinmiyor: günlüklere, koda, belgelere bakmak ve bir hipotezi sınamak gerekebilir. Araçların hepsi salt okuma, çıktı yalnızca bir rapor. Birinci soru "hayır", ikinci soru "evet". Üçüncü soru belirleyici: raporun doğruluğunu geçmiş olaylarla ölçemiyorsanız önce ölçüm gerekir. Ölçebiliyorsanız dördüncü soruya bakılır: her araştırma için adım, çağrı ve maliyet üst sınırı koyabiliyorsanız tablo "ajan; dar araç, kısa ömürlü yetki, üst sınırlarla" der, koyamıyorsanız sabit iş akışı ya da tek çağrı.

Üç örnekte de karar, işin kendi cevaplarından çıkıyor; "yapay zeka kullanıyoruz" demenin bir ağırlığı yok.

Ajana verilecek yetkiyi tasarlamak

OWASP'ın "Excessive Agency" maddesi sorunun kökünü üçe ayırıyor: fazla işlev, fazla yetki, fazla özerklik. Biz bunu üç tasarım alanına çeviriyoruz.

Araç envanteri (fazla işlev). Ajana yalnızca gerekli araçları verin. Araçlar dar olsun, okuma ve yazma ayrı araçlar olsun. OWASP, "kabuk komutu çalıştır" ya da "adres getir" gibi açık uçlu araçlardan kaçınmayı, yerine ayrıntılı işlevler kullanmayı öneriyor. Bir araç yalnızca belgeleri okuyacaksa silme ve değiştirme işlevi de taşımamalı.

Kimlik (fazla yetki). Araç, işlemi yapan kullanıcının bağlamında ve gereken en az yetkiyle çalışsın; herkesin verisine erişen genel bir yüksek yetkili kimlik kullanmasın. Mühendislik yazımızda anlatılan altyapı sisteminde bu ilke daha da ileri gidiyor: ajanın elinde kalıcı bir kimlik bilgisi yok, yetki uygulama anında onaylanmış plana bağlı, kısa ömürlü bir kimlik bilgisiyle veriliyor. Anahtarların koda ve istemci paketine sızması ayrı bir tehlike; onu vibe coding denetiminde ele aldık.

Özerklik. Her eylemi üç sınıftan birine yazın: otomatik, insan onaylı, yasak. OWASP, yüksek etkili eylemlerde insan onayını ve yetkilendirmenin modelin değil, alttaki sistemlerin elinde olmasını öneriyor. Metne göre, bir eylemin izinli olup olmadığına karar vermeyi LLM'e bırakmak yerine yetkilendirme alttaki sistemlerde uygulanmalı.

Mühendislik yazımızdaki altyapı sisteminden yalnızca yapısal deseni alıyoruz, rakamsız: ajanın bulut sistemine giden bir ağ yolu yok, ürettiği tek çıktı bir plan ve planın uygulanıp uygulanmayacağına akıl yürütmeyen deterministik bir kapı karar veriyor. Ürününüz bir destek asistanı ya da kayıt güncelleyen bir akış olabilir; ilke aynı: zorlama yoluna olasılıksal bir bileşen koymayın. Bu bölümün kontrol listesi karşılığı 14 maddelik listenin 7. ve 8. maddesidir; burada yinelemiyoruz.

Onay kapısı da tasarım ister; onay ekranı yalnızca bir "onayla" düğmesi olmamalı. Onaylayan kişi ajanın önerdiği eylemi, etkilenecek kaydı, değişikliğin önceki ve sonraki halini, ajanın gerekçesini ve geri alma yolunu görmeli. Bunlar ekranda yoksa onay, aşağıda anlatılan lastik damga riskine yaklaşır. Bu bizim yargımız; OWASP yalnızca yüksek etkili eylemlerde insan onayını söylüyor.

Eylem sınıfı ve önerilen yetki, küçük bir tablo olarak:

Bu sınıflama bizim yargımızdır; OWASP örnekleri (e-posta gönderme, içerik yayımlama, silme) onay gerektiren eylemler olarak anıyor.

Ajanı değerlendirmek ve izlemek

Sonucu ve izi ayrı değerlendirin. "Sonuç doğru muydu?" ve "doğru yoldan mı gitti?" farklı sorulardır. Anthropic, ajanların her adımda ortamdan gerçek veri (araç sonucu, kod çalıştırma çıktısı) alarak ilerlediğini ve planlama adımlarının açıkça gösterilmesini öneriyor; izi okuyabilmek bunun karşılığı. Ajanı canlıya almadan önce güvenli bir ortamda test etmek de Anthropic'in önerisi. Sonuç ve iz için ayrı ölçüt yazmak bizim yargımız. Örneğin iade önerisi doğru olsa bile ajan müşterinin başka bir kaydını okuduysa sonuç doğru, iz yanlıştır; yalnızca sonucu ölçen bir set bunu görmez.

Durma koşulu ve üst sınır olmadan döngü kurmayın. Anthropic ajanlarda azami yineleme sayısı gibi durma koşullarının yaygın olduğunu, Microsoft ise sonsuz araç çağrısı döngülerine karşı yineleme sınırı konmasını yazıyor. Sınırın değeri sizin işinize bağlı; biz bir rakam önermiyoruz.

"Bunu neden yaptı?" sorusuna kayıt tutun. Mühendislik yazımızdaki sistem her karar için şunları kaydediyor; kendi ajanınız için de aynı alanları isteyin:

• model ve sürümü,
• kullanılan istem,
• getirilen belgelerin kimlikleri,
• araç çağrıları ve sonuçları,
• onaylayan kişinin kimliği.

Yazının nitel gözlemi: kayıt olmadan insan onayı yavaşlar, yavaş inceleme de er geç lastik damgaya kayar. Yani kayıt yalnızca denetim için değil, onay kapısının işlemesi için de gerekli.

Değerlendirme setinin nasıl kurulacağını ve nasıl okunacağını kontrol listesindeki 3. madde ve değerlendirme seti şablonu anlatıyor; burada kopyalamıyoruz.

Düşünmenin faturası: ajanı iş akışına derlemek

Mühendislik yazımızdaki sistemden, yine rakamsız, bir ders: her kararı tam bir akıl yürütme döngüsüyle çözmek hem pahalı hem yavaştır. Yazıya göre kararlar çoğunlukla az sayıda şekle yığılıyor. Bir karar şekli kararlı bir sonuçla tekrar ettiğinde parametreli bir iş akışına, yazının deyimiyle playbook'a derleniyor. Playbook'a oturmayan karar hızlı ve ucuz bir modele, şekli ıskalayan ya da güveni düşük karar güçlü bir modele gidiyor. Güçlü modele yükselen karar payı da kaymanın öncü göstergesi: bir ortamda bu pay artıyorsa o ortam daha önce görülen şekillerin dışına çıkıyor demektir.

Bizim okumamız şu: ajanı keşif için kullanıp tekrar eden deseni sabit akışa çevirmek, "ajan mı iş akışı mı" sorusunu bir kez değil sürekli sormak demektir. Ajan olarak başlayan bir iş zamanla sabit akışa dönüşebilir; ajan yalnızca hâlâ öngöremediğiniz kenarda kalır. Bu yaklaşımın sizin işinizde işleyip işlemediğini kendi kayıtlarınız gösterir.

Ajan tasarım kartı

Aşağıdaki tabloyu kopyalayıp her ajan adayı için doldurun. İkinci sütun, o satıra ne yazacağınızı söyler.

Kullanım: kartı iş sahibi, mühendis ve güvenlikten sorumlu kişi ayrı ayrı okuyup doldursun. Kartta boş kalan her satır açık bir karardır; bir satırı yazamıyorsanız ajan o konuda hazır değildir. Amaç ve "neden ajan" satırları yazılamıyorsa kart henüz bir tasarım değildir. İlk sorunun cevabı "evet" çıkarsa "ajan gerekmiyor" kararı da geçerli bir sonuçtur ve kartın tek satırı bu olabilir.

Biz bunu nasıl yapıyoruz

Her proje, onayladığınız yazılı teklifle başlayan ücretli bir çalışmadır. Kapsam, takvim ve maliyet, herhangi bir ücretlendirme başlamadan önce yazılı olarak elinizde olur; onayınızdan önce tahsilat yoktur. Yapay zeka projelerinde en çok değer ilk iki adımda üretilir, çünkü yapay zekanın neyi çözeceği ve neyi çözmeyeceği orada belirlenir. Yapay zekanın doğru çözüm olmadığı bir durumla karşılaşırsak bunu da söyleriz. Hatayı baştan tasarımın bir girdisi sayarız; yanlışın bedeli yüksekse sistem karar vermez, öneri sunar ve eylem insan onayına bağlanır. Her teknik kararın nedenini yazılı hale getiririz. Kodunuzu yazan mühendisle doğrudan konuşursunuz. Hazır bir sohbet botu aboneliği işinizi görüyorsa özel bir yapıya gerek yoktur ve bunu söyleriz. Kapsam yazılı teklifte belirlenir. Adımları Süreç sayfasında, yapay zeka tarafını yapay zeka entegrasyonu sayfamızda anlatıyoruz. Projenizi anlatın.

Sık sorulan sorular

Yapay zeka ajanı nasıl kurulur, nereden başlanır?

Önce yukarıdaki dört soruyu cevaplayın. Sıklıkla başlangıç sabit bir iş akışıdır; ajan döngüsü ancak adımları önceden yazamadığınız bölüm için eklenir. İlk sürümün kapsamını küçük tutmak için MVP geliştirme yaklaşımı yardımcı olur. Ajan tasarım kartının ilk iki satırı doldurulamıyorsa kurulumdan önce işin tanımına dönün. Hangi çerçeveyle ya da hangi modelle kurulacağı, bu karardan sonra gelen ve işin riskine, verisine ve maliyetine göre değişen ayrı bir sorudur; bu yazı onu seçmiyor.

Ajan ile iş akışı arasındaki fark nedir?

Anthropic'in ayrımıyla: iş akışında LLM'ler ve araçlar önceden yazılmış kod yolları üzerinden yönetilir, ajanda LLM kendi süreçlerini ve araç kullanımını dinamik olarak yönlendirir. Sohbet botu ile ajan arasındaki farkı yapay zeka entegrasyonu sayfamızdaki yanıtta anlattık.

Bir ajana hangi eylemleri yaptırmalı, hangilerini onaya bağlamalı?

Bazı eylemleri kendi başına yapabilir; asıl soru, yapmasına izin verilen eylemlerin sınırıdır. Geri alınamayan ya da dış dünyaya etki eden eylemler için öner ve uygula ayrımı, insan onayı ve onay kuralını model dışında bir kapıya koymak gerekir. Hangi eylemin hangi sınıfa gireceğini işin sahibiyle birlikte yazılı olarak belirleyin ve ajanın aracına değil, aracın arkasındaki sisteme zorlatın. Eylem sınıfı tablosu yukarıda; ayrıntısı kontrol listesinin 8. maddesinde.

Çok ajanlı sistem ne zaman gerekir?

Microsoft'un yazdığı gibi gereksinimlerinizi güvenilir biçimde karşılayan en düşük karmaşıklık seviyesini kullanın. Çok ajanlı orkestrasyon, tek ajanın istem karmaşıklığı, araç fazlalığı ya da güvenlik gereksinimleri yüzünden işi güvenilir yapamadığı yerde gerekçelendirilebilir. Önce tek ajan ya da sabit akışla ölçün; neden yetmediğini yazılı gösteremiyorsanız çoğul ajan gerekmiyordur. Bu son cümle bizim yargımızdır.

Ajanın yaptığı bir işin nedeni sonradan nasıl anlaşılır?

Kayıt tutarak: model ve sürüm, istem, getirilen belge kimlikleri, araç çağrıları ve sonuçları, onaylayan kimlik. Bu alanlar olmadan "bunu neden yaptı" sorusunun cevabı bir tahmine döner. Kartın "Kayıt" satırı bunun için var. Kaydı ajanı yazdıktan sonra eklemek zordur; en baştan tasarıma koyun, çünkü onay kapısındaki kişi de gerekçeyi aynı kayıttan okuyacaktır.

Kaynaklar

Aşağıdaki sayfalar 6 Kasım 2026'da açılıp okundu. Anthropic sayfası, bu yazıda anlatılan araç ortamının Aralık 2024'ten beri değiştiğini belirten bir not taşıyor; biz yalnızca mimari ayrımı ve ilkeleri kullandık.

• Anthropic, Building effective agents (19 Aralık 2024).
• Microsoft Learn, AI agent orchestration patterns (sayfa tarihi 12 Şubat 2026).
• OWASP GenAI Security Project, LLM06:2025 Excessive Agency (son değişiklik 5 Mayıs 2025).
• C.E.O. Bee mühendislik yazısı: Eylem Değil Öneri: Otonom Altyapı Agent'larının Arkasındaki Kontrol Düzlemi.