Yapay zeka ajanı vs chatbot: farkı nedir gerçekten?

Yapay zeka ajanı vs chatbot: farkı nedir gerçekten?

Yapay zeka ajanı vs chatbot farkı tek noktada toplanır: geri yazma (write-back) yetkisi. Bir chatbot tek bir LLM çağrısında konu satırı ve gövde metni oluşturur, insan review bekler. Bir yapay zeka ajanı ise bir döngü içinde çalışır: durumu okur, karar verir, dış sistemlere yazı yapma yetkisine sahiptir, sonucu değerlendirir.

İkisinden de "14 gün pasif olan kullanıcılara yeniden katılım e-postası yaz, sesinizi eşleştir" diye söyleyin. Chatbot metin oluşturur, işlemi bitirmesi için insan review bekler. Yapay zeka ajanı ise bunu yapar: e-posta geçmişini ESP'den çeker, kullanıcının açma profiline bakarak en uygun gönderme saatini seçer, karar hakkında bir message'ı Postgres'e kayıt eder, sonucu sistem log'larına işler.

E-mail altyapısında önemli olan bu fark, sözlükteki kelimelerle ilgili değildir. Sorun şudur: sistem sizin production altyapınızda etkin olarak harekete geçebilir mi, yoksa sadece "siz bu işi yapmalısınız" tavsiyesiyle mi yetinir? Satıcılar bu çizgiyi bulanıklaştırmaya her incentifi vardır, çünkü bu sene "agent" terimi "chatbot"tan daha yüksek fiyat etiketiyle gelir. Fakat bu kelimelerin neyi temsil ettiğini anlamak altyapı kararları için kritiktir.

Yapay zeka ajanı ve chatbot, ikisi de AI kullansa da altyapınızda tamamıyla farklı şekilde çalışır. İkisinden de "14 gün pasif olan kullanıcılara yeniden katılım e-postası yaz, sesinizi eşleştir" diye söyleyin. Chatbot tek bir LLM çağrısında konu satırı ve gövde metni döndürür, işlemi bitirmesi için insan review bekler. Yapay zeka ajanı ise bunu yapar: e-posta geçmişini ESP'den çeker, kullanıcının açma profiline bakarak en uygun gönderme saatini seçer, karar hakkında bir message'ı Postgres'e kayıt eder, sonucu sistem log'larına işler.

E-mail altyapısında önemli olan bu fark, sözlükteki kelimelerle ilgili değildir. Sorun şudur: sistem sizin production altyapınızda etkin olarak harekete geçebilir mi, yoksa sadece "siz bu işi yapmalısınız" tavsiyesiyle mi yetinir? Satıcılar bu çizgiyi bulanıklaştırmaya her incentifi vardır,çünkü bu sene "agent" terimi "chatbot"tan daha yüksek fiyat etiketiyle gelir. Fakat bu kelimelerin neyi temsil ettiğini anlamak altyapı kararları için kritiktir.

Tek ayrılış noktası: geri yazma (write-back) yetkisi

Hemen her satıcı slides'inde "agent" ve "chatbot" aynı şeymiş gibi kullanılıyor. Halbuki bunlar tamamıyla ayrı sistem kategorileridir. Bir chatbot, en gelişmiş LLM modelini çalıştırsada, metinle cevap verir: bir tavsiye, bir taslak, bilgi bankasından çekilen özet. Asla veritabanınıza yazı yapmaz, asla API aracılığıyla external sistemde değişiklik yaratmaz.

Yapay zeka ajanı ise bir döngü içinde çalışır: durumu oku, karar ver, bir araç çağır, sonucu kontrol et, yeniden değerlendir, belki yeniden hareket et. O döngü ayırıcı öğedir. Kişiliği, yanıt hızı, kopyaların dilbilim kalitesi,bunlar hangi kategoride olduğunu değiştirmez.

