AI Ajanları Nasıl Çalışır? Agentic AI'a Mühendis Bakışı

Bir AI ajanı, hedefi verilen ve o hedefe ulaşmak için hangi adımları atacağına kendi karar veren bir sistemdir. Tanımın can alıcı kısmı "kendi karar veren" değil, aslında döngü: model bir araç çağırır, sonucu görür, ona bakarak bir sonraki adıma karar verir ve bu, hedefe ulaşana veya durdurma koşuluna takılana kadar sürer.

Bu döngü, bir LLM özelliğini niteliksel olarak farklı bir şeye dönüştürür. Tek atışlık bir çağrıda en kötü ihtimal yanlış bir cümledir. Döngüde en kötü ihtimal, on beş adım boyunca yanlış yöne giden, her adımda para harcayan ve yol boyunca gerçek sistemlerde değişiklik yapan bir süreçtir. Bu yazı, o döngüyü güvenli ve öngörülebilir kurmakla ilgili. Temeller için önce LLM tabanlı uygulama geliştirme yazısına bakmanı öneririm.

Ajan olmayan şeyler

Sınırı netleştirmek, gereksiz karmaşıklıktan kaçınmanın en kolay yolu. Aşağıdakiler ajan değildir ve çoğu problem için bunlardan biri doğru cevaptır:

Altın kural: akışı önceden çizebiliyorsan ajan kurma, zincir kur. Zincir öngörülebilir, ucuz, test edilebilir ve hata ayıklaması kolaydır. Ajan, ancak "kaç adım süreceğini ve hangi sırayla gideceğini bilmiyorum" diyebildiğin yerde karşılığını verir.

Temel döngü

Ajan mimarisi, ne kadar karmaşık görünürse görünsün, şu dört adımın tekrarıdır:

1. 1Düşün. Model, hedefi ve şimdiye kadarki gözlemleri görür, bir sonraki eylemi seçer.
2. 2Çağır. Model bir araç adı ve argümanlar üretir; senin kodun o aracı çalıştırır.
3. 3Gözlemle. Aracın sonucu (veya hatası) modelin bağlamına eklenir.
4. 4Karar ver. Hedefe ulaşıldı mı? Ulaşıldıysa dur ve cevapla; ulaşılmadıysa başa dön.

def run_agent(goal: str, tools: dict, max_steps: int = 8, budget_usd: float = 0.50):
    messages = [{"role": "user", "content": goal}]
    spent = 0.0

    for step in range(max_steps):
        reply, cost = model.call(messages, tools=describe(tools))
        spent += cost
        # Bütçe, adım sayısından daha güvenilir bir fren: pahalı bir araç
        # az adımda da faturayı patlatabilir.
        if spent > budget_usd:
            return Halt(reason="budget_exceeded", step=step, spent=spent)

        if reply.is_final:
            return Done(answer=reply.text, steps=step + 1, spent=spent)

        call = reply.tool_call
        if call.name not in tools:
            messages.append(observation(f"Bilinmeyen araç: {call.name}"))
            continue
        # Yetki kontrolü BURADA, modelin önerisine bakarak değil oturuma bakarak.
        if not authorized(session.user, call.name, call.args):
            messages.append(observation("Bu işlem için yetkin yok."))
            continue

        result = safe_invoke(tools[call.name], call.args)
        messages.append(observation(result))

    return Halt(reason="max_steps", step=max_steps, spent=spent)

Bu otuz satırda, ajan sistemlerinin sonraki bölümlerde tek tek açacağım bütün kritik kararları var: adım sınırı, bütçe sınırı, bilinmeyen araç, yetki kontrolü ve güvenli çağrı. Bir ajan çerçevesi kullansan da kullanmasan da bu beşinin karşılığı mutlaka olmalı.

Araç tanımı: modelin gördüğü tek şey

Model, aracının kodunu görmez. Yalnızca adını, açıklamasını ve parametre şemasını görür. Yani araç tanımı bir API dokümantasyonu değil, modele verilmiş bir talimattır ve kalitesi doğrudan doğru araç seçimine dönüşür.

İyi bir araç tanımının özellikleri:

• Tek iş yapar. manage_order kötü bir araçtır; get_order, cancel_order, update_shipping_address iyi araçlardır. Model çok amaçlı araçlarda yanlış modu seçer.
• Açıklaması ne zaman kullanılacağını söyler. "Siparişi getirir" yetersiz. "Sipariş numarası bilinen bir siparişin durumunu ve kalemlerini getirir. Müşteri adıyla arama yapmaz — onun için search_orders kullan." Modelin en çok ihtiyaç duyduğu bilgi, aracın ne yapmadığıdır.
• Parametreleri dar tipli. Serbest metin yerine enum, tarih için ISO biçimi, kimlik için desen. Şema ne kadar dar olursa model o kadar az uydurur.
• Sonucu özlü. 400 satırlık JSON'u modele geri vermek bağlamı doldurur ve dikkati dağıtır. Yalnızca kararı etkileyen alanları döndür.
• Hatası açıklayıcı. "Error 500" modele hiçbir şey öğretmez. "Sipariş bulunamadı; numara 8 haneli olmalı, verilen: 'ABC'" modelin kendini düzeltmesini sağlar.

