“AI agent” kavramının popülerleşmesiyle birlikte daha önce otomasyon olarak tanımlanan birçok sistem artık agent olarak pazarlanmaya başladı.
Ancak bir workflow'a LLM eklemek sistemi otomatik olarak AI agent yapmaz.
Klasik otomasyon ile agentic sistem arasındaki temel fark kullanılan yapay zeka modeli değil, sistemin hedefe ulaşmak için nasıl karar verdiğidir.
Klasik otomasyon nedir?
Klasik otomasyon önceden tanımlanmış kuralları takip eder.
Örneğin:
Yeni sipariş geldi
→ stok düş
→ ERP'ye aktar
→ fatura oluştur
→ müşteriye e-posta gönder
Burada sistem hangi adımların uygulanacağını önceden bilir.
AI agent nedir?
AI agent ise verilen bir hedefe ulaşmak için:
- durumu yorumlayabilir,
- gerekli araçları seçebilir,
- ara sonuçları değerlendirebilir,
- sonraki adımı belirleyebilir,
- gerektiğinde planını değiştirebilir.
Örneğin:
“Son iki haftada satışları düşen ürünleri bul, stok ve reklam performanslarını incele ve olası nedenleri bana raporla.”
Agent analytics aracını, stok sistemini ve reklam verisini kullanarak dinamik bir analiz yapabilir.
En temel fark
Automation: “Şu olduğunda şunu yap.”
Agent: “Bu hedefe ulaş; hangi adımlar gerektiğine karar ver.”
AI agent neden her yerde kullanılmamalı?
Deterministik süreçlerde klasik otomasyon çoğu zaman daha doğru çözümdür.
Örneğin “Ödeme başarılıysa faturayı oluştur” işleminde LLM'nin karar vermesine gerek yoktur.
Hangi işler klasik otomasyona daha uygundur?
- stok senkronizasyonu,
- sipariş aktarımı,
- invoice creation,
- webhook processing,
- scheduled report,
- fiyat güncelleme,
- müşteri segmentine tag ekleme,
- transaction event gönderme.
Agent hangi işlerde avantaj sağlar?
Karar ağacının önceden tamamen tanımlanması zor olduğunda agent anlamlı hale gelir.
Örneğin müşteri:
“Geçen hafta aldığım siyah ceketi değiştirmek istiyorum ama aynı bedenin beji varsa onu almak istiyorum.”
Agent mesajı anlamalı, order history açmalı, ürünü bulmalı, stok sorgulamalı, iade/değişim politikasını kontrol etmeli ve uygun aksiyonu belirlemelidir.
Tool calling nedir?
Agent'ın external tool kullanabilmesidir.
Örneğin:
getOrder()checkInventory()findCustomer()createReturn()searchProducts()getAnalytics()
Agent'a doğrudan veritabanı erişimi verilmeli mi?
Genellikle hayır.
Daha sağlıklı mimari:
Agent → Tanımlanmış tools → Application/API layer → Database
şeklindedir.
Human-in-the-loop neden önemli?
Özellikle para transferi, sipariş iptali, yüksek tutarlı refund, fiyat değiştirme ve müşteri hesabında kritik işlem gibi operasyonlarda insan onayı gerekebilir.
Agentic workflow nedir?
Agent ile klasik workflow arasında hibrit modeldir.
Örneğin:
Yeni support ticket geldi
→ AI mesajı analiz eder
→ Workflow gerekli order bilgisini getirir
→ AI talebi politikaya göre değerlendirir
→ Tutar yüksekse insan onayı
→ Tool refund gerçekleştirir
E-ticarette örnek
Müşteri:
“Geçen ay aldığım ürünü yeniden almak istiyorum ama bu kez daha büyük beden gerekiyor.”
AI agent geçmiş siparişleri sorgular, ürünü bulur, önceki bedeni tespit eder, büyük varyantları kontrol eder, stok bulunan varyantı önerir ve kullanıcı onaylarsa sepete ekler.
AI agent ve otomasyon karşılaştırması
| Özellik | Klasik Otomasyon | AI Agent |
|---|---|---|
| Akış | Önceden belirli | Dinamik olabilir |
| Karar verme | Rule-based | Context-based |
| LLM gerekli mi? | Hayır | Genellikle |
| Tool kullanımı | Workflow belirler | Agent seçebilir |
| Predictability | Çok yüksek | Daha düşük |
| Esneklik | Sınırlı | Yüksek |
| Test etmek | Daha kolay | Daha karmaşık |
| Maliyet | Düşük | Daha yüksek |
En iyi production mimarisi
Birçok gerçek sistem için en doğru yapı:
Deterministic Core + Agentic Decision Layer
şeklindedir.
E-ticarette payment, inventory, order creation, pricing, tax ve invoice deterministik kalırken; müşteri talebini anlama, ürün araştırma, ürün karşılaştırma ve operasyon analizi agentic olabilir.
Determinizm spektrumu
Production sistemleri bir spektrumda düşünülebilir:
- Pure deterministic workflow
- Workflow + LLM classification
- Workflow + constrained tool selection
- Agentic planner + deterministic tools
- Highly autonomous agent
Risk arttıkça sistem genellikle spektrumun daha deterministik tarafına çekilmelidir.
Agent'ın karar alanını nasıl sınırlarız?
Kötü:
execute_sql(query)
Daha güvenli:
get_order(order_id)
check_return_eligibility(order_id)
create_return_draft(order_id, items)
submit_return(draft_id, approval_token)
Tool contract tasarımı
Her tool için:
- input schema,
- output schema,
- authorization requirement,
- side effect,
- idempotency behavior,
- timeout,
- error taxonomy
tanımlanmalıdır.
Agent memory ile system of record farklıdır
Memory müşteri tercihi veya konuşma özeti tutabilir. Ancak order, stock, price veya balance gibi ticari gerçekler system of record'dan okunmalıdır.
Memory'de “ürün stokta” yazması gerçek stok garantisi değildir.
Evaluation nasıl yapılmalı?
| Senaryo | Ölçüm |
|---|---|
| Basit ürün arama | doğru ürün recall |
| Belirsiz talep | doğru clarification |
| Refund talebi | policy adherence |
| Yetkisiz işlem | refusal |
| Tool failure | recovery |
| Prompt injection | tool safety |
| Duplicate request | idempotency |
Cost ve latency budget
İzlenebilecek metrikler:
- task completion rate,
- median tool calls/task,
- p95 latency,
- token cost/task,
- human escalation rate.
Agentic mimari teknik olarak çalışsa bile ekonomik olarak çalışmayabilir.
Hangi problem agent'a verilmemeli?
İşin doğru adımlarını önceden açıkça ve eksiksiz tanımlayabiliyorsanız deterministik workflow genellikle daha doğrudur.
Hibrit support örneği
User message
→ LLM intent extraction
→ deterministic customer/order lookup
→ policy engine
→ LLM explanation
→ risky action? approval
→ deterministic mutation tool
→ audit log
Bu tasarım AI'ın güçlü olduğu dil/yorum katmanını kullanırken para ve sipariş state'ini kontrollü tutar.
Mimari seçim kuralı
Bir görevi değerlendirirken:
- input yapısal mı?
- karar ağacı deterministik mi?
- yanlış karar maliyeti yüksek mi?
- doğal dil yorumu gerekiyor mu?
- tool seçimi dinamik mi?
soruları cevaplanabilir.
Deterministik + yüksek risk → klasik workflow.
Belirsiz + düşük/orta risk → agentic layer.
Belirsiz + yüksek risk → agent + approval + deterministic policy engine.
Bu çerçeve “her yere agent ekleyelim” yaklaşımını engeller.
Sonuç
AI agent klasik otomasyonun “daha gelişmiş versiyonu” değildir.
Farklı bir problem sınıfını çözer.
Reliefers olarak AI agent projelerinde LLM katmanını tek başına ürün olarak görmüyoruz. Agent'ı mevcut API'ler, e-ticaret altyapısı, ERP, CRM, analytics ve operasyon sistemleriyle güvenli şekilde çalışan bir application layer olarak tasarlıyoruz.