Kendi ESP wrapper'ını yazıp webhook payload'ından gönderme zamanı belirleyen bir ekip iseniz, bu sene pazarlanan çoğu "agent" ile karşılaştırıldığında, pratik anlamda daha çok bir ajanınız var demektir. "Agent" pazarlar çünkü iyi satış yapar, "LLM step'i olan workflow motor"dan çok daha iyi satış yapar: hatta ikincisi mühendislik açısından daha doğru olsa bile.

Chatbot vs Agent'ı ayıran dört somut kriter:

• Dokunulan sistem sayısı. Chatbot: 0-1, sadece context okur, yazı işlemi yok. Agent: 2+, okur ve aralarında karar alarak yazar.

• Tipik latency. Chatbot: 1-3 saniye, tek model çağrısı. Agent: 3-15+ saniye, ardışık çok araç çağrısı.

• Hata senaryosu. Chatbot: kötü, generic veya yanıltıcı metin. Agent: kaldığı yerden devam edemeyen karar, eksik data yazısı.

• Yazma yetkisi. Chatbot: yok. Agent: sınırlı ve tanımlanmış, her araç için ayrı.

• İdeal kullanım alanı. Chatbot: konu satırları, email copy, tek tur compose. Agent: gönderme zamanı optimization, rate limiting, eskalasyon routing.

Yaşam döngüsü tetikleyicisinde, observe-reason-act döngüsü nasıl çalışır?

Araştırmacıların "observe-reason-act-evaluate" diye çağırdığı matematiksel döngü, bir yaşam döngüsü tetikleyicisine tam olarak eşlenir. Gerçek hayattaki bir activation path'ında bu döngü şöyle ilerler, sırasıyla:

Birinci aşama: Gözlemle (Observe). Bir Postgres CDC stream ya da Segment webhook, deneme kullanıcısı belirli bir kullanım eşiğini geçtiğinde ateşlenir. Agent etkinliği alır ve okumak için yetkilendirildi olan context'i de alır: plan seviyesi, eski gönderiler sayısı, kaydolmadan bu yana kaç gün, son açma tarihi.

İkinci aşama: Düşün (Reason). Model şu soruları sorar: Bu olay ne anlama geliyor? Bu kullanıcı nudge'a mı ihtiyaç duyuyor, yoksa 3 gün önce zaten benzer bir mesaj aldı mı? E-mail doğru kanal mı, yoksa bu hesap tarihçe olarak sadece in-app prompts'tan dönüştü mü? Bu kullanıcı şu anda hassas midir (fraud signal)?

Üçüncü aşama: Harekete geç (Act). Eğer gönderme gerekli ise, agent bir fonksiyon çağırır: hemen blast yerine hesaplanmış bir gönderme zamanında template'i queue'ya alma gibi. Fonksiyon ESP API'sine karşı çalışır, kayıt yazılır.

Dördüncü aşama: Değerlendir (Evaluate). Agent göndermenin temiz olduğunu doğrular, sonucu log'a işler. Döngünün bitip bitmediğine karar verir: bazen bir takip adımı hala ödenmemiş ise (Slack notif growth lead'e, CRM field güncellemesi, internal event fire).

Bunun hiç biri tüm pipeline'ı başından sonuna otonomize etmenizi gerektirmez: bu kadar özerklik production'da risky'dir. Pratikte, çoğu production deployment ajanı dar bir kararla kapsamlandırır: tek bir tetikleyici tipi için zaman ve kanal seçimi, geri kalanını belirlenimci kodla bırakır. Bu compromise değildir, bu doğru engineeringdir. Çoğunlukla yargı gerektirmeyen işler için çok özerklik zararlıdır. Tüm pipeline'ı agent'a veren ekipler, "neden gönderme ateşlenmedi?" hata ayıklama ile zamanlarını boşa harcarlar.

Pazarlanan "AI email agent"ların çoğu aslında tek bir LLM çağrısı

Gartner'ın genel agentic AI pazarına dair okuması keskindir: firma agentic AI projelerinin %40'ından fazlasının 2027 sonuna kadar iptal edileceğini öngörüyor. Sebep nedir? Çoğu durumda bu sistemlerin asla özerk hareket için tool erişimi ve veri mimarisi yok baştan beri. E-mail araçlandırması bu kalıptan bağışık değildir.