{
  "name": "search_orders",
  "description": (
    "Müşteri adı, e-posta veya tarih aralığına göre sipariş ARAR ve en fazla "
    "20 özet kayıt döndürür. Tek bir siparişin ayrıntısı için get_order kullan. "
    "İptal veya değişiklik yapmaz."
  ),
  "input_schema": {
    "type": "object",
    "properties": {
      "query": {"type": "string", "description": "Ad, soyad veya e-posta"},
      "from":  {"type": "string", "format": "date", "description": "YYYY-MM-DD"},
      "to":    {"type": "string", "format": "date"},
      "status": {"type": "string", "enum": ["pending", "shipped", "delivered", "cancelled"]}
    },
    "required": ["query"]
  }
}

Araç seçimi neden yanlış gider

Ajanların en yaygın hatası yanlış aracı seçmek ve nedeni neredeyse her zaman tanım tarafında. Üretimde tekrar tekrar görülen dört desen:

• Çok fazla araç. On beş aracın üstünde model kaybolmaya başlar. Çözüm: araçları bağlama göre filtrele — kullanıcı bir sipariş ekranındaysa muhasebe araçlarını hiç gösterme.
• Birbirine benzeyen araçlar. get_user ve fetch_user_profile aynı anda varsa model rastgele birini seçer. Ya birleştir ya da açıklamalarda farkı çok net yaz.
• Argüman uydurma. Model, elinde olmayan bir sipariş numarası uydurabilir. Çözüm kod tarafında: var olmayan kimlik için anlaşılır bir hata döndür, model düzeltsin.
• Gereksiz araç çağırma. Basit bir soruya cevap verirken de araca uzanmak. Sistem talimatına "Cevabı zaten biliyorsan araç çağırma" eklemek bunu belirgin biçimde azaltır.

Durdurma koşulu: en kritik tasarım kararı

Bir ajanın ne zaman duracağını bilmemesi, üretimde en pahalı hata sınıfıdır. Döngü kendi kendine bitmez; bitmesini sen garanti edersin. En az dört fren olmalı ve bunlar birbirinin yedeği değil, tamamlayıcısıdır.

Dördüncüsü en çok atlanan ve pratikte en çok işe yarayan. Ajanlar sıkıştıklarında aynı eylemi tekrar ederler — sanki farklı bir sonuç gelecekmiş gibi. Son birkaç aracın adını ve argüman hash'ini tutup tekrarı yakalamak, on satırlık bir kontrol ve sayısız boşa harcanan döngüyü önlüyor.

Sistem talimatı: ajanın anayasası

Tek atışlık bir çağrıda sistem talimatı rolü ve biçimi tarif eder. Ajanda ek bir iş yapar: döngü içindeki davranış kurallarını koyar. Bu kurallar olmadan model, mantıklı ama istenmeyen kararlar alır.

Üretimde tekrar tekrar değer üreten kurallar:

• Gereksiz araç çağırma. "Cevabı elindeki bilgiyle verebiliyorsan araç çağırma." Basit ama ölçülebilir biçimde adım sayısını düşürür.
• Belirsizlikte sor, tahmin etme. "Hangi siparişten bahsedildiği belirsizse kullanıcıya sor; rastgele birini seçme." Ajanların en sinir bozucu davranışı, eksik bilgiyi uydurarak doldurmaktır.
• Aynı aracı aynı argümanla tekrar çağırma. Kod tarafındaki tekrar tespitinin prompt tarafındaki karşılığı; iki katman birlikte daha iyi çalışır.
• Başarısızlığı bildir. "Hedefe ulaşamıyorsan, ne denediğini ve neyin eksik olduğunu söyleyerek dur." Yarım kalmış bir görevi tamamlanmış gibi sunmasını engeller.
• Yan etkiyi açıkla. "Bir şey değiştirmeden önce ne değiştireceğini bir cümleyle söyle." İz kaydını okunur kılar ve onay ekranını besler.

Hafıza: ajan ne hatırlar

Ajanın iki tür hafızaya ihtiyacı var ve bunları karıştırmak bağlam penceresini hızla doldurur.

Çalışma hafızası o görevin içindeki gözlemler: hangi araçlar çağrıldı, ne döndü. Bağlamda tutulur ve görev bitince atılır. Uzun görevlerde bu bile şişer; çözüm, eski gözlemleri özetlemek. Ama dikkat: araç sonuçlarını özetlerken sayı ve kimlik gibi kritik ayrıntılar kaybolabilir. Özetleme yerine kırpma çoğu zaman daha güvenli — ilk gözlemi ve son üç gözlemi tut, ortadakileri "5 adım atlandı" notuyla değiştir.

Kalıcı hafıza görevler arası taşınan bilgi: kullanıcının tercihleri, önceki oturumda varılan sonuçlar. Bunu bağlamda değil, bir depoda tut ve ilgili olduğunda getir — yani RAG. Kalıcı hafızayı her göreve otomatik enjekte etmek, hem pahalıdır hem de alakasız geçmişle modeli yanıltır. Getirme mekanizması için RAG nedir yazısındaki desenler doğrudan uygulanabilir.

Planlama: önden mi, adım adım mı

İki yaklaşım var ve seçim görev tipine bağlı.

Önden planlama: model önce bütün adımları listeler, sonra sırayla uygular. Avantajı denetlenebilirlik — planı kullanıcıya gösterip onay alabilirsin, maliyeti önceden tahmin edebilirsin. Dezavantajı kırılganlık: üçüncü adımda beklenmedik bir sonuç geldiğinde plan geçersizleşir ve yeniden planlama mantığı gerekir.

Adım adım: her adımda yalnızca bir sonrakine karar verilir. Değişen koşullara uyum sağlar, ama nereye gittiği önceden belli değildir ve maliyet tahmini zorlaşır.

