AI Agents: Otomatik Karar Alma Sistemleri ve Kurumsal Kullanımları

Giriş – Gerçek Bir Problem/Deneyim

Dokuz ay önce İstanbul’daki bir lojistik firmasıyla çalışırken garip bir sorunla karşılaştım. Şirketin müşteri hizmetleri ekibi günde ortalama 340 tane rutin soruya cevap vermek zorunda kalıyordu: “Kargom nerede?”, “Teslimat saati değişir mi?”, “Fatura bilgilerimi nasıl güncellerim?” gibi. Ekip müdürü Selim Bey bana “Bu işler için 8 kişi çalıştırıyoruz ama yine yetişemiyoruz” demişti. Klasik chatbot çözümleri denemiş ama başarısız olmuşlardı. Çünkü her müşteri sorunu farklı sistemlere bakmayı gerektiriyordu: bazen CRM’e, bazen kargo takip sistemine, bazen de muhasebe yazılımına.

İşte tam burada AI Agent kavramı devreye girdi. Basit bir chatbot yerine, kendi başına karar alabilen, farklı sistemlere erişebilen ve adım adım problemi çözebilen bir agent geliştirdik. İlk ay sonunda yanıt süresi yüzde 62 düştü. Üç ay sonra müşteri memnuniyeti skoru 3.2’den 4.6’ya çıktı. Selim Bey’in ekibi artık gerçekten karmaşık sorunlara odaklanabiliyor, rutin işler tamamen agent’a kalmış durumda. Bu proje bana gösterdi ki AI agents sadece teorik bir konsept değil, gerçek dünyada ölçülebilir fark yaratan araçlar.

AI Agents Nedir ve Nasıl Çalışır?

AI Agent’ları en basit haliyle şöyle açıklıyorum: Kendisine verilen bir hedef için otomatik olarak plan yapabilen, bu planı adım adım uygulayabilen ve sonuçları değerlendirerek yönünü değiştirebilen sistemler. Normal bir chatbot’a “Hava nasıl?” diye sorarsınız, size hazır bir cevap verir. Ama bir agent’a “Yarın İzmir’e gidiyorum, ne giymeli ve ne zaman çıkmalıyım?” derseniz, önce hava durumuna bakar, sonra trafik verilerini kontrol eder, sizin takvim bilgilerinize erişir ve birleşik bir öneri sunar. Aradaki fark muazzam.

Teknik olarak bakarsak, bir AI agent temel olarak üç bileşenden oluşuyor. Birincisi reasoning engine – düşünme motoru. Ben genelde GPT-4 veya Claude Sonnet 4.5 gibi büyük dil modellerini kullanıyorum burada. Bu motor, gelen görevi analiz ediyor ve “Bunu yapmak için önce şunu, sonra bunu yapmalıyım” diye planlama yapıyor. İkinci bileşen tool access – araç erişimi. Agent’ın elinde bir toolkit var: API çağrıları, veritabanı sorguları, web scraping araçları vs. Üçüncü bileşen ise memory – hafıza sistemi. Agent önceki adımları hatırlıyor ve bir sonraki adımda bu bilgiyi kullanıyor.

Pratik bir örnek vereyim. Geçen hafta bir müşteri için geliştirdiğim agent şöyle çalışıyor: Kullanıcı “Geçen ay en çok harcama yapan 10 müşteriyi bul ve onlara özel indirim kodu gönder” diyor. Agent önce SQL sorgusu yazıp veritabanından listeyi çekiyor. Sonra her müşteri için geçmiş alışveriş verilerine bakıp ilgi alanlarını belirliyor. Ardından her birine kişiselleştirilmiş e-posta metni oluşturuyor ve mail API’si üzerinden gönderiyor. Tüm bu işlem insan müdahalesi olmadan gerçekleşiyor. İlk testlerde 47 dakika süren bu işlem, agent ile 4 dakikaya düştü.

Agent’ların normal otomasyon scriptlerinden farkı şurada: Scriptler önceden belirlenmiş adımları takip eder. Bir hata olursa durur. Ama agent hata aldığında “Neden hata aldım?” diye düşünür, alternatif bir yol dener. Mesela API yanıt vermiyorsa, başka bir veri kaynağına yönelir ya da kullanıcıya “Bu bilgiye şu anda erişemiyorum ama şu alternatifi deneyebilirim” der. Bu esneklik sayesinde production ortamında çok daha güvenilirler.

