Yapay Zeka Ajanı (AI Agent) Nedir? Chatbot ve Otomasyondan Farkı

En sade tanımla yapay zeka ajanı, bir hedefi alıp o hedefe giden adımları kendisi seçen bir yazılımdır. Seçimi büyük dil modeli yapar; adımları ise ajanın kullanmasına izin verilen araçlar gerçekleştirir. Araç dediğimiz şey çoğu zaman bir API çağrısıdır: sipariş sistemine sorgu, CRM’e kayıt, takvime randevu, muhasebe yazılımına taslak fiş. Ajan her çağrının sonucunu okur, bir sonraki adıma yine kendisi karar verir ve hedef gerçekleşince ya da kendisine konan sınıra ulaşınca durur.

İngilizce kaynaklarda sık geçen agentic AI (ajanik yapay zeka) terimi de bu davranışı anlatır: model metin üretmekle kalmaz, sonuç doğuran işlemlere girişir. Toplantılarda en çok vakit kaybettiren yanlış anlama şu: otonomiyi bir açma-kapama düğmesi sanmak. Bir ajan yalnız okuyabilir, okuyup öneri hazırlayabilir, insan onayıyla yazabilir ya da belli tavanlar içinde kendi başına işlem yapabilir. Bu yazının büyük kısmı bu kademeler hakkında.

Bir uyarıyı da hemen yapayım. Son iki yılda “ajan” etiketi neredeyse her ürüne yapıştırıldı; sektörde buna agent washing deniyor. Sabit bir senaryoyu izleyen sohbet botu, araya bir LLM çağrısı eklenmiş bir Zapier akışı ya da yalnızca metin özetleyen bir eklenti de “AI agent” diye satılabiliyor. Bunların hepsi işe yarayabilir. Ama ajan değildir; ajan gibi fiyatlanması da, ajan riskiyle değerlendirilmesi de gerekmez.

Dört sorunun dördüne de “evet” diyebiliyorsanız elinizde gerçek bir ajan var. İkisine ya da üçüne “evet” diyorsanız bu bir kusur sayılmaz; birçok iş için doğru seviye zaten orasıdır.

Ajanların büyük kısmı, 2022’de Yao ve arkadaşlarının yayımladığı makaleyle adı konan ReAct (Reasoning + Acting, yani akıl yürüt ve eyle) düzenine benzer bir döngüyle çalışır. Model önce durumu değerlendirir, sonra bir araç seçip parametrelerini belirler, aracın döndürdüğü sonucu bağlamına ekler ve hedefe ulaşıp ulaşmadığına karar verir. Ulaşmadıysa döngü baştan başlar.

Burada modelin araçları kendisinin çalıştırmadığını bilmek önemli. Araç çağırma (tool calling ya da function calling) sırasında model yalnızca “şu aracı şu parametrelerle çağırmak istiyorum” diyen yapılandırılmış bir çıktı üretir. Çağrıyı yapan, yetkiyi kontrol eden ve sonucu modele geri veren sizin yazılımınızdır. Güvenlik tasarımının neredeyse tamamı bu aradaki katmanda yapılır. Modelin talimatına “lütfen dikkatli ol” yazmak bir kontrol değildir.

Aşağıda bir e-ticaret destek ajanının “12 Ekim’de verdiğim sipariş nerede?” sorusunu nasıl çözdüğünü adım adım görüyorsunuz. Müşteri ekranda tek bir cümle görür; arkada iki araç çağrısı, iki gözlem ve bir karar vardır.

1. 1. DüşünMüşteri sipariş numarası vermedi. Oturumdaki müşteri kimliğiyle o tarihteki siparişlere bakmalıyım.
2. 2. Araçsiparisleri_listele(musteri_id, tarih: 12.10)
3. 3. GözlemTek sipariş var: #10482, durum “kargoya verildi”, takip numarası mevcut.
4. 4. Araçkargo_takip(takip_no)
5. 5. GözlemPaket dağıtım şubesinde, teslim tahmini yarın.
6. 6. KararHedef karşılandı. Müşteriye tahmini teslim gününü ve takip bağlantısını yaz, döngüyü bitir.