Pratikte en iyi çalışan melez: önden kaba plan, adım adım uygulama, gerektiğinde yeniden planlama. Plan kullanıcıya gösterilir ve bir onay noktası olur; uygulama esnek kalır; bir adım beklenmedik sonuç verdiğinde model planı günceller. Yeniden planlama sayısına da üst sınır koy — plan sürekli değişiyorsa görev yanlış tanımlanmıştır.

Hatadan kurtulma

Araçlar başarısız olur: ağ hatası, hız sınırı, geçersiz argüman, yetki reddi. Ajanın bu durumlarda ne yapacağı, kalitesini belirleyen ayrıntılardan biri.

Temel kural: hatayı modele anlaşılır biçimde göster, ama tekrar deneme kararını koda bırak. Geçici bir ağ hatasında model üç kez aynı çağrıyı yapmaya çalışırsa üç adım boşa gider; bunun yerine kod içinde geri çekilmeli yeniden deneme yap ve modele yalnızca nihai sonucu ver.

Yetkilendirme: ajanların en ciddi riski

Tek atışlık bir LLM özelliği yanlış bir cümle üretir. Bir ajan yanlış bir eylem gerçekleştirir — kayıt siler, e-posta gönderir, ödeme başlatır. Aradaki fark, hata maliyetinin sınıf atlaması.

Tek kural her şeyi özetliyor: yetki kontrolü araç katmanında, oturumdaki kimliğe bakarak yapılır. Prompt'ta "yalnızca kullanıcının kendi siparişlerini görebilirsin" yazmak bir güvenlik önlemi değil, bir temennidir. Model o cümleyi çoğu zaman uygular; "çoğu zaman", yetkilendirme için yeterli bir garanti değildir.

# YANLIŞ: yetki prompt'ta
SYSTEM = "Kullanıcı yalnızca kendi siparişlerini görebilir. Başkasınınkini gösterme."

# DOĞRU: yetki araç katmanında, argümandan değil oturumdan
def get_order(args, *, session):
    order = db.orders.get(args["order_id"])
    if order is None:
        return ToolError("Sipariş bulunamadı.")
    # Modelin verdiği user_id'ye ASLA güvenme; oturumdaki kimliği kullan.
    if order.user_id != session.user_id and not session.is_support_agent:
        return ToolError("Bu siparişi görüntüleme yetkin yok.")
    return order.summary()

İkinci kural: araçları okuma ve yazma olarak ayır. Okuma araçları serbestçe çağrılabilir; yazma araçları ek koşullara bağlanır — onay, hız sınırı, geri alınabilirlik. Bu ayrımı araç kaydında bir alan olarak tut ki döngü kodu yazma işlemlerini ayrı ele alabilsin.

Prompt injection tarafı da ajanlarda daha tehlikeli hâle gelir: modelin okuduğu bir belge "şu aracı çağır" diyebilir. Bu konunun ayrıntısı AI Security ve OWASP LLM Top 10 eğitiminde; buradaki savunma hattı yine aynı: modelin ne önerdiği değil, kodun neye izin verdiği belirleyici.

İnsan onayı: nereye konur

Her yazma işlemine onay koymak ajanı işe yaramaz hâle getirir; hiçbirine koymamak riskli yapar. Ayrımı geri alınabilirlik üzerinden kur.

• Geri alınabilir ve ucuz (taslak oluşturma, etiket ekleme, not yazma): onay gerekmez.
• Geri alınabilir ama görünür (müşteriye e-posta taslağı hazırlama): onay iyi olur, göstererek yap.
• Geri alınamaz veya pahalı (ödeme, silme, dışarı mesaj gönderme): onay zorunlu.

Onay ekranında modelin ne yapacağını argümanlarıyla birlikte göster. "Ajan bir e-posta göndermek istiyor" yetersiz; alıcıyı, konuyu ve gövdeyi göster. Kullanıcı neyi onayladığını görmüyorsa onay bir güvenlik önlemi değil, sorumluluk aktarımıdır.

Maliyet: ajanlar neden pahalıdır

Bir ajan çağrısı, tek atışlık bir çağrının basitçe birkaç katı değildir. Bağlam her adımda büyür: adım 5'te model, önceki dört adımın bütün gözlemlerini de okur. Yani maliyet adım sayısıyla doğrusal değil, kabaca karesel artar.

Pratik sonuç: adım sayısını azaltmak, en etkili maliyet optimizasyonudur. Bunu yapmanın yolu modeli zorlamak değil, görevleri daraltmak ve araçları daha yetenekli hâle getirmek. Üç ayrı araç çağrısı gerektiren bir işi tek araçta toplamak, üç adımı bire indirir.

• Araç sonuçlarını kırp — 400 satırlık JSON yerine kararı etkileyen 10 alan.
• Eski gözlemleri kırp veya özetle; bağlamı sınırsız büyütme.
• Basit adımlar için küçük model, karmaşık kararlar için güçlü model kullan.
• Sabit sistem talimatını ve araç tanımlarını önbelleğe al — her adımda tekrar gönderiliyorlar.

Maliyet tarafını bütçe disiplini olarak kurmak istersen AI FinOps eğitimi konuyu bu açıdan ele alıyor.

Bağlam yönetimi: adım 6'da ne kaldı

Ajanın bağlamı her adımda büyür ve bu büyüme yalnızca maliyet sorunu değil — kalite sorunu. Sekizinci adımda model, yedi adımlık gözlem yığınının içinde ilk talimatı hatırlamakta zorlanır.