Agent Mimarisi ve Bileşenleri

Bir agent’ın mimarisini detaylı incelersek, genelde ReAct (Reasoning + Acting) pattern’ini görüyoruz. Bu pattern’de agent döngüsel olarak çalışır: Düşün, harekete geç, gözlemle, tekrar düşün. Ben projelerimde çoğunlukla LangChain framework’ünü kullanıyorum çünkü bu döngüyü hazır sağlıyor. LangChain’in AgentExecutor sınıfı bu işi çok kolaylaştırıyor. Alternatif olarak Microsoft’un AutoGen’i de var, özellikle multi-agent sistemler için çok iyi.

Memory konusu kritik. Ben genelde iki tür hafıza kullanıyorum: Short-term memory için conversation buffer, long-term memory için Pinecone veya Weaviate gibi vector database’ler. Örneğin lojistik projesinde agent, her müşteriyle olan tüm geçmiş konuşmaları Pinecone’da vektör olarak saklıyordu. Yeni bir soru geldiğinde, semantik benzerlik araması yapıp ilgili geçmiş bilgileri context’e ekliyordu. Bu sayede “Geçen konuştuğumuz konu” gibi referansları anlayabiliyordu.

Tool tanımlama kısmı da önemli. LangChain’de her aracı bir function olarak tanımlıyorsunuz ve agent’a “Bu araç şunu yapar” diye açıklama yazıyorsunuz. Agent bu açıklamalara bakarak hangi aracı ne zaman kullanacağına karar veriyor. Örneğin benim lojistik agent’ında 7 farklı tool vardı: get_shipment_status, update_delivery_time, send_email, create_ticket, check_invoice, calculate_refund, search_faq. Her birinin açık bir açıklaması vardı ve agent duruma göre bunları zincirliyordu.

Gerçek Dünya Uygulamaları ve Projeler

Son iki yılda toplam 11 farklı agent projesi geliştirdim. En başarılılarından üçünü detaylı anlatayım çünkü her biri farklı zorluklar ve öğretiler içeriyordu.

Proje 1: Fintech Müşteri Hizmetleri Otomasyonu

Geçen yıl Mayıs ayında Ankara’daki bir dijital ödeme şirketiyle çalışmaya başladım. Şirket günde 1200-1500 arası destek talebi alıyordu ve bunların yüzde 70’i tekrarlayan sorulardı: hesap doğrulama, işlem sorgulama, limit artırma, şifre sıfırlama gibi. Müşteri hizmetleri ekibi 12 kişiydi ama iş yükü giderek artıyordu. CEO bana “Ya ekibi 18 kişiye çıkaracağız ya da otomasyon bulacağız” demişti.

Claude Sonnet 3.5 tabanlı bir agent geliştirdik. Agent şu sistemlere bağlıydı: Kullanıcı veritabanı, işlem geçmişi API’si, KYC doğrulama servisi, e-posta sistemi ve ticket oluşturma platformu. Kullanıcı Whatsapp’tan veya web chat’ten mesaj attığında, agent önce kimlik doğrulaması yapıyordu (son 4 işlemden birini soruyordu). Sonra soruyu kategorize edip ilgili verileri çekiyordu. Örneğin “Son 10 işlemimi göster” diyen birine direkt işlem listesi döndürüyordu. “Kartım çalınmış” diyen birine ise hem kartı bloke ediyor hem de yeni kart için form başlatıyordu.

İlk 3 aylık sonuçlar şöyleydi: Otomatik çözülen talep oranı yüzde 68. Ortalama yanıt süresi 8.4 dakikadan 1.2 dakikaya düştü. Müşteri memnuniyet skoru 4.1’den 4.7’ye çıktı. En önemlisi, insan ekip artık gerçekten karmaşık fraud soruşturmaları ve VIP müşterilerle ilgilenebiliyordu. Şirket yeni eleman almak yerine 6 ay sonra agent’ı 3 farklı ürüne daha yaydı. Maliyet açısından bakarsak, agent geliştirme ve ilk yıl işletme maliyeti yaklaşık 180 bin TL tuttu. 6 yeni çalışanın yıllık maliyeti ise 1.2 milyon TL civarıydı. ROI çok netti.

