Yapay Zeka 'Agent'ı Nedir? Tekrarlayan Ofis İşini Nasıl Otomatikleştiriyor

Bir yapay zeka 'agent'ı, tek bir soruya tek seferde cevap veren bir chatbot değil; sana verilen bir hedefi kendi başına, birden fazla adımda ve gerektiğinde araçlar kullanarak tamamlamaya çalışan bir sistem. 'Şu faturaları kontrol et, tutmayanları işaretle ve ilgili kişilere taslak e-posta hazırla' dediğinde agent bunu tek bir LLM çağrısıyla yapmıyor; veriye bakma, karar verme, bir araç çağırma ve sonucu değerlendirme adımlarını kendi kendine art arda zincirliyor, gerekirse planını yeniden kuruyor. Bu yazıda yapay zeka agent'ının gerçekte ne olduğunu, tekrarlayan ofis işini nasıl otomatikleştirdiğini, gerçek bir senaryoyla nasıl kurulduğunu ve nerede hâlâ insan gözetimine ihtiyaç duyduğunu anlatacağım.

##Yapay zeka agent'ını chatbot'tan ve klasik otomasyondan ayıran şey ne?

Üç katmanı birbirine karıştırmak kolay, ama aralarındaki fark net. Bir chatbot tek turlu çalışır: sen bir şey sorarsın, o cevap verir; konuşma geçmişini hatırlar ama kendi başına bir eylem gerçekleştirmez — birinin o cevabı okuyup elle bir şey yapması gerekir. Zapier veya Make gibi klasik otomasyon araçları ise sabit bir kural zinciridir: 'şu tetiklenirse şunu yap' mantığı baştan insan tarafından tasarlanmıştır, araç sadece o sabit akışı yürütür, karar vermez. Agent üçüncüsü: ona bir hedef ve bir araç seti verirsin, hangi adımı ne zaman atacağına kendisi — her adımda yeniden değerlendirerek — karar verir. Bir fatura beklenenden farklı çıkarsa, klasik otomasyon önceden tanımlanmış tek bir yola gider (genelde 'hata' diye durur); agent ise 'bu farkı araştırayım, ilgili siparişi bulayım, gerekirse ilgili kişiye soru sorayım' diye kendi planını kurabilir.

Bu yüzden agent'ı otomasyon araçlarının 'daha akıllı versiyonu' gibi düşünmek yanıltıcı — asıl fark akıl yürütmenin nerede olduğu. Otomasyon aracında akıl yürütme kurulum anında, insanın kafasında gerçekleşir ve sabitlenir; agent'ta akıl yürütme çalışma anında, her seferinde yeniden yapılır. Bu da agent'ı hem daha esnek hem de daha öngörülemez kılıyor — aynı görevi iki kez çalıştırdığında farklı bir yoldan gidebilir, bu da ileride değineceğimiz gözetim ihtiyacının kaynağı. Pratik sonucu şu: bir otomasyon senaryosunu test ettiğinde her çalıştırmada aynı sonucu beklersin, bir agent'ı test ettiğinde ise 'genelde doğru sonuca ulaşıyor mu' sorusuna bakman gerekir — bu da test etme ve güvenme biçimini kökten değiştirir.

##Bir agent gerçekte nasıl çalışır: algıla-düşün-uygula döngüsü

Teknik olarak bir agent, bir LLM'i bir döngü içine koyar. Sürece bir hedef ve bir sistem talimatı ile başlar; LLM bu hedefe bakıp 'şu an atılacak en mantıklı adım ne' diye akıl yürütür ve genelde bir 'araç' (tool/function) çağırır — bir API isteği, bir veritabanı sorgusu, bir dosya okuma, bir e-posta taslağı oluşturma. Bu çağrı 'function calling' olarak bilinen mekanizmayla çalışır: modele önceden hangi araçları hangi parametrelerle çağırabileceği tanımlanır, model de metin yerine yapılandırılmış bir çağrı üretir. Araç çalışır, sonucu modele geri döner, model bu sonucu değerlendirip hedefe ulaşıldı mı yoksa bir adım daha mı gerekiyor diye karar verir. Bu 'düşün-uygula-gözlemle' döngüsü hedefe ulaşana ya da önceden konan bir adım/maliyet limitine çarpana kadar devam eder — limit olmazsa sonsuz döngüye girme riski gerçek, bu yüzden her ciddi agent kurulumunda mutlaka bir üst sınır olur.