Üç pratik önlem:

1. 1Hedefi tekrarla. Her adımda kullanıcı hedefini bağlamın sonuna yeniden koy. Birkaç yüz token maliyetine, modelin ne yapmaya çalıştığını unutmasını engeller.
2. 2Gözlemleri kırp. Araç sonuçlarının tamamını değil, kararı etkileyen alanları sakla. Uzun bir JSON döndüren aracın çıktısını ikinci adımda tek satırlık özete indirebilirsin.
3. 3Ara özet çıkar. Beşinci adımdan sonra "şimdiye kadar öğrenilenler" başlıklı kısa bir özet üretip eski gözlemleri onunla değiştir. Bu özeti modele ürettirebilirsin, ama kimlik ve sayıların korunduğunu doğrula.

Kırpma yaparken en sık yapılan hata, kritik bir kimliği atmak: model üçüncü adımda bulduğu sipariş numarasını altıncı adımda kullanacaktır. Kırpma mantığına "kimlik benzeri alanları her zaman koru" kuralını koy; yoksa ajan, bulduğu şeyi tekrar aramak zorunda kalır ve döngüye girer.

Gecikme ve kullanıcı deneyimi

Sekiz adımlık bir ajan, her adımda birkaç saniye harcarsa kullanıcı yarım dakika bekler. Boş bir yükleme göstergesiyle yarım dakika, ürünün ölüm sebebidir.

Çözüm, döngüyü görünür kılmak. Her adımda ne yapıldığını kullanıcıya yaz: "Siparişler aranıyor…", "Kargo durumu kontrol ediliyor…". Bu üç şeyi birden sağlar: bekleme kısa hissettirir, kullanıcı ilerlemeyi görür ve ajan yanlış yöne gittiğinde kullanıcı erken müdahale edebilir.

İkinci teknik: uzun süren görevleri asenkron yapmak. Kullanıcı görevi başlatır, ekranı kapatır, iş bitince bildirim alır. Her görev interaktif olmak zorunda değil; bazıları arka planda daha iyi çalışır.

Gözlemlenebilirlik: iz kaydı olmadan ajan hata ayıklanamaz

Tek atışlık bir çağrıda prompt ve cevabı loglamak yeter. Ajanda bu yetmez; bütün yürütmeyi bir iz (trace) olarak kaydetmen gerekir. Kullanıcı "yanlış yaptı" dediğinde cevaba bakmak işe yaramaz — hatanın hangi adımda başladığını görmen lazım.

Bir iz kaydında bulunması gerekenler: görev kimliği, her adımın numarası, modelin verdiği gerekçe, çağrılan araç ve argümanları, aracın sonucu (kırpılmış), adım süresi, adım maliyeti ve nihai durum (tamamlandı / adım sınırı / bütçe / hata).

$ curl -s localhost:8080/traces/tsk_91f2 | jq -r '.steps[] |
    "\(.n)  \(.tool // "final")  \(.ms)ms  $\(.cost)  \(.summary)"'
1  search_orders      812ms  $0.004  query="Ayşe Y." → 3 sonuç
2  get_order          204ms  $0.006  id=88213 → status=shipped
3  get_shipment       190ms  $0.008  carrier=X, last_scan=2 gün önce
4  search_orders      798ms  $0.011  query="Ayşe Y." → 3 sonuç   ← tekrar
5  search_orders      805ms  $0.014  query="Ayşe Y." → 3 sonuç   ← tekrar
6  halt(repeat_detected)
# ✓ Model 3. adımda takıldı: kargo verisi sorusunu cevaplamıyordu,
#   model de baştan aramaya döndü. Sorun araç tanımında.

Bu izde teşhis üç saniye sürüyor. İz olmasaydı, aynı hatayı bulmak için prompt'u elle deneyerek saatler harcanırdı. Ajan sistemlerinde iz kaydı isteğe bağlı bir iyileştirme değil, temel gereksinimdir.

Değerlendirme: ajanı nasıl test edersin

Ajan değerlendirmesi, tek atışlık değerlendirmeden zor; çünkü aynı hedefe farklı yollardan ulaşılabilir ve "doğru cevap" tek bir metin değil.

Üç katmanda ölç:

Sonuç katmanı en önemlisi ve en kolay otomatikleştirileni: sahte (mock) araçlarla çalışan bir test ortamı kur, ajanı elli senaryoda çalıştır, sonunda beklenen durumun oluşup oluşmadığını kontrol et. Sahte araçlar aynı zamanda hata senaryolarını test etmeni sağlar — aracın 500 döndüğü durumda ajan ne yapıyor?

Yol katmanını küçümseme. Doğru cevaba on iki adımda ulaşan bir ajan, üç adımda ulaşandan dört kat pahalıdır ve dört kat yavaştır. Adım sayısı dağılımını izlemek, kalite düşüşünü sonuç bozulmadan önce yakalatır. Değerlendirme altyapısının derinlemesine anlatımı AI Agent Evaluation & Observability eğitiminde.

Bir vaka: kendini tekrar eden ajan

Yukarıdaki iz gerçek bir hata sınıfını gösteriyor, açalım. Destek ekibi için bir ajan: müşteri adına göre sipariş bulup kargo durumunu özetliyor. Testlerde sorunsuz. Üretimde, belirli müşterilerde döngüye giriyor ve bütçe sınırına takılıyor.