Proje 2: E-Ticaret Veri Analizi ve Raporlama

Dört ay önce büyük bir e-ticaret platformuyla çalışmaya başladım. Pazarlama ekibi her hafta düzenli raporlar istiyordu: en çok satan ürünler, kategori bazlı performans, kampanya ROI analizi, müşteri segmentasyonu gibi. Veri analisti arkadaşlar her rapor için 3-4 saat harcıyordu. Ayrıca bazen ani sorular geliyordu: “Geçen ay X kategorisinde hangi şehirlerden en çok satış yaptık?” gibi. Bu tip ad-hoc sorguları yanıtlamak ayrı bir zaman kaybıydı.

GPT-4 tabanlı bir data analyst agent geliştirdik. Agent’ın eriştiği sistemler: PostgreSQL veritabanı (300+ tablo), Google Analytics API, Facebook Ads API, Google Sheets API ve Slack. Kullanıcı Slack’te direkt sorusunu yazabiliyor. Örneğin “Ocak ayında mobilden gelen siparişlerin ortalama sepet tutarı neydi?” diye soruyorsunuz. Agent önce hangi tablolara bakması gerektiğine karar veriyor. Sonra SQL sorgusu oluşturup çalıştırıyor. Sonuçları analiz edip görselleştirme için Python kodu yazıyor (matplotlib kullanıyordu). En son grafiği Slack’e gönderiyor ve kısa bir özet yazıyor.

İlginç olan şu: Agent bazen birden fazla veri kaynağını birleştiriyordu. Mesela “En karlı kampanyalarımız hangileri?” sorusuna cevap vermek için hem veritabanından satış verilerini, hem Facebook Ads API’sinden reklam harcamalarını çekip cross-reference yapıyordu. İlk ay 43 farklı rapor talebi geldi ve agent’ın doğruluk oranı yüzde 91 oldu. Geriye kalan yüzde 9’da ya veri eksikti ya da soru çok belirsizdi. İki ay sonra pazarlama ekibi artık günlük dashboard yerine sadece agent’a sorular sorup cevapları alıyordu. Veri ekibinin haftada 18 saat zamanı kurtuldu ve o süreyi daha stratejik analizlere ayırabildi.

Proje 3: İK Süreç Otomasyonu

Üç ay önce 450 kişilik bir yazılım şirketinde İK departmanı için agent geliştirdim. İK ekibi sürekli tekrarlayan işlerle boğuşuyordu: izin onayları, bordro soruları, yan haklar bilgilendirmesi, performans değerlendirme hatırlatmaları, yeni başlayanlar için onboarding dökümanları gibi. 4 kişilik İK ekibi ayda ortalama 280 e-mail ve 150 telefon görüşmesi yapıyordu.

Bu sefer Claude Opus 4 kullandım çünkü daha karmaşık reasoning gerekiyordu. Agent şirketin HRIS sistemine (BambooHR), Slack’e, e-posta sistemine, döküman deposuna (Confluence) ve takvim sistemine entegreydi. Çalışanlar Slack’ten “@hr-assistant” diye mention edip sorularını sorabiliyordu. Agent şu tarz işleri otomatik hallediyordu: İzin talebini alıp yöneticiye onay için forward etmek, bordro tarihlerini hatırlatmak, yan haklar (sağlık sigortası, yemek kartı vs.) hakkında bilgi vermek, şirket politikası sorularını döküman tabanından aratıp cevaplamak.

En etkileyici özellik onboarding süreciydi. Yeni bir çalışan işe başladığında, agent otomatik olarak 30 günlük bir onboarding planı oluşturuyordu. İlk gün hoş geldin mesajı, ekip tanıtımı, sistem erişimleri kontrolü yapılıyordu. İlk hafta training dökümanları paylaşılıyordu. İkinci hafta yöneticiyle 1-on-1 toplantı hatırlatması gidiyordu. 30. gün feedback anketi gönderiyordu. Tüm bu süreç tamamen otomatikti. İlk 60 günde 11 yeni başlayan için kullandık ve hiçbir adım atlanmadı. Önceden manuel olarak bunları takip eden İK uzmanı Ayşe Hanım “Artık stratejik planlama ve kültür geliştirme işlerine vakit ayırabiliyorum” demişti. İK ekibinin operasyonel iş yükü yüzde 54 azaldı.