Durma koşulu neden zorunlu?

Döngüyü esnek yapan şey, onu tehlikeli de yapar. Kargo API’si zaman aşımına düştüğünde ajan aynı çağrıyı tekrar tekrar deneyebilir. Her deneme modele bağlamı yeniden gönderir, her bağlam da token faturası demektir. Bizim ekipte bir ajanı canlıya almadan önce şu sınırları modelden bağımsız olarak, kod düzeyinde tanımlıyoruz:

• Adım tavanıGörev başına en fazla N araç çağrısı. Aşılırsa görev, o ana kadarki iziyle insana devredilir.
• Zaman aşımıHem tek tek araç çağrıları hem görevin tamamı için süre sınırı.
• Bütçe tavanıGörev başına token ya da para üst sınırı. Aşılınca ajan durur ve durumu loglar.
• Tekrar tespitiAynı araç aynı parametrelerle art arda çağrılıyorsa döngü kesilir.
• Başarı tanımı“Bitti”nin ne demek olduğu yazılıdır: yanıt gönderildi, kayıt açıldı, taslak hazır.

Teklif görüşmelerinde en sık duyduğum cümle “bizim zaten bir chatbot’umuz var, onu ajana çevirsek?” oluyor. Cevabım çoğu zaman bir soru: neyi değiştirmek istiyorsunuz? Chatbot ile ajan arasındaki fark modelin zekâsında değil, sistemin dokunabildiği yerlerde. Chatbot konuşmanın içinde kalır; ajan konuşmanın dışına çıkıp başka sistemlerde iş yapar.

Aşağıdaki tablo dört yaklaşımı yan yana koyuyor. RAG asistanı, şirket belgelerinden kaynak göstererek cevap üreten chatbot türüdür; nasıl çalıştığını ilk yapay zeka projesi rehberimizin RAG bölümünde ayrıntılı anlattık, burada tekrar etmeyeceğim.

Tablodan çıkan pratik ders şu: ajan, diğer üçünün “üst sürümü” değildir. Öngörülebilirlikten vazgeçip karşılığında esneklik satın alırsınız. Esnekliğe ihtiyacınız yoksa bu takas size kaybettirir.

Ajan anlatan yazılarda pek rastlamayacağınız bir bölüm bu. Bir CTO olarak ekibime ilk sorduğum soru hep aynı: “Bu işin adımları her seferinde aynı mı?” Cevap evetse ajan kurmak, rayları döşenmiş bir hatta tren yerine taksi çalıştırmaya benzer. Taksi de sizi götürür; ama her seferinde yolu yeniden seçer, daha pahalıya ve daha yavaş götürür, geç kaldığında da nedenini bulmak zorlaşır.

Fatura aktarımı, stok senkronizasyonu, satın alma onay akışı, gün sonu raporu gibi işlerin girdisi yapılandırılmıştır ve adımları bellidir. Bunlar için n8n, Make ya da doğrudan yazılmış bir entegrasyon servisi hem daha ucuz hem daha denetlenebilirdir. Pazaryeri ile ERP arasındaki sipariş ve stok akışında sorun genellikle zekâ eksikliği değil, entegrasyonun kendisidir; bunun teşhisini entegrasyon hataları yazımızda ele aldık.

Orta yol: akışın içine tek bir LLM adımı

Çoğu şirketin aradığı şey aslında burada. Akışın iskeleti sabit kalır, yalnızca insan dilini anlamak gereken tek bir adımda model kullanılır: gelen e-postayı “fatura / şikâyet / teklif talebi” diye sınıflandırmak, PDF faturadan numara, tarih ve tutar çıkarmak, müşteri mesajının aciliyetini belirlemek. Model karar ağacının bir dalını seçer, ağacın kendisini çizmez.