Teşhis izde görünüyordu: model get_shipment aracını çağırıyor, araç last_scan ve carrier döndürüyor ama tahmini teslim tarihi döndürmüyordu. Modelden istenen özet ise teslim tarihini içeriyordu. Model, aradığı bilgiyi bulamayınca baştan aramaya dönüyor, aynı sonuçları alıyor ve tekrar deniyordu.

İlginç olan şu: model "mantıklı" davranıyordu. Eksik bilgiyi bulmak için tekrar arıyordu. Hata modelde değil, araç ile görev tanımı arasındaki uyumsuzluktaydı: ondan istediğimiz çıktı, verdiğimiz araçlarla üretilemezdi.

Düzeltme üç parçaydı ve üçü de öğretici. Birincisi, get_shipment aracına tahmini teslim tarihi eklendi — asıl çözüm bu. İkincisi, araç açıklamasına "tahmini teslim tarihi mevcut değilse null döner" cümlesi eklendi, böylece model bilginin yokluğunu bir sonuç olarak kabul edebilsin. Üçüncüsü, tekrar tespiti devreye alındı ki benzer bir uyumsuzluk bir daha bütçe yakmasın.

Ajanın devreye alınışı: kademeli güven

Bir ajanı doğrudan tam yetkiyle üretime almak, en pahalı öğrenme biçimi. Olgunlaşmış ekiplerin izlediği yol kademeli ve her kademenin kendi öğrettiği bir şey var.

1. 1Gölge mod. Ajan çalışır, kararlarını loglar, ama hiçbir eylemi gerçekleştirmez. Gerçek trafikle kaç adım harcadığını, hangi araçları seçtiğini ve nerede saçmaladığını bedavaya öğrenirsin.
2. 2Öneri modu. Ajan ne yapacağını söyler, insan uygular. Onay oranı bir kalite metriğine dönüşür: insanlar önerilerin yüzde doksanını onaylıyorsa sıradaki kademeye geçebilirsin.
3. 3Dar otonomi. Yalnızca geri alınabilir işlemler için tam otomatik. Taslak oluşturma, etiketleme, sınıflandırma.
4. 4Geniş otonomi. Geri alınamaz işlemler de dahil, ama onay eşiğiyle: tutar veya etki belli bir sınırın altındaysa otomatik, üstündeyse insan.

Bu merdivenin en değerli basamağı birincisi ve en çok atlanan da o. Gölge mod, üretimde ne olacağını üretime çıkmadan gösteren tek mekanizma; kurulum maliyeti düşük, öğrettiği şey yüksek. Ajanı gölge modda bir hafta çalıştırıp izleri okumak, aynı süreyi prompt ayarlamakla geçirmekten kıyaslanamayacak kadar verimli.

MCP: araçları standartlaştırmak

Her ajan çerçevesi araçları kendi biçiminde tanımlıyor. Aynı aracı üç farklı sistemde kullanmak isteyince üç kez yazmak gerekiyor. MCP (Model Context Protocol), bu tanımı standartlaştıran açık bir protokol: aracı bir kez bir sunucu olarak yazarsın, protokolü destekleyen her istemci onu kullanabilir.

Pratik faydası, üretim ekipleri için şu üç noktada toplanıyor: araç envanterini merkezî tutabilmek, aynı aracı farklı ürünlerde tekrar kullanabilmek ve üçüncü taraf araçlarını hazır sunucular üzerinden bağlayabilmek. Ayrıntılı bir ele alış ayrı bir yazının konusu; MCP AI araçları eğitim sayfası kapsamı gösteriyor.

Eşzamanlılık ve yarış koşulları

Tek bir ajan tek bir görevde çalışırken her şey düzenli görünür. Aynı anda yüz ajan çalıştığında, klasik dağıtık sistem problemleri geri gelir — ve ajanlar bu problemleri özellikle kötü ele alır, çünkü model yarış koşulunu anlamaz.

Sık karşılaşılan üç durum:

• Aynı kayda iki ajan. İki destek talebi aynı siparişe dokunuyorsa, ikisi de "durumu güncelle" diyebilir. Yazma araçlarına iyimser kilit (sürüm numarası) koy; çakışmada aracı hata döndürsün, model yeniden okusun.
• Hız sınırı paylaşımı. Yüz ajanın aynı anda aynı API'yi çağırması, hız sınırını anında doldurur ve hepsi birden başarısız olur. Araç çağrılarını merkezî bir kuyruktan geçir; her ajanın kendi yeniden denemesi bu sorunu büyütür, çözmez.
• Maliyet patlaması. Adım başına bütçe kontrolü tek görevde çalışır; yüz görev aynı anda başladığında toplam harcama saatler içinde aylık bütçeyi geçebilir. Görev başına bütçenin yanında toplam eşzamanlı harcama tavanı gerekir.

Bu üçünün ortak dersi şu: ajanı bir fonksiyon gibi değil, bir iş yükü gibi düşün. Kuyruk, hız sınırı, geri basınç (backpressure) ve bütçe — hepsi klasik altyapı meseleleri ve hiçbiri model kalitesiyle çözülmüyor. SRE nedir yazısındaki çerçeve burada doğrudan geçerli.

Yan etki yönetimi ve izolasyon

Ajan gerçek sistemlere dokunuyorsa, dokunduğu yeri sınırlamak gerekir. Birkaç pratik desen:

• Kuru çalıştırma (dry run). Yazma araçlarının bir önizleme modu olsun: ne yapacağını döndürsün, yapmasın. Hem test hem onay ekranı için kullanışlı.
• İşlem sınırı. Görev başına en fazla kaç yazma işlemi yapılabileceğini sınırla. Bir ajanın yüz kayıt güncellemesi neredeyse hiçbir zaman istenen şey değildir.
• Geri alma kaydı. Yapılan her yazma işlemini görev kimliğiyle logla ki toplu geri alınabilsin.
• Ayrı kimlik. Ajan kendi servis hesabıyla çalışsın, kullanıcının tam yetkisiyle değil; yetkisi görev için gerekenle sınırlı olsun.

Kod çalıştıran ajanlarda ayrıca izolasyon gerekir: üretilen kodu ana süreçte değil, ağ erişimi kısıtlı ve süresi sınırlı ayrı bir ortamda çalıştır. Konteyner temelleri için Docker nedir yazısı iyi bir başlangıç.

Çoklu ajan: ne zaman gerçekten gerekir

Birden fazla ajanı birbiriyle konuşturmak cazip bir fikir ve çoğu zaman erken bir fikir. Tek bir ajan iyi araçlarla çoğu işi görür; ikinci bir ajan eklemek, koordinasyon, maliyet ve hata ayıklama zorluğu ekler.

Gerçekten yardımcı olduğu üç durum var: farklı araç kümeleri (her ajanın kendi dar alanı ve araçları var), farklı bağlam bütçeleri (bir ajan uzun bir belgeyi işlerken diğerinin bağlamını kirletmemesi) ve farklı yetki seviyeleri (okuma yapan ajan ile yazma yapan ajanın ayrılması).

Bunun dışındaki durumlarda "araştırmacı ajan, yazar ajan, eleştirmen ajan" gibi kurgular genelde tek bir ajanın adımlarına indirgenebilir — ve indirgendiğinde daha ucuz, daha hızlı ve daha kolay hata ayıklanır olur. Konunun ayrıntısı Multi-Agent ve A2A eğitiminde.

Bilgiye erişen ajanlar: RAG ile birleşim

Ajanın araçlarından biri neredeyse her zaman arama olur. Bu birleşim iki yönlü fayda sağlıyor ama bir tuzağı da var.

Fayda tarafı: ajan, tek atışlık RAG'ın yapamadığını yapabilir — arar, sonucu değerlendirir, eksik kalanı görür ve farklı bir sorguyla tekrar arar. Kullanıcının belirsiz sorusunu birden fazla arama turuna bölmek, karmaşık sorularda belirgin fark yaratır. Bu desen bazen "agentic RAG" diye anılıyor ve RAG nedir yazısında ileri varyantlar arasında geçiyor.

Tuzak tarafı: arama aracı bir sonuç döndürdüğünde model onu doğru kabul etme eğiliminde. Getirilen belge alakasızsa bile modelin elinde metin vardır ve ondan bir cevap üretmeye çalışır. Bu yüzden arama aracının boş veya düşük skorlu sonucu açıkça bildirmesi gerekir: "3 sonuç bulundu ama hiçbirinin alaka skoru eşiğin üzerinde değil" demek, sessizce üç alakasız parça döndürmekten çok daha iyidir.

Bir de sınır koyma meselesi var: arama turlarına üst sınır koymazsan, cevabı olmayan bir soru ajanı sonsuza kadar aratır. Tur sayısını ikiyle üçle sınırla ve sonrasında "bulamadım" demesine izin ver.

Ne zaman ajan kullanmamalı

Bu bölüm, yazının geri kalanı kadar önemli. Ajan mimarisi karmaşıktır ve karmaşıklığın bedelini ödemeye değmeyen pek çok durum var.

• Akış sabitse. Adımları önceden biliyorsan zincir yaz. Ajan, bilinen bir akışı öngörülemez hâle getirmekten başka bir şey yapmaz.
• Hata maliyeti yüksek ve geri alınamazsa. Finansal işlem, üretim veritabanı değişikliği — model karar vermesin, insan versin; model en fazla hazırlasın.
• Gecikme kritikse. Sekiz adımlık bir döngü hiçbir senkron istek yolunda kabul edilebilir değil.
• Araçlar yeterli değilse. Yukarıdaki vakadaki gibi: elindeki araçlarla üretilemeyecek bir çıktı isteniyorsa ajan çözüm değil, semptom üreticisidir.
• Gözlemleyemiyorsan. İz kaydı kuramayacaksan ajan çalıştırma; bakımı imkânsız hâle gelir.

Ajanın maliyeti nereye yazılır

Ajan projelerinde sık görülen bir yönetim sorunu: maliyet bir kalemde birikir ve kimse sahiplenmez. Görev başına maliyeti hesaplayıp işin kendisiyle karşılaştırmak, bu tartışmayı somutlaştırmanın en iyi yolu.

Basit bir çerçeve: bir görev ajan tarafından ortalama ne kadara ve ne kadar sürede yapılıyor, aynı görev insan tarafından ne kadar sürede yapılıyor, ajanın çıktısını doğrulamak ne kadar sürüyor? Üçüncüsü en çok unutulan. Bir dakikada üretilen ama beş dakikada kontrol edilmesi gereken bir çıktı, on dakikada elle yapılan işten her zaman daha iyi değildir — özellikle kontrol eden kişi, üretenden daha kıdemliyse.

Bu hesabı ürün kararı olarak kur: hangi görevlerde ajan gerçekten kazandırıyor, hangilerinde yalnızca yeni görünüyor. Cevap zaman içinde değişir; ölçmeye devam et.

Ajanı test ortamında çalıştırmak