• ▸Açık ve dar bir hedef tanımı — 'ofisi otomatikleştir' değil, 'gelen faturaları satınalma siparişleriyle eşleştir' gibi somut bir görev
• ▸Sınırlı bir araç seti — sadece gerekli API/fonksiyon tanımları, gereksiz yetki verilmez
• ▸Kısa süreli hafıza — önceki adımların özeti, döngü içinde bağlamı taşımak için
• ▸Adım/maliyet limiti — sonsuz döngüyü ve kontrolsüz harcamayı önleyen bir sayaç
• ▸Loglama — her adımda hangi aracın hangi parametrelerle çağrıldığının kaydı
• ▸Riskli adımlarda insan onayı — geri alınamaz eylemler otomatik değil, onaylı yürür

##Gerçek bir senaryo: bir muhasebe ekibinde fatura eşleştirme agent'ı

Bunu somutlaştırmak için anonimleştirdiğim gerçek bir örneği anlatayım. On iki kişilik bir operasyon ekibi, tedarikçilerden gelen PDF faturaları her sabah tek tek açıp ERP'deki satınalma siparişleriyle elle karşılaştırıyordu — günde ortalama 30-40 fatura, kişi başı neredeyse bir saat. Kurulan agent şöyle çalışıyor: e-posta kutusunu izliyor, gelen her PDF faturayı bir OCR+LLM adımıyla okuyup tutar/tarih/miktar bilgisini çıkarıyor, ardından ERP'de eşleşen satınalma siparişini arıyor. Tutar ve miktar tolerans aralığında eşleşiyorsa faturayı otomatik onaylanmış olarak işaretleyip kaydı düşüyor; eşleşme yoksa ya da fark toleransı aşıyorsa, ilgili tedarikçiye veya iç ekibe gönderilecek bir açıklama e-postası taslağı hazırlayıp faturayı bir 'incelenecek' kuyruğuna düşürüyor. Ekibin gördüğü şey basit bir panel: 'otomatik onaylanan', 'incelemede bekleyen' ve 'taslak e-posta hazır' olmak üzere üç sütun. Haftalık rutin değişti — artık her faturayı tek tek açmıyorlar, sadece kuyruğa düşen yaklaşık her beş faturadan birini gözden geçirip taslak e-postayı ya onaylıyor ya da düzeltiyorlar.

##Nasıl kurulur (kısaca)

Bir agent'ı sıfırdan büyük ve uçtan uca bir sistem olarak kurmaya çalışmak en sık yapılan hata; küçük ve dar başlamak hem daha hızlı sonuç veriyor hem de hataları erken yakalıyor. Aynı mantık bir yazılım projesine yeni bir özellik eklerken de geçerli — önce en dar kapsamda çalışan bir sürüm çıkarıp gerçek kullanımda gözlemlemek, baştan geniş kapsamlı planlamaktan neredeyse her zaman daha az riskli.

• ▸Tek, dar ve tekrarlayan bir görevle başla — tüm süreci değil, en acı veren tek adımı hedefle
• ▸Araçları en az yetkiyle tanımla — silme, ödeme gibi geri alınamaz eylemler için ayrı bir onay adımı ekle
• ▸Önce sadece okuma (read-only) yetkisiyle test et, sonuçlar tutarlı olunca yazma yetkisi ekle
• ▸Her adımı logla ve adım sayısına üst limit koy — hem maliyeti hem hata riskini sınırlar
• ▸Riskli/geri alınamaz eylemlerde insan onayı iste, otomatik yürütme sadece düşük riskli adımlarda kalsın
• ▸Haftalık olarak flagged/hatalı vakaları gözden geçirip talimat ve araç tanımlarını buna göre iyileştir

##Nerede gerçekten işe yarıyor, nerede hâlâ insan gerekiyor