Bu yapının güzel tarafı ölçülebilir olmasıdır. Sınıflandırma adımının doğruluğunu geçmiş e-postalarla test edebilir, model kararsız kaldığında kaydı insan kuyruğuna atan bir eşik koyabilirsiniz. Zayıf tarafı, beklenmedik bir durumda akışın kendini uyaramamasıdır. O noktaya geldiğinizde ajan konuşmaya değer.

Bir ajanın mimarisini konuşurken modelden çok etrafındaki parçaları konuşuruz. Model değiştirilebilir bir bileşendir; araç tasarımı, yetkiler ve gözlem katmanı ise projenin asıl emeğidir. Bir ajanı oluşturan altı parça şunlar:

• ModelAkıl yürütmeSıradaki adımı seçen büyük dil modeli. Görevin zorluğuna göre büyük ve pahalı ya da küçük ve hızlı bir model seçilir; bazı projelerde ikisi farklı adımlarda birlikte çalışır.
• Talimat (sistem prompt’u)Rol ve sınırlarAjanın kim olduğu, hedefi, hangi durumda insana devredeceği ve neyi asla yapmayacağı. Talimat bir davranış rehberidir, güvenlik duvarı değildir.
• AraçlarEylemAjanın çağırabildiği fonksiyonlar. Her aracın adı, açıklaması ve JSON şemasıyla tanımlı parametreleri vardır. Modelin doğru aracı seçmesi büyük ölçüde açıklamanın kalitesine bağlıdır.MCP bu katmanı standartlaştırır
• BellekBağlamKısa süreli bellek, konuşma ve araç sonuçlarıdır. Uzun süreli bellek ise müşteri geçmişi, önceki görevler ya da RAG ile getirilen belgelerdir. Belleğe ne yazılacağı da bir yetki konusudur.
• Kimlik ve yetkiSınırAjanın sistemlere hangi hesapla bağlandığı. Bir çalışanın kişisel hesabı değil, yalnız gereken izinlere sahip ayrı bir servis hesabı kullanılmalı.
• Gözlem ve logHesap verebilirlikHer adımın, araç çağrısının, parametrenin ve sonucun kaydı (trace). Hata ayıklama, maliyet takibi ve “neden böyle yaptı?” sorusunun cevabı buradan çıkar.

Araç tanımının nasıl göründüğünü somutlaştırmak için sipariş durumu sorgulayan basit bir aracın şemasını aşağıya koydum. Modelin gördüğü şey tam olarak budur: bir isim, ne işe yaradığını anlatan bir açıklama ve parametre tipleri. Açıklamaya “ne zaman kullanılmaz” satırını eklemek, iade ile sipariş sorgusu gibi birbirine benzeyen araçların karıştırılmasını azaltıyor; kod incelemesinde ilk baktığım yerlerden biri bu. Dikkat edin, musteri_id alanını model değil, oturumdan uygulama dolduruyor; böylece model başka bir müşterinin siparişini sorgulayamıyor.

{
  "name": "siparis_durumu_getir",
  "description": "Müşterinin tek bir siparişinin durumunu ve kargo takip numarasını döndürür. Yalnız okuma yapar. Sipariş iptali veya iade için KULLANILMAZ.",
  "input_schema": {
    "type": "object",
    "properties": {
      "siparis_no": {
        "type": "string",
        "pattern": "^[0-9]{5,10}$",
        "description": "Sipariş numarası, yalnız rakam"
      },
      "musteri_id": {
        "type": "string",
        "description": "Oturumdaki müşteri; uygulama doldurur, model değiştiremez"
      }
    },
    "required": ["siparis_no", "musteri_id"]
  }
}

Araçların arkasında çoğu zaman mevcut sistemlerinizin API’leri vardır. API’si olmayan bir sisteme ajan bağlamak, önce o sisteme güvenli bir uç nokta yazmak demektir. Konuya yeniyseniz API nedir, API entegrasyonu nasıl yapılır yazısıyla başlayabilirsiniz; bu katmanı API geliştirme hizmetimiz kapsamında, ajan projesinden bağımsız olarak da kuruyoruz.