Pazarlanan çoğu "AI email agent" ürünün feature sayfasını açarsanız, single LLM call bulursunuz: "Marka sesinizi verin, üç konu satırı al." Bu iyi bir system prompt'la hızlı bir chatbot'tur. Yararlı mı? Evet. Ajan mı? Hayır. İnsanlar "ajan" diye pazarlanırsa, yanlış beklenti yaratır: sanki sistemin production'da supervised olmadan hareket edebileceği ve kararları yazacağı görünür.

Bu teknik kısıt meselesidir. Bir agent, şu üçüne gerek duyar: (1) tanımlı bir tool schema'sı, (2) hareket etmesi gereken sistemlere yazma yetkisi, (3) sonucu değerlendir yolu (idempotency, rollback). Bu üçünden birini kaçırırsanız: veya production'da güvenmeyi gerektirirse, pazarlanan agent olmayan, çıktısını human review gerektirir bir chatbot yazmışsınız.

Kurulu ESP'ler bu konuda çoğunlukla dürüst davranırlar. Klaviyo ve Customer.io, LLM-destekli copy composition gönderirler: single-turn, chatbot mimarisi, asla "özerk hareket eder" demezler. Mailchimp ve Brevo'nun send-time özellikleri LLM ajanından çok istatistik model'e yakındır. Resend hiç "AI agent" pazarlamaz: bu kategoride bu kadar çok "agent-washing" görülünce kısıtlı davranmak anlaşılır.

Copy.ai'nin chat-to-workflow arayüzü orta yol örneğidir. Giriş katmanında hala temel chatbot'tur: bir prompt input, bir metin output. Çok-adım otomasyona açan workflow credits, sadece Growth tier ve üstünde ortaya çıkar: bu gerçek mühendislik maliyetinin nerede olduğunun adil gösterimidir.

Basit metin oluşturma chatbot problemidir, agent problemi değil

"14 gün lounge yapmayan kullanıcılara yeniden katılım e-postası yaz, 120 sözcük altında tut, sesinizi eşleştir" diye istek yap: bu tek turlu, deterministic görevdir. Model talimat okur, metin üretir, bitti. LLM sonucunu human review eder, approve eder, gönderir. Bunu agent altyapısında sarmalamak: tool calling loop, state tracking, auto write-back, sadece gecikme ve maliyet ekler, doğruluk eklemez.

Ekipler en yaygın overengineering burası yapıyorlar. Email composition aracı, iyi bir system prompt ve basit LLM call gerektirir. Multi-session memory değil, tool loop değil, ESP'ye write yetkisi değil. Agent mimarisini çok-system karar ve unsupervised execution gerektiren işler için sakla.

ChatGPT'nin Agent mode'ü bunu bir tek üründe nasıl bulanıklaşır gösterir. Chat yüzeyi çoğu istek için tek turlu chatbot'tur. Agent mode browsing veya dosya multi-step işleme gerektiren alt-kümeler için katmanlanır. Kampanya metni yazarken çoğu ekip hiç Agent mode'e girmez.

Uygulanması gereken test: isteğin karmaşıklığı × sistem sayısı × insansız execution gerekip gerekmediği. Hepsi düşük ise, chatbot doğru araçtır ve daha ucuzdur. Herhangi biri yüksek ise, döngüye ihtiyaç duyarsınız.

Gönderme zamanı optimizasyonu ve rate limiting: ajanın param ettiği gerçek durum

Alıcı başına gönderme zamanı optimizasyonu, email infrastructure'da gerçek agent döngüsünün en net ve high-ROI use case'idir. Sistem şunları yapmalıdır: alıcının historical open pattern'ı oku, domain reputation ve warmup durumunu kontrol et, optimal gönderme penceresini belirle, gönder, sonucu doğrula, warm-up engine input'u güncelle.

Beş sistem bir karar etrafında dönüyor: engagement history, domain warmup status, ESP rate limits, göndermenin outcome'u, internal user segmentation. Tek bir LLM çağrısı tüm bu state'i tutamaz ve aralarında atomic logic uygulamaz. Döngüye gerek var, ve warmup automation'a yazma yetkisine (reputation düştüğünde pause, resume logic).