Dürüst olmak gerekirse agent'lar her yerde aynı güvenilirlikte çalışmıyor. Maliyet tarafında her adım ayrı bir LLM çağrısı demek — beş adımlık bir görev, tek bir soru-cevaba göre birkaç kat daha fazla token tüketir, bu yüzden adım sayısını sınırlamak hem güvenlik hem bütçe meselesi. Doğruluk tarafında model bazen yanlış bir araç parametresi 'uydurabilir' (örneğin var olmayan bir sipariş numarasıyla arama yapmaya çalışabilir) ya da gereksiz yere fazladan adım atabilir; iyi tasarlanmış bir sistemde bu, sonucu bozmadan önce loglardan ya da bir doğrulama adımından yakalanır. Eğitim verisinde az görülen uç durumlarda (nadir bir fatura formatı, alışılmadık bir para birimi, eksik bir alan) davranış da öngörülemez hale gelebilir — bu yüzden 'düşük riskli ama sık tekrar eden' işler agent için ideal, 'nadir ama yüksek riskli' işler için hâlâ insan gerekiyor. En net sınır geri alınamaz eylemlerde: para transferi, veri silme, müşteriye doğrudan giden bir e-posta gibi işlerde agent'ın kararını otomatik yürütmek yerine bir insanın onayına düşürmek, bu teknolojiyle çalışırken en önemli güvenlik kuralı. İyi çalıştığı yer ise net: okuma ağırlıklı, iyi tanımlanmış, orta hacimli ve tekrarlayan görevler — fatura eşleştirme, kayıt sınıflandırma, rapor taslağı hazırlama, gelen kutusunu önceliklendirme gibi işler.

##Sık Sorulan Sorular

>Yapay zeka agent'ı ile chatbot arasındaki fark tam olarak ne?

Chatbot tek turlu çalışır — soruya cevap üretir, konuşma hafızası tutar ama kendi başına bir eylem gerçekleştirmez. Agent ise kendisine verilen bir hedefi, araçlar kullanarak, birden fazla adımda ve her adımda yeniden karar vererek tamamlamaya çalışır. Chatbot 'söyler', agent 'yapar'.

>Bir agent yanlış bir eylem yaparsa sorumluluk kimde olur?

Sorumluluk her zaman sistemi kuran ve işleten tarafta kalır, teknoloji bunu değiştirmez. Bu yüzden loglama, adım limiti ve özellikle geri alınamaz eylemlerde insan onayı zorunlu tutmak — 'agent karar versin, insan onaylasın' modeli — pratikte en güvenli kurulum.

>Küçük bir işletme kendi agent'ını nasıl kurar — hazır araç mı, özel kod mu?

Basit ve tek servisli senaryolar için hazır agent platformları (n8n'in agent düğümleri, LangChain tabanlı araçlar, büyük model sağlayıcılarının kendi agent SDK'ları) hızlı bir başlangıç sağlar. İş mantığı özelleştikçe, birden fazla iç sisteme bağlanmak gerektikçe ya da geri alınamaz eylemler devreye girdikçe, izinleri ve onay akışını tam kontrol edebildiğin özel bir kurulum daha güvenilir hale geliyor.

>Agent'lar chatbot'ların ya da Zapier gibi otomasyon araçlarının yerini mi alıyor?

Hayır, tamamlıyor. Tek bir soruya hızlı cevap için chatbot hâlâ en pratik seçenek; düşük hacimli, tek yönlü ve sabit kurallı işler için Zapier/Make hâlâ en ucuz ve en az bakım isteyen yol. Agent, karar gerektiren, birden fazla adımlı ve verinin göreve göre değiştiği tekrarlayan işlerde devreye giriyor — üçü de birbirinin yerine değil, farklı iş tiplerine göre bir arada kullanılıyor.

>Bir agent'ı çalıştırmanın maliyeti nedir?

Her adım ayrı bir LLM çağrısı olduğu için maliyet, tek bir soru-cevaba göre kat kat artabilir; beş-on adımlık bir görev, kullanılan modele ve adım sayısına göre birkaç kuruştan birkaç TL'ye kadar değişen bir maliyete çıkabilir. Gerçek maliyeti önceden tahmin etmenin yolu, dar bir görevle küçük bir pilot çalıştırıp adım başına ortalama token tüketimini ölçmekten geçiyor — büyük ölçekte devreye almadan önce bu rakamı bilmek, sürpriz bir fatura almamanın en pratik yolu.

Kendi ekibindeki tekrarlayan bir iş akışının agent ile otomatikleştirilmeye uygun olup olmadığını konuşmak istersen /contact üzerinden birkaç soruyla başlayabiliriz; otomasyon araçlarıyla özel yazılım arasındaki genel sınırı merak ediyorsan ilgili yazımıza da göz atabilirsin.