Aşağıdaki altı örnek, keşif görüşmelerinde en sık konuştuğumuz senaryolardan seçildi. Her kartta işi başlatan tetik, ajanın kullandığı araçlar, insanın devreye girdiği nokta ve “neden akış değil de ajan?” sorusunun cevabı var. Bilerek hiçbirine başarı yüzdesi yazmadım; o rakam sizin verinizle, pilotta ölçülür.

• E-ticaretİade talebi ajanıS3

  Tetik

  Müşteri destek kanalından iade ister.

  Araçlar

  Sipariş sorgusu, iade politikası (RAG), ödeme kuruluşunun iade API’si, CRM notu

  İnsan devrede

  Para hareketi doğuran her iade ve politika dışı her talep onaylı başlar; tavan üstü tutarı ajan hiç başlatamaz.

  Neden ajan?

  Talep serbest metindir; ürün durumu, süre ve kampanya koşulları her seferinde farklı birleşir.

• Muhasebee-Fatura eşleştirme ajanıS3

  Tetik

  Entegratörden yeni gelen e-Fatura düşer.

  Araçlar

  e-Fatura XML okuma, satın alma siparişi ve irsaliye sorgusu, ERP’de taslak kayıt

  İnsan devrede

  Eşleşmeyen satırlar ve fark çıkan tutarlar muhasebecinin kuyruğuna düşer; kesin kayıt insanda.

  Neden ajan?

  Tedarikçiler aynı kalemi farklı adlarla yazar; kısmi teslim ve fiyat farkı her seferinde başka bir yol ister.

• Satın almaTeklif karşılaştırma ajanıS2

  Tetik

  Bir satın alma talebi için birkaç tedarikçi teklifi PDF ya da e-postayla gelir.

  Araçlar

  Belge okuma, geçmiş alış fiyatları, döviz kuru servisi, tablo oluşturma

  İnsan devrede

  Karar ve sipariş tamamen insanda; ajan yalnızca karşılaştırma tablosu ve dikkat notları hazırlar.

  Neden ajan?

  Teklif formatları birbirine benzemez; vade, KDV dahil/hariç ve teslim koşulları her belgede başka yerde yazar.

• BT destekTalep sınıflandırma ve ilk çözüm ajanıS3

  Tetik

  Bir çalışan yardım masasına “VPN bağlanmıyor” yazar.

  Araçlar

  Bilgi bankası, kullanıcı ve cihaz envanteri, servis durum sayfası, ticket sistemi

  İnsan devrede

  Parola sıfırlama ve yetki değişikliği onaylı; çözülemeyen talep geçmişiyle birlikte teknisyene devredilir.

  Neden ajan?

  Aynı belirti farklı nedenlerden doğar; ajan envantere ve servis durumuna bakarak hangi yolu izleyeceğini seçer.

• SatışPotansiyel müşteri (lead) zenginleştirmeS2

  Tetik

  Web formundan yeni bir talep gelir.

  Araçlar

  CRM, firmanın kamuya açık web sitesi, sektör sınıflandırması, temsilci takvimi

  İnsan devrede

  Müşteriye giden ilk e-posta temsilcinin onayından geçer.

  Neden ajan?

  Formdaki bilgi eksik ve dağınıktır; ajan neyi araştıracağına girdiye bakarak karar verir.

• İnsan kaynaklarıAday ön tarama asistanıS2

  Tetik

  İlana yeni bir başvuru düşer.

  Araçlar

  Başvuru sistemi, ilan kriterleri, özgeçmiş okuma

  İnsan devrede

  Eleme ya da ret kararı her zaman insanda; ajan yalnız kriter eşleşmesini gerekçesiyle özetler.

  Neden ajan?

  Özgeçmişler serbest biçimlidir; ama karar kişiyi doğrudan etkilediği için otonomi bilerek düşük tutulur.

e-Fatura eşleştirme örneğinde ajanın ERP’ye yazdığı şey kesin fiş değil, taslak kayıttır. Logo tarafında bu tür entegrasyonların nasıl kurgulandığını Logo ERP entegrasyonu rehberimizde anlattık; kurulum ve özelleştirme işleri Logo ERP çözüm ortaklığı ekibimizin alanı.