Bir growth lead bize 40k-kullanıcı yaşam döngüsü e-mail yönetiyoruz dedi: fixed 09:00 send'den per-recipient optimized window'a geçiş, 3 hafta production trust oluşturmaya aldı. Çoğunlukla throttle logic'i spam spike altında izleyerek geçti. Neden? Çünkü döngü write-back sırasında, reputation düştüğü esnada nasıl davranır bunu görmek gerekir. O döngünün gerçek mühendislik maliyeti bu: model çağrısı değil, production'da güvenebileceğin confidence'tır.

Lindy bu bağlamda reference'tır: lifecycle email için tasarlanmamış, ama inbox-triage ve follow-up loop'u aynı observe-reason-act pattern'ı izler. Durumu oku, karar ver, hareket et, doğrula, tekrar et: dar yinelenen görev kapsamında.

Manus aynı döngüyü general-purpose yapar: web browsing, file generation, multi-step research, open-ended reasoning loop. Lifecycle email'de production pipeline'ına hangi seviyede özerklik vermeyi gerçekten istediğinizi görmek için reference point olarak yararlı: demo size vermek isteyebileceğiniz şeydir bu değildir.

İkisi de lifecycle email context'inde tasarlanmamıştır. Mimari pattern'dır mesele.

Döngünün maliyet: gönderme başına latency ve error surface

Döngüdeki her tool çağrısı: network round-trip artı token maliyeti. Chatbot oluşturma: 1-3 saniye, bir model çağrısı. Agent loop, warmup kontrolü+window decision+delivery confirm için 3 tool çağrısı: 3-15+ saniye, ve her adım chain'ın kırılabileceği yer.

Trace seviyesinde ne görmek yapılan ekipleri: lifecycle flow'ına loop-based send-time karar ekleyin. Decision başına gecikme: düşük-saniye, multi-saniye. Error mode değişir: "yanlış copy" yerine "stalled decision, gönderme hiç yapılmadı." İkisi de production'da maliyetli, ama farklı operational problem'ler. Farklı monitoring, farklı alerting, farklı on-call runbooks gerektirir.

ReAct paper'ı, bu loop'un adını verdi, argümanını şöyle yapar: tradeoff sadece görevde external bilgi mid-reasoning gerektiğinde değer katıyor. Konu satırı? External bilgi gerektirmez. Gönderme zamanı optimal window karar? Gerektirir. O çizgi karar etmeli misiniz hakkında dusunmeniz gerekendir.

Headcount ile karşılaştırmada: çok-step görevler için loop hala ekonomiyi kazanır. İnsan her gönderme zamanı kararını manual review ederse, günde birkaç yüz kullanıcı ölçeklenmez. Bir kez trusted bir loop, ölçeklenir. Hata tek-turn oluşturmaya aynı matematik uygulamak: insan review asla bottleneck olmadı zaten.

Biz ne yapardık? Pratik roadmap

Herhangi bir yeni e-mail capability'de chatbot versiyonla başla. Bir LLM çağrısı, açık input, metin output, human review process sonrası. O versiyon ship olduktan sonra ekip repeatedly sınırına vursa: çok-sistem karar gerekli, supervised batch impossible hale gelirse, o zaman loop'u inşa etme saat gelmiş demektir.

Çoğu production lifecycle stack genel-purpose agent'a tüm pipeline'ı gözetleyerek gerek duymaz. Üç dar-scoped loop gerektirir tipik olarak: send-time kararları, throttle-pause-resume, maybe escalation routing. Yanında deterministic kod: no LLM, user segmentation, policy enforcement, audit logging.

Agent vs chatbot sorusu "hangisi daha iyi" hakkında değildir. Karar kaç sistemi aslında dokunduğunu ve bağlanıp bağlanmadığını belirlemek hakkındadır. Mimarinizi sonraya uydurun. Ve dürüst olun hangiyi aslında yapı yaptığınız konusunda.