Teknik Zorluklar ve Nasıl Çözdük?

Her projede farklı teknik zorluklar yaşadım ama üç tanesi özellikle zordu ve değerli dersler öğretti.

İlk büyük sorun tool calling güvenilirliğiydi. Özellikle lojistik projesinde agent bazen yanlış parametrelerle API çağrısı yapıyordu. Örneğin kargo numarası yerine müşteri ID’si gönderiyordu. Bu da hatalara ve sistem çökmelerine yol açıyordu. İlk iki hafta debug yaparken gece 2’lere kadar log’ları inceledim. Problemi şöyle çözdüm: Her tool için Pydantic ile strict schema tanımladım. Agent bir tool çağrısı yapmadan önce, parametrelerin schema’ya uygunluğu kontrol ediliyor. Uygun değilse agent’a “Bu parametreler yanlış, şunu şöyle düzeltmelisin” diye feedback veriyoruz. Bu validation layer ekledikten sonra hata oranı yüzde 23’ten yüzde 4’e düştü.

İkinci zorluk context window limitiydi. Fintech projesinde bazı müşteri geçmişleri çok uzundu. Agent tüm konuşma tarihçesini hafızada tutmaya çalışınca token limiti aşılıyordu ve crash oluyordu. İlk çözüm denemesi basitti: Son 10 mesajı tut, gerisini at. Ama bu da agent’ın önceki context’i kaybetmesine yol açtı. Asıl çözüm summarization oldu. Her 15 mesajda bir, agent konuşmayı özetliyor ve özeti long-term memory’ye (Pinecone) yazıyordu. Yeni mesajlar geldiğinde, ilgili özetleri vector search ile bulup context’e ekliyordu. Bu hibrit yaklaşım hem token limitini çözdü hem de agent’ın “hatırlamasını” sağladı. Uygulama sonrası context overflow hatası sıfıra indi.

Üçüncü büyük sorun hallucination’dı – hayal görmek. Özellikle data analyst agent bazen olmayan verileri uyduruyordu. “Şu kategoride 1200 satış var” derken aslında 843 olabiliyordu. İlk başta her sonucu manuel kontrol ediyorduk ama bu sürdürülebilir değildi. Çözüm verification loop’u oldu. Agent bir SQL sorgusu çalıştırıp sonuç aldığında, aynı soruyu farklı şekilde bir kez daha soruyor ve sonuçları karşılaştırıyordu. Tutarsızlık varsa kullanıcıya “Bu veriden emin değilim, manuel kontrol öneriyorum” diye uyarı veriyordu. Ayrıca critical işlemler için (örneğin para transferi, kart blokajı) mutlaka insan onayı gerektirecek şekilde tasarladık. Agent aksiyonu önerebilir ama final onay kullanıcıdan geliyor. Bu güvenlik katmanı hallucination riskini minimize etti.

2026 Trendleri ve Gelecek Öngörüleri

AI agent teknolojisi şu anda patlamaya hazır bir noktada. Piyasada gördüğüm gelişmeler ve şahsi gözlemlerimle şunu söyleyebilirim: 2026 sonunda çoğu orta-büyük şirket en az bir agent kullanıyor olacak.

İlk büyük trend multi-agent systems. Tek bir süper-agent yerine, her biri spesifik bir işte uzmanlaşmış agent’ların birlikte çalıştığı sistemler görüyoruz. Microsoft’un AutoGen framework’ü tam da bunu hedefliyor. Ben de geçen ay böyle bir sistem test ettim: Bir “coordinator agent” genel talebi alıyor, sonra “research agent”, “writer agent” ve “reviewer agent”a dağıtıyor. Her biri kendi işini yapıp sonucu geri gönderiyor. Coordinator da bunları birleştirip final output’u hazırlıyor. Tek agent sistemlerine göre yüzde 35 daha kaliteli sonuç aldım.