“Ajan mı, değil mi?” yerine “hangi seviyede ajan?” diye sormak projeleri hem daha güvenli hem daha hızlı canlıya çıkarıyor. Biz beş basamaklı bir merdiven kullanıyoruz. Her basamak bir öncekinin güvenlik önlemlerini devralır ve üstüne yenilerini ekler.

Merdivende tek kuralımız var: basamaklar tek tek çıkılır. S3’te birkaç haftalık onay verisi toplamadan S4’e geçmek, yeni bir çalışana ilk gününde şirket kartını teslim etmeye benzer.

1. S0Klasik otomasyonKural ve akış; model yok. Yapılandırılmış girdi, sabit adımlar.Gereken önlem: Hata bildirimi, denetim logu
2. S1Akış + LLM adımıSabit akışın içinde tek bir sınıflandırma ya da alan çıkarma adımı.Gereken önlem: Çıktıyı şemayla doğrulama, kararsızlıkta insan kuyruğu
3. S2Araçlı asistan (salt okuma)Model araç seçer ama yalnızca okur; öneri ve taslak hazırlar, işlemi insan yapar.Gereken önlem: Ayrı servis hesabı, adım ve süre tavanı, harici içerik ayrımı
4. S3Onaylı ajanYazma işlemlerini hazırlar; riskli adımlar insan onayından sonra uygulanır.Gereken önlem: Onay kapısı, gölge mod, acil durdurma anahtarı
5. S4Sınırlı otonom ajanTutar ve adet tavanı içindeki geri alınabilir işlemleri onaysız yapar.Gereken önlem: Harcama ve adet tavanı, geri alma yolu, anomali alarmı

Sihirbaz size seviyeyi söyler; ama ajan araç bazında yetkilendirilir. “Bu iş S3, onaylı ajan” kararı, sipariş sorgusunun da onaya bağlanacağı anlamına gelmez. Pratikte her aracın kendi politikası olur: okuma araçları otomatik çalışır, geri alınabilir yazmalar belli bir tutara kadar otomatik ve loglu yapılır, geri alınamaz işlemler onaya düşer, bazı işlemler ise ajana hiç verilmez.

Aşağıdaki araçla ajanınızın yapacağı işlemleri seçin, her birinin türünü ve tutar tavanını girin. Araç her satıra Otomatik, Onay ya da Yasak politikası atar ve sonucu yazılımcınızın doğrudan kullanabileceği bir YAML ya da JSON taslağına çevirir. Ödeme ve silme işlemleri varsayılan olarak yasaktır; isterseniz satır bazında onaya açabilirsiniz.

• Okuma→ Otomatik
• Geri alınabilir yazma→ Tavana kadar otomatik ve loglu, tavan üstü onay
• Geri alınamaz işlem→ Her zaman onay; tavan üstünü ajan hiç yapamaz
• Ödeme ve silme→ Varsayılan yasak

# Ajan araç yetki politikası (taslak) · W3 Araç Yetki Matrisi Üretici
# Bu dosyayı araç çağrılarını uygulayan katman okumalı; modelin talimatı değil.
agent: iade_asistani
defaults:
  mode: forbidden          # listede olmayan araç çağrılamaz
  log: true
  max_steps_per_task: 12
  kill_switch: true        # tüm yazma araçlarını tek ayarla kapat
tools:
  - name: crm_musteri_oku
    system: "CRM"
    access: read
    mode: auto
  - name: stok_sorgula
    system: "ERP"
    access: read
    mode: auto
  - name: siparis_durumu_getir
    system: "E-ticaret"
    access: read
    mode: auto
  - name: eposta_taslagi_olustur
    system: "E-posta"
    access: write
    mode: auto
  - name: iade_baslat
    system: "Ödeme"
    access: irreversible
    mode: approval
    max_amount_tl: 2000   # üstünü ajan hiç başlatamaz
  - name: telafi_kuponu_tanimla
    system: "E-ticaret"
    access: write
    mode: auto
    approval_above_tl: 250   # üstü insan onayına düşer