Ajan testinin en büyük engeli, gerçek araçların gerçek yan etkileri olması. Çözüm, araç katmanını baştan değiştirilebilir tasarlamak: üretimde gerçek araç, testte aynı şemayı uygulayan sahte araç.

Sahte araçların iyi olması, testin değerini belirliyor. Her zaman başarı döndüren bir sahte araç, ajanın hata davranışını hiç test etmez. En az üç senaryo kur: mutlu yol, boş sonuç ve hata. Üçüncüsü özellikle önemli — ajanların en tuhaf davranışları hata durumlarında ortaya çıkıyor.

class FakeOrderTool:
    """Aynı şema, kontrol edilebilir davranış."""
    def __init__(self, mode: str = "ok"):
        self.mode = mode
        self.calls: list[dict] = []          # çağrı kaydı = testin asıl çıktısı

    def __call__(self, args):
        self.calls.append(args)
        if self.mode == "empty":  return {"orders": []}
        if self.mode == "error":  return ToolError("Servis geçici olarak kullanılamıyor")
        if self.mode == "slow":   raise TimeoutError()
        return {"orders": [{"id": 88213, "status": "shipped"}]}

def test_agent_stops_on_empty_results():
    tool = FakeOrderTool(mode="empty")
    out = run_agent("Ayşe'nin siparişini bul", {"search_orders": tool})
    assert out.status == "done"              # döngüye girmemeli
    assert len(tool.calls) <= 2              # iki denemeden fazlası israf
    assert "bulamadım" in out.answer.lower() # dürüst cevap vermeli

Bu testlerin ölçtüğü şey cevabın metni değil, ajanın davranışı: kaç kez çağırdı, durdu mu, dürüst mü. Metni test etmeye çalışmak kırılgan testler üretir; davranışı test etmek dayanıklı testler üretir. Aynı ayrım, CI/CD boru hattına bağladığında da geçerli — ajan testleri yavaş olabilir, bu yüzden hızlı davranış testleri her PR'da, uçtan uca senaryolar gecelik çalışsın.

Üretime çıkmadan önce kontrol listesi

1. 1Adım, bütçe, süre ve tekrar frenlerinin dördü de var.
2. 2Durdurma koşulu tetiklendiğinde kullanıcıya dürüst bir mesaj dönüyor.
3. 3Yetki kontrolü araç katmanında ve oturumdaki kimliğe bakıyor; prompt'a güvenilmiyor.
4. 4Araçlar okuma/yazma olarak ayrılmış; geri alınamaz işlemler onay istiyor.
5. 5Her yürütme için iz kaydı tutuluyor: adım, araç, argüman, sonuç, süre, maliyet.
6. 6Sahte araçlarla çalışan elli senaryoluk bir değerlendirme kümesi var.
7. 7Adım sayısı ve görev başına maliyet dağılımı izleniyor.
8. 8Ajan kendi servis hesabıyla, görev için gereken asgari yetkiyle çalışıyor.

Ajan yazarken yapılan beş klasik hata

Bu yazıdaki uyarıların pratikteki karşılıkları. Beşi de üretimde tekrar tekrar görülüyor ve beşi de ucuza önlenebilir.

Üçüncü satırı özellikle vurgulamak isterim: iz kaydı olmadan ajan geliştirmek, log'suz bir dağıtık sistemi hata ayıklamaya benziyor. Mümkün ama gereksiz yere acı verici ve her teşhis tahmine dayanıyor.

Sık sorulanlar

Ajan ne kadar otonom olmalı?

Sorunun cevabı teknik değil, ticari: yanlış kararın maliyeti ne kadar? Yanlış etiketlenmiş bir destek bileti ucuzdur, yanlış iade edilmiş bir ödeme değildir. Otonomi seviyesini bu maliyetten türet, modelin ne kadar iyi olduğundan değil. Aynı model, aynı görevde, farklı maliyet bağlamlarında farklı otonomi seviyelerini hak eder.

Ajanı kullanıcıya nasıl anlatmalıyım?

Ne yaptığını ve ne yapamadığını açıkça söyleyerek. Kullanıcılar ajanların sınırlarını bilmediğinde ya fazla güvenip kontrol etmezler ya da hiç güvenmeyip kullanmazlar. "Bu asistan siparişlerini görüntüleyebilir ve kargo durumunu kontrol edebilir; iptal ve iade işlemlerini senin onayın olmadan yapmaz" cümlesi, her ikisini de önler.

Ajan çerçevesi kullanmalı mıyım, kendim mi yazmalıyım?

İlk ajanını kendin yaz. Yukarıdaki otuz satır, bir ajanın ne olduğunu çerçeve dokümantasyonu okuyarak öğrenemeyeceğin kadar net gösterir. Karmaşıklık arttığında — çoklu ajan, duraklatma, dağıtık yürütme — bir çerçeveye geçmek mantıklı. Ama o zaman bile çerçevenin senin adına hangi kararları verdiğini bilerek geç.

Kaç araç fazla?

Pratik eşik on beş civarında başlıyor; bunun üstünde araç seçme kalitesi düşüyor. Çözüm araç sayısını azaltmak değil, bağlama göre filtrelemek: her adımda modele yalnızca o durumda anlamlı olan araçları göster. Bu, ölçeklenen tek yaklaşım.

Ajan yanlış bir şey yaparsa sorumluluk kimde?