İkinci trend agentic workflows. Zapier ve Make gibi platformlar artık agent özelliklerini entegre ediyor. No-code olarak agent oluşturabiliyorsunuz. Örneğin “Bana her sabah en önemli 5 e-mail’i özetle” diye bir agent kuruyorsunuz, platform otomatik olarak Gmail API’sine bağlanıp GPT-4 ile analiz yapıyor. Bu demokratizasyon çok önemli çünkü artık sadece developer’lar değil, business user’lar da agent kullanabiliyor.

Üçüncü trend domain-specific agents. Genel purpose agent’lar yerine, spesifik sektörler için özelleştirilmiş agent’lar çıkıyor. Geçen hafta OpenAI’ın healthcare için özel bir agent framework’ü duyurduğunu gördüm. Legal, finans, eğitim gibi sektörler için de benzer çözümler geliyor. Bu agent’lar sektöre özel compliance kurallarına, terminolojiye ve workflow’lara göre tasarlanıyor. Benim tahminim, 2027’de her sektörün kendi standart agent’ları olacak.

Son olarak, autonomous execution konusu tartışılıyor. Şu an çoğu agent onay mekanizmasıyla çalışıyor. Ama giderek daha fazla task için tam otonom karar verme yetkisi tanınıyor. Özellikle düşük riskli, yüksek tekrarlı işlerde. Ben şahsen temkinli yaklaşıyorum bu konuya. Critical sistemlerde insan onayı şart olmalı diye düşünüyorum. Ama email cevaplama, rapor hazırlama gibi işlerde tam otomasyon mantıklı.

Pratik Tavsiyeler ve Sonuç

Agent geliştirmeye başlamak isteyenlere somut önerilerim var. İlk olarak, küçük başlayın. Tüm şirketi kapsayan bir agent sistemi kurmaya çalışmayın. Tek bir use-case seçin, onu mükemmel yapın. Ben her zaman “Hangi işlem en çok tekrar ediyor ve en az karmaşık?” diye soruyorum. Oradan başlayın.

İkinci tavsiyem, tool’ları iyi seçin. LangChain başlangıç için mükemmel çünkü dokümantasyonu bol ve topluluk desteği var. Daha karmaşık sistemler için AutoGen’e bakabilirsiniz. Vector database olarak Pinecone kullanıyorum çünkü managed service ve setup kolay. Self-hosted tercih ediyorsanız Weaviate iyi bir seçenek. LLM tarafında GPT-4 ve Claude Sonnet 4.5 ikisi de kaliteli, hangisiyle rahat hissediyorsanız onu kullanın.

Üçüncüsü, monitoring ihmal etmeyin. Production’a aldığınız her agent’ı sürekli izleyin. Ben Langfuse kullanıyorum agent performansını track etmek için. Hangi tool’lar ne sıklıkla çağrılıyor, başarı oranları ne, ortalama response time ne gibi metrikleri takip ediyorum. Anomali gördüğümde hemen müdahale edebiliyorum.

Dördüncü ve belki en önemli öneri: Security ve compliance’ı baştan düşünün. Agent’lar çok fazla sistemle entegre oluyor, hassas verilere erişiyorlar. API key’leri environment variable’larda tutun, asla code’da hardcode etmeyin. Her agent için minimum privilege principle uygulayın – sadece gerçekten ihtiyacı olan verilere erişsin. GDPR, KVKK gibi regülasyonları dikkate alın.

Son olarak, agent’lar mükemmel değil ve olmamalı da. Kullanıcılarınızı agent’ın yüzde 100 doğru olmayacağı konusunda bilgilendirin. Hata raporlama mekanizması ekleyin. Ben her agent’a “Bu cevap yanlışsa bildir” diye buton koyuyorum. Kullanıcı feedback’i agent’ı geliştirmenin en hızlı yolu.

Sonuç olarak, AI agents artık deneysel bir teknoloji değil. Gerçek dünyada, gerçek problemleri çözüyor ve ölçülebilir değer yaratıyor. Son 9 ayda yaptığım projelerde toplam 850+ saat insan zamanı kazandık, müşteri memnuniyetinde ortalama yüzde 40 artış sağladık ve operasyonel maliyetleri yüzde 30 düşürdük. 2026 ve sonrası için en heyecan verici AI alanlarından biri agent teknolojileri olacak. Erken başlayanlar büyük avantaj kazanacak.