Politikanın en önemli satırı aslında en üstteki mode: forbidden varsayılanıdır: listede olmayan hiçbir araç çağrılamaz. Yetki matrisini yazılımcıya bir öneri olarak değil, araç çağrılarını uygulayan katmanın okuduğu bir yapılandırma olarak teslim edin. Modelin talimatına yazılan kural, modelin ikna edildiği gün delinir; kodda duran kural delinmez.

Çoklu ajan sistemlerinde bir orkestratör ajan işi parçalara böler ve her parçayı kendi araçları ve talimatı olan uzman alt ajanlara dağıtır, sonra sonuçları toplar. Kâğıt üzerinde çok çekici: biri araştırır, biri hesaplar, biri yazar, biri kontrol eder.

Mimari incelemelerde gördüğüm tablo farklı: çoğu işte tek bir ajan ve iyi tanımlanmış araçlar yetiyor. Her ek ajan, modeller arasında bir konuşma demek; o konuşmanın her turu gecikme ve token maliyeti ekler. Daha kötüsü, bir hata çıktığında hangi ajanın hangi yanlış bilgiyi diğerine aktardığını bulmak, tek ajanlı bir izi okumaktan çok daha zordur.

Chatbot yanlış cevap verdiğinde kötü bir cevap okursunuz. Ajan yanlış işlem yaptığında ise yanlış bir iadeyle, yanlış kişiye giden bir e-postayla ya da silinmiş bir kayıtla uğraşırsınız. Bu yüzden ajan güvenliği, klasik uygulama güvenliğinin üstüne eklenen yeni bir katmandır.

OWASP’ın büyük dil modeli uygulamaları için yayımladığı 2025 tarihli Top 10 listesi bu riskleri adlandırıyor. İlk sırada LLM01: Prompt Injection var: modelin, kullanıcıdan ya da işlediği içerikten gelen talimatlarla amacı dışında davranmaya yönlendirilmesi. Ajanlar için asıl tehlikeli olan dolaylı türüdür; saldırgan ajanla hiç konuşmaz, talimatı ajanın okuyacağı bir e-postaya, web sayfasına ya da belgeye gizler.

Altıncı sıradaki LLM06: Excessive Agency (aşırı yetki) bu saldırının neden zarara dönüştüğünü anlatır: ajana gereğinden fazla araç, izin ya da otonomi verilmiştir. Onuncu sıradaki LLM10: Unbounded Consumption ise kontrolsüz kaynak tüketimini kapsar; gece boyunca aynı API’yi deneyip duran bir ajanın sabah gelen model faturası tam olarak budur. Üçünü birlikte okuyunca ders netleşiyor: modeli kandırmak her zaman mümkün olabilir, sizin işiniz kandırılmış bir modelin yapabileceği zararı sınırlamak.

Bir ajanı korumak için yedi önlem

1. 1En az yetkiE-posta özetleyen ajana gönderme aracı vermeyin. Gerekiyorsa yalnız taslak oluşturabilsin; gönderme insanda kalsın.
2. 2Ayrı servis hesabıAjanın erişimi kendi hesabının izinleriyle sınırlı olsun. Müşteri listesine erişim gerekmiyorsa hesapta da olmasın.
3. 3Harici içerik ≠ talimatE-posta, belge ve web içeriğini modele veri olarak işaretleyerek verin; böyle bir içerik okunduktan sonra yüksek riskli araçları kilitleyin.
4. 4Parametre doğrulamaAraç parametrelerini kod tarafında kontrol edin: alıcı izinli alan adında mı, tutar tavanın altında mı, kayıt bu müşteriye mi ait?
5. 5Kimliği uygulama doldursunMüşteri kimliği ve yetki rolü gibi alanları model değil, oturumdan uygulama doldursun; başka müşteri adına sorgu baştan engellensin.
6. 6Harcama ve adım tavanıGörev başı token, işlem adedi ve tutar sınırları kodda dursun; model bu sınırları değiştiremesin.
7. 7Acil durdurmaŞüpheli bir durumda tüm yazma araçlarını tek ayarla kapatabilin ve bunun nasıl yapılacağı nöbet belgesinde yazsın.