Ürünü işleten tarafta — yani sende. Bu hukuki bir konu olduğu kadar tasarım konusu: geri alınamaz işlemleri onaya bağlamanın asıl gerekçesi bu. "Model karar verdi" bir savunma değildir.

Ajanlar zamanla daha mı iyi olacak?

Modeller iyileşiyor ve araç seçimi belirgin biçimde düzeliyor. Ama bu yazıdaki mühendislik kararlarının hiçbiri ortadan kalkmıyor: durdurma koşulu, yetkilendirme, iz kaydı, maliyet kontrolü model kalitesinden bağımsız gereksinimler. Daha iyi model, kötü tasarlanmış bir döngüyü kurtarmaz — sadece daha hızlı ve daha ikna edici biçimde yanlış yapar.

Ajan ile iş akışı motorunu birlikte kullanabilir miyim?

Evet ve olgun sistemlerin çoğu böyle çalışıyor. İş akışı motoru büyük resmi kontrol eder — sıra, yeniden deneme, kalıcılık, zamanlama — ajan ise akışın içindeki belirsiz bir adımı çözer. "Belgeyi sınıflandır ve doğru ekibe yönlendir" adımını ajan yapar, geri kalan on adımı motor yönetir. Bu bölüşüm, ajanın öngörülemezliğini tek bir kutuya hapseder.

Ajanın verdiği kararı nasıl açıklarım?

İz kaydı üzerinden. Modelin her adımdaki gerekçesini saklıyorsan, "neden bu siparişi iptal etti" sorusunun cevabı elindedir. Gerekçeyi saklamıyorsan cevabın yok — ve düzenlemeye tabi bir alanda çalışıyorsan bu ciddi bir eksiklik. Gerekçe alanını en baştan izin bir parçası yap; sonradan eklemek, geçmiş kararları açıklanamaz bırakır.

Küçük bir modelle ajan çalıştırılabilir mi?

Araç sayısı az ve görev darsa evet, ve maliyet farkı ciddi olabilir. Karar noktalarının karmaşıklaştığı yerlerde küçük modeller yanlış araç seçme ve döngüye girme eğilimi gösterir. Yaygın bir orta yol: yönlendirme ve basit adımlar küçük modelde, karar gerektiren adımlar güçlü modelde.

Küçük başlamak: ilk ajanın ne olmalı

İlk ajanı yanlış seçmek, bu teknolojiye dair yanlış bir izlenimle çıkmanın en hızlı yolu. İyi bir ilk ajanın dört özelliği var: dar bir görev, az sayıda araç (üçü geçmesin), geri alınabilir eylemler ve doğruluğu kolay kontrol edilen bir çıktı.

Bu tarife uyan klasik örnekler: gelen destek biletini sınıflandırıp ilgili dokümantasyon bağlantılarını ekleyen bir ajan; bir hata kaydını okuyup ilgili logları getiren ve ilk teşhis notunu yazan bir ajan; bir toplantı özetinden görev listesi çıkarıp taslak kartlar oluşturan bir ajan. Üçü de yanlış yaptığında maliyeti düşük, doğru yaptığında faydası görünür.

Uyarı olarak tam tersi: ilk ajan olarak "şirketin bütün sistemlerine bağlanan genel asistan" seçmek. Bu proje kaçınılmaz olarak yarım kalır, çünkü aynı anda araç tasarımı, yetkilendirme, değerlendirme ve kullanıcı deneyimi problemlerini birden çözmeni ister. Dar başla; kapsamı ölçtükçe genişlet.

Bu alan nereye gidiyor

Ajan mimarisi hızla değişiyor ve tahmin yürütmek yerine hangi kısmın sabit kaldığını söylemek daha faydalı. Modeller daha iyi araç seçiyor, daha uzun görevleri takip edebiliyor ve daha az döngüye giriyor — bu iyileşme sürecek. Ama döngüyü kuran, frenleri koyan, yetkiyi kontrol eden ve izi tutan taraf sensin ve bu sorumluluk model kalitesiyle azalmıyor.

Değişen şey, ajanların hangi görevler için ekonomik olduğu. Bugün sekiz adımda çözülen bir görev yarın üç adımda çözülüyorsa, bugün pahalı olduğu için elle yapılan işler yarın otomatikleşebilir hâle gelir. Bu yüzden "ajan bu işe uygun değil" kararını tarihiyle birlikte not et ve altı ayda bir gözden geçir; o kararların bir kısmı zamanla değişecek.

Sabit kalan ise sorumluluk çizgisi: modelin ne önerdiği ile sistemin neye izin verdiği arasındaki ayrım. Bu ayrımı net tutan ekipler, model her nesilde iyileştikçe otonomiyi güvenle genişletebiliyor; tutmayanlar ise her yeni modelde aynı riskleri baştan keşfediyor.

Sonraki adım

Ajan, bu sütunun giriş kapısı. Buradan üç yöne gidilir: araçları standart bir protokolle tanımlamak istiyorsan MCP AI araçları, ajanın bilgiye erişmesi gerekiyorsa RAG nedir, güvenlik tarafını derinleştirmek istiyorsan AI Security ve OWASP LLM Top 10.

Ama en faydalı sonraki adım muhtemelen kod yazmak değil: mevcut bir ajanın izlerinden yirmi tanesini okumak. Modelin nerede tereddüt ettiğini, hangi aracı yanlış seçtiğini, kaç adımda çözdüğünü görmek — bu alanda hiçbir makalenin veremeyeceği bir sezgi kazandırır. Temellere dönmek istersen LLM tabanlı uygulama geliştirme her zaman burada.