Bir form doldurulduğunda e-posta gönderen sistem de bir işi otomatik yapar. Gelen talebi okuyup hangi bilgiye ihtiyaç duyduğunu belirleyen, izinli araçlardan bilgi toplayan ve bir sonraki adımı seçen sistem de. İkisine aynı adı verdiğimizde aralarındaki önemli fark kayboluyor: Sonraki adımı kim belirliyor?
Bu ayrım, yalnızca teknik bir isim meselesi değil. Sistemin ne kadar öngörülebilir olacağını, nasıl test edileceğini ve hangi yetkileri alacağını etkiliyor.
Otomasyonda yol çoğunlukla önceden bellidir
Basit bir akış düşünelim: Web formuna talep gelir, zorunlu alanlar kontrol edilir, kayıt müşteri listesine eklenir ve ilgili çalışana bildirim gönderilir. Koşulları ve sıralamayı önceden siz tanımlarsınız. Beklenmeyen bir durum için de bir kural veya hata yolu gerekir.
Otomasyonun içinde yapay zekâ bulunabilir. Örneğin gelen metni özetleyen bir adım eklemek, bütün akışı kendiliğinden bir ajana dönüştürmez. Model yalnızca belirlenmiş işin bir parçasını yapıyor olabilir.
Ajanda adımların seçimi daha esnektir
Bir yapay zekâ ajanına amaç ve kullanabileceği araçlar verilir. Sistem, bu sınırlar içinde hangi bilginin eksik olduğuna ve sıradaki uygun işleme karar verebilir. Anthropic'in mimari ayrımı da önceden tanımlanmış iş akışlarıyla modelin adımları ve araç kullanımını dinamik olarak yönettiği ajanları ayırır.
Örneğin bir destek ajanı, talebin içeriğine göre ürün belgesine bakmayı veya daha önceki servis kaydını aramayı seçebilir. Yine de her üründe aynı yetenekler bulunmaz. Satıcının “ajan” demesi, sistemin hangi işlemleri yapabildiğini tek başına açıklamaz.
Aynı iş iki farklı şekilde kurulabilir
Bir teklif talebinin hazırlanmasını ele alalım. Kurallı bir akışta sistem, belirli alanları kontrol eder, hazır bir şablona bilgileri yerleştirir ve çalışanın incelemesine sunar. Talepler birbirine benziyorsa bu yapı yeterli olabilir.
Daha esnek bir sistemde ise model, talepteki belirsizlikleri ayırır; izin verilmiş katalog ve önceki kayıtlar içinde arama yapar; hangi açıklamanın istenmesi gerektiğini önerir. Bu esneklik yararlı olabilir ama yanlış kaynak seçme veya gereksiz işlem yapma gibi yeni kontrol ihtiyaçları da doğurur.
Bu bir tasarım örneğidir. Belirli bir ürünün hazır olarak bunların tamamını sunduğu anlamına gelmez.
Esnekliğin yanına sınır koymak gerekir
Bir ajana araç bağlamak, o araçtaki bütün işlemleri açmak demek değildir. Belgeyi okumakla belgeyi değiştirmek, taslak oluşturmakla müşteriye göndermek ayrı yetkilerdir.
- Hangi kayıtlara erişebileceğini tanımlayın.
- Gönderme, silme veya ödeme gibi işlemler için uygun onayı belirleyin.
- Deneme süresi, işlem sayısı ve maliyet için sınır koyun.
- İşlem kayıtlarını ve hata halinde durma yolunu tasarlayın.
- Yanlış çıktıları, yalnızca başarılı örnekler kadar dikkatle test edin.
Müşteriye gönderilecek teklifin onayını çalışanda bırakmak, bu sınırların anlaşılır bir örneğidir. Onay ekranı da sadece bir düğmeden ibaret olmamalı; kişi neyin gönderileceğini ve bilginin nereden geldiğini görebilmeli.
Her işin ajana ihtiyacı yok
Girdi ve çıktı belliyse, kurallar nadiren değişiyorsa ve istisnalar yönetilebiliyorsa sade bir otomasyon daha kolay işletilebilir. Yol her talepte değişiyorsa, farklı kaynaklar arasında seçim gerekiyorsa ajan yaklaşımı değerlendirilebilir. Ek esnekliğin getirdiği zaman, maliyet ve kontrol yükünü de hesaba katmak gerekir.
Satıcıya sorulacak iyi soru şu: “Sistem hangi adımı kendi seçiyor, hangi adımı bizim kuralımız belirliyor?” Ardından gerçek bir istisna gösterip ne yaptığını izleyin. Etiketten çok, o davranış size karar vermeniz için bilgi verecektir.
Kaynak ve kapsam
Kavramsal ayrım için Anthropic — Building effective agents. Teklif ve destek senaryoları bu yazının açıklayıcı örnekleridir; ürün karşılaştırması değildir.