Bu önlemlerin hiçbiri tek başına yetmez; birlikte kullanıldıklarında saldırının etki alanını küçültürler. Canlıya almadan önce ajanı kötü niyetli girdilerle denemek, klasik bir sızma testinin parçası olarak planlanabilir. Sürecin nasıl işlediğini sızma testi rehberimizde anlattık; yapay zeka bileşenli uygulamaların testini de güvenlik ve sızma testi hizmetimiz kapsamında yapıyoruz. Çalışanların ChatGPT gibi genel araçlara şirket verisi girmesi ise ayrı bir konu; onu ChatGPT güvenli mi yazımızda ele alıyoruz.

Bir chatbot’u test ederken cevabın doğru olup olmadığına bakarsınız. Ajanı test ederken buna ek olarak yolun doğru olup olmadığına da bakmanız gerekir: doğru aracı mı seçti, gereksiz adım attı mı, durması gereken yerde durdu mu? Cevap doğru olsa bile beş yerine on beş adımda ulaşılmışsa o ajan canlıda pahalı ve yavaş olacaktır.

Değerlendirmenin temeli, süreci bilen kişilerin hazırladığı ve beklenen sonucu belli senaryolardan oluşan bir test setidir. Altın soru seti ve halüsinasyon ölçümünü ilk proje rehberimizin değerlendirme bölümünde anlattık. Ajan için bu sete iki şey eklenir: her senaryoda beklenen araç sırası ve “burada durmalı” dediğiniz sınır durumları.

Trace loglarında ne tutulmalı, ne maskelenmeli?

Ajan kurmanın tek bir doğru yolu yok. Seçimi iki şey belirliyor: şirketin elinde nasıl bir ekip olduğu ve verinin nerede durması gerektiği. Dört yaygın seçeneğe benim bakışım şöyle:

• n8nAkış ağırlıklı işler · S1–S3Görsel akış editörü ve AI Agent düğümüyle akışın içinde ajan kurulabiliyor; kendi sunucunuzda barındırılabiliyor. Lisansı OSI anlamında açık kaynak değil; n8n’in Sustainable Use License adını verdiği fair-code modeli. Kendi şirketinizin iç işleri için kullanmak serbest, n8n’i başkalarına akış kurdukları bir hizmet olarak sunmak kısıtlı. SSO gibi bazı özellikler ücretli planlarda.Dikkat: Karmaşık ajan mantığı görsel editörde çabuk okunaksız hâle gelir; sürüm kontrolü ve test disiplini baştan kurulmalı.
• Microsoft Copilot StudioMicrosoft 365 kullanan şirketlerTeams, SharePoint ve Microsoft 365 verisiyle çalışan ajanları düşük kodla kurmaya yarar. Şirket zaten Microsoft 365 kullanıyorsa kullanıcı kimlikleri ve erişim hakları için sıfırdan bir yapı kurmanız gerekmez.Dikkat: Lisans ve kullanım bazlı ücretlendirme ayrıca hesaplanmalı; Microsoft dışındaki yerel sistemlere bağlanmak için yine bağlayıcı ya da API gerekir.
• Sağlayıcı SDK’ları ve açık çatılarYazılım ekibi olan şirketlerModel sağlayıcılarının ajan geliştirme kitleri ve açık kaynak çatılar; döngü, araç çağırma ve iz kaydı için hazır yapı taşları sunar.Dikkat: Bir sağlayıcıya özgü özelliklere fazla yaslanmak ileride model değiştirmeyi zorlaştırır; araç katmanını MCP ya da kendi soyutlamanızla ayırın.
• Özel geliştirmeYerel sistemlere derin entegrasyon, yüksek riskDöngü, yetki katmanı, onay ekranı ve log altyapısı sizin kodunuzda durur; hangi verinin nereye gittiği tamamen sizin kontrolünüzdedir.Dikkat: İlk kurulum emeği daha yüksek; bakım ve izleme için sahibi belli bir ekip gerekir.

Seçerken sorulacak altı soru

1. 1.Veri konumuModel çağrısı ve loglar hangi ülkede işleniyor, kişisel veri yurt dışına aktarılıyor mu?
2. 2.KimlikSSO ve rol bazlı yetki var mı, ajan sistemlere hangi hesapla bağlanıyor?
3. 3.Denetim kaydı“Kim, neyi, ne zaman onayladı?” sorusunun cevabı dışa aktarılabiliyor mu?
4. 4.BağımlılıkModel ya da platform değişirse araç tanımları ve iş mantığı taşınabiliyor mu?
5. 5.Yerel entegrasyonLogo, e-Fatura entegratörü, iyzico ya da PayTR gibi sistemlere hazır bağlantı var mı, yoksa API mi yazılacak?
6. 6.BakımAkışlar ve talimatlar sürüm kontrolünde mi, her değişiklik test setinden geçiyor mu?

Maliyet tarafı ayrı bir yazının konusu: model kullanım ücreti, platform lisansı, entegrasyon geliştirme ve izleme emeği birlikte hesaplanmalı. Bu kalemleri yapay zeka chatbot fiyatları ve maliyet hesaplama yazımızda tek tek ele alıyoruz. Birden fazla sistemi tek akışta buluşturmanız gerekiyorsa sistem birleştirme için API geliştirme sayfamız, ajanın çalışacağı uygulamayı da biz yazalım derseniz web yazılım geliştirme hizmetimiz iyi bir başlangıç noktası.

İlk ajan projesinin amacı şirketi dönüştürmek değil, ajanın sizin verinizle ve sizin sistemlerinizde nasıl davrandığını öğrenmektir. Yapay zeka projelerinde müşterilere önerdiğimiz sıra şu:

1. 1Dar bir görev seçin“Müşteri hizmetleri” değil, “kargo durumu soruları”. Başarıyı tek cümleyle tarif edebileceğiniz bir iş.
2. 2Hata maliyetini ölçünBu iş bugün elle yapılırken hangi hatalar, ne sıklıkta oluyor ve bir hatanın bedeli ne? Sihirbazdaki R skoru buradan gelir.
3. 3Salt okumayla başlayınAjan yalnızca sorgulasın ve cevap ya da taslak önersin. Araç tanımlarını ve yetki matrisini bu aşamada netleştirin.
4. 4Gölge modda çalıştırınAjan önersin, insan uygulasın; öneri ile karar arasındaki farkı kaydedin.
5. 5Yazma işlemlerini onaylı açınOnay ekranı insanların gerçekten okuyacağı kadar sade olsun; “tümünü onayla” düğmesi olmasın.
6. 6Tavanları veriyle gevşetinTavanlı otonomiye geçmeden önce onay verisi toplayın. Biz başlangıç noktası olarak 4–6 haftayı alıyoruz, ama asıl ölçü süre değil, birikmiş onaylı işlem sayısı. Onay oranı ve reddedilen işlemlerin nedenleri kararı versin.

Kendi ürünümüz Tuğra AI’da da benzer bir ilkeyle ilerledik: kullanıcı modu seçer, o iş için uygun model OpenAI, Anthropic ya da Google altyapısından sunucu tarafında atanır. Ajan projelerinde de her adıma aynı modeli koymak zorunda değilsiniz. Sınıflandırma gibi basit adımlara küçük ve hızlı bir model, planlama gibi zor adımlara daha büyük ve pahalı bir model atamak, görev başı faturayı ciddi biçimde aşağı çekebilir.

Müşteri destek tarafından başlamak istiyorsanız müşteri hizmetleri otomasyonu için yapay zeka, kendi yazılım ürününüze ajan özelliği eklemek istiyorsanız SaaS ürün özelliği için yapay zeka sayfalarımız daha somut kurgular içeriyor.