“AI agent kuralım” cümlesi bugün toplantı odalarında çok sık duyuluyor. Ama bu cümlenin arkasında genellikle üç farklı şey kastediliyor: bir chatbot, bir otomasyon akışı ya da gerçekten otonom bir ajan. Üçü aynı şey değil ve üçünün kurulumu da aynı değil.
Bu rehber, AI agent kurulumunun teknik ve operasyonel tarafını baştan sona ele alıyor: hangi görev ajana uygun, hangi mimariyi seçmeli, araçlar nasıl tanımlanır, hafıza nereye yazılır, insan onayı nereye konur, maliyet nasıl kontrol edilir ve proje neden çoğu zaman altıncı ayda ölür.
Bu yazı kurulum yöntemine odaklanıyor. Hizmet kapsamı, agent türleri ve geliştirme süreci için AI agent geliştirme sayfasına bakabilirsiniz. Konuya yeni başlıyorsanız önce yeni başlayanlar için AI ajanı oluşturma rehberini okumanız daha kolay olur.
AI Agent Nedir, Neyi Kurmuyoruz?
Bir AI agent, kendisine hedef verildiğinde adımları kendi planlayan, araçları kendi çağıran, sonuçları değerlendiren ve hedefe ulaşana kadar bu döngüyü sürdüren sistemdir.
Farkı en net şu üçlü tabloda görürsünüz:
| Chatbot | Otomasyon (workflow) | AI Agent | |
|---|---|---|---|
| Girdi | Kullanıcı mesajı | Tetikleyici olay | Hedef |
| Adımlar | Yok, tek cevap | Önceden yazılmış, sabit | Model tarafından belirlenir |
| Araç kullanımı | Genelde yok | Sabit sırayla | Duruma göre, kendi seçer |
| Beklenmedik durum | Cevap veremez | Akış durur | Yeni yol dener |
| Öngörülebilirlik | Yüksek | Çok yüksek | Düşük — bu yüzden denetim şart |
Bu tablodaki son satır, kurulumun en önemli cümlesi: ajan öngörülemezdir. Öngörülebilirlik istediğiniz her yerde ajan değil, kural tabanlı otomasyon kurulur. Ajanı, kuralın yazılamadığı yerde kullanırsınız.
Pratik ayrım kuralı: Süreci bir akış şeması olarak çizebiliyorsanız, ajana ihtiyacınız yok. Çizemiyorsanız — çünkü adım sayısı girdiye göre değişiyor — ajan doğru araçtır.
Kurulum Öncesi Beş Karar
Kod yazmadan veya araç seçmeden önce beş sorunun cevabı netleşmeli. Sahada gördüğüm başarısız projelerin çoğu, bu beşinden en az ikisi belirsizken başlamış projelerdir.
1. Ajan tam olarak hangi görevi devralıyor?
”Müşteri desteğini yönetsin” bir görev tanımı değil. Görev tanımı şuna benzer:
Gelen destek e-postasını oku → talebi sınıflandır → CRM’den müşterinin son 3 siparişini çek → biliniyorsa cevabı taslak olarak yaz → aciliyet yüksekse insana ata
Bu tanımın üç özelliği var: başlangıcı belli, bitişi belli, başarısı ölçülebilir.
2. Ajan hangi araçlara erişecek?
Ajanın yetkisi araçlarıyla sınırlıdır. Araç listesi aynı zamanda güvenlik sınırıdır. Baştan yazın:
- Okuma araçları: veritabanı sorgusu, dosya okuma, web arama, API GET
- Yazma araçları: kayıt oluşturma, e-posta gönderme, dosya yazma
- Geri alınamaz araçlar: ödeme, silme, sözleşme onayı
Üçüncü grup, kurulumun ilk sürümünde hiç bulunmamalı.
3. Otonomi seviyesi ne olacak?
| Seviye | Davranış | Uygun olduğu yer |
|---|---|---|
| L1 — Öneri | Ajan hazırlar, insan uygular | Yüksek riskli, geri alınamaz işler |
| L2 — Onaylı eylem | Ajan yapar, insan onaylar | Dış dünyaya çıkan işler (e-posta, teklif) |
| L3 — Otonom + log | Ajan yapar, insan sonradan denetler | İç süreçler, düşük hata maliyeti |
| L4 — Tam otonom | İnsan yok | Tekrarı çok yüksek, hatası ucuz işler |
Kurulumda L2 ile başlayın. İki–üç hafta log biriktirin, hata oranını ölçün, sonra kademe atlayın. Doğrudan L4 ile başlayan projelerin ilk hatası genellikle müşteriye gider.
4. Ajan neyi hatırlayacak?
Üç ayrı hafıza katmanı vardır ve karıştırılmamalıdır:
- Oturum hafızası: Tek görev boyunca geçen konuşma. Görev bitince silinir.
- Kalıcı hafıza: Oturumlar arası taşınan bilgi (müşteri tercihleri, öğrenilen kurallar). Dosya veya veritabanı.
- Bilgi tabanı (RAG): Şirket dokümanları, ürün bilgisi. Ajan yazmaz, sadece okur.
Çoğu ilk kurulum yalnızca oturum hafızası + bilgi tabanı ile yeterlidir. Kalıcı hafızayı erken eklemek, ajanın yanlış bir öğrenmeyi kalıcılaştırması riskini getirir.
Kritik uyarı: Kalıcı hafızaya asla API anahtarı, token veya kişisel veri yazdırmayın. Hafıza gelecekteki her oturuma aynen geri okunur.
5. Başarı nasıl ölçülecek?
Devreye almadan önce ölçüt tanımlanmazsa, ajanın işe yarayıp yaramadığı tartışma konusu olur. En az şu dördü:
- Tamamlama oranı: Görevlerin yüzde kaçı insansız bitti?
- Devir oranı: Yüzde kaçı insana düştü?
- Düzeltme oranı: Çıktının yüzde kaçı elle düzeltildi?
- Görev başı maliyet: Token + altyapı / tamamlanan görev
Bunlardan düzeltme oranı en kritiğidir. Çıktının yarısı elle düzeltiliyorsa süreç otomatikleşmemiş, sadece yer değiştirmiştir.
Hangi Kurulum Yolunu Seçmeli?
Üç ana yol var. Seçim, ekipteki teknik kapasiteye ve görevin karmaşıklığına göre yapılır.
| Yol | Ne zaman | Artı | Eksi |
|---|---|---|---|
| No-code (n8n, Make) | İlk ajan, basit araç seti, hızlı doğrulama | Günler içinde çalışır, görsel takip | Karmaşık mantıkta kırılgan, özelleştirme sınırlı |
| Kod tabanlı (API + araçlar) | Özel araçlar, ölçek, hassas kontrol | Tam kontrol, test edilebilir | Geliştirici gerektirir, bakım sizde |
| Yönetilen platform | Uzun süren oturumlar, sandbox, zamanlanmış çalışma | Döngü ve altyapı hazır | Platform bağımlılığı |
Hazır bir ajan çerçevesiyle başlamak isterseniz, kalıcı hafıza ve öğrenme döngüsü yerleşik gelen Hermes Agent kurulumu rehberine de bakabilirsiniz.
Tavsiye edilen sıra: Önce no-code ile bir hafta içinde çalışan bir prototip kurun ve süreci gerçekten anlayın. Sonra hangi parçanın özel koda ihtiyacı olduğu netleşir. “Doğru mimariyi baştan kuralım” diye başlayan projeler, çoğunlukla yanlış problemi doğru mimariyle çözer.
Yol 1: No-Code AI Agent Kurulumu (n8n)
n8n’in AI Agent node’u, ajan döngüsünü sizin yerinize yürütür. Kurulum altı adımda tamamlanır.
Adım 1 — Tetikleyiciyi tanımlayın
Ajanı ne başlatacak? Webhook (form gönderimi), yeni e-posta, zamanlanmış tetik (her sabah 09:00) veya Slack mesajı.
Adım 2 — AI Agent node’unu ekleyin
Node üç şey ister: model, sistem talimatı ve araçlar.
Adım 3 — Sistem talimatını yazın
Burası kurulumun kalitesini en çok belirleyen yer. İyi bir sistem talimatı dört bölümden oluşur:
ROL
Sen bir B2B satış ön eleme asistanısın.
GÖREV
Gelen talebi değerlendir, eksik bilgiyi tespit et,
CRM'e kaydet ve uygunsa satış ekibine ata.
ARAÇ KULLANIMI
- crm_ara: Firma adıyla mevcut kaydı kontrol et. Her talepte ilk bunu çağır.
- crm_kaydet: Yeni kayıt oluştur. Sadece crm_ara boş döndüyse kullan.
- ekibe_ata: Bütçe belirtilmişse ve 50.000 TL üzerindeyse kullan.
SINIRLAR
- Fiyat verme, teklif oluşturma.
- Emin olmadığın bilgiyi tahmin etme; "bilgi eksik" olarak işaretle.
- Müşteriye doğrudan e-posta gönderme.
Araç açıklamalarında “ne yaptığını” değil “ne zaman çağrılacağını” yazmak, ajanın doğru aracı seçme oranını belirgin şekilde artırır. En sık yapılan hata, aracı tanımlayıp ne zaman kullanılacağını söylememektir.
Adım 4 — Araçları bağlayın
n8n’de her araç bir alt-node’dur: HTTP Request (kendi API’niz), Google Sheets, Postgres, Gmail, Slack. Her araca anlaşılır bir isim ve net bir açıklama verin — model yalnızca bu metni görür.
Adım 5 — Hafıza ekleyin
Basit başlangıç için “Window Buffer Memory” yeterlidir (son N mesajı taşır). Bilgi tabanı gerekiyorsa bir vektör veritabanı node’u ekleyip dokümanlarınızı indeksleyin.
Adım 6 — Onay adımını koyun
Dışa çıkan her eylemin öncesine bir onay düğümü ekleyin: Slack’e “Bu e-postayı göndereyim mi?” mesajı ve buton. Bu adım, ilk aylarda ajanın en değerli güvenlik ağıdır.
n8n’i kendi sunucunuzda kurmak isterseniz, adım adım kurulum için n8n kurulumu rehberine bakabilirsiniz.
Tipik süre: Basit bir ajan için 2–5 gün. Asıl zaman araç bağlantılarında ve sistem talimatının ince ayarında geçer, node’ları dizmekte değil.
Yol 2: Kod Tabanlı AI Agent Kurulumu
Kod tarafında ajan, özünde bir döngüdür: modele hedefi ve araç listesini ver, model bir araç çağırsın, aracı çalıştır, sonucu geri ver, model bitirene kadar tekrar et.
Ortam hazırlığı
pip install anthropic
export ANTHROPIC_API_KEY=sk-ant-...
Araç tanımlama
Araçlar JSON şeması ile tanımlanır. Açıklama alanı, modelin aracı doğru kullanıp kullanmayacağını belirleyen tek şeydir — üstünkörü yazılmış bir açıklama, hiç yazılmamış gibidir.
tools = [
{
"name": "musteri_ara",
"description": (
"CRM'de firma adına göre müşteri kaydı arar. "
"Bir talebi işlemeye başlamadan önce her zaman ilk bunu çağır. "
"Kayıt bulunamazsa boş liste döner."
),
"input_schema": {
"type": "object",
"properties": {
"firma_adi": {
"type": "string",
"description": "Aranacak firma adı, örn. 'Aydın Metal A.Ş.'"
}
},
"required": ["firma_adi"],
},
},
{
"name": "teklif_taslagi_olustur",
"description": (
"Verilen ürün ve adet bilgisiyle teklif taslağı hazırlar. "
"Taslak müşteriye gönderilmez, yalnızca sisteme kaydedilir. "
"Bütçe bilgisi eksikse çağırma."
),
"input_schema": {
"type": "object",
"properties": {
"musteri_id": {"type": "string"},
"urunler": {
"type": "array",
"items": {"type": "string"},
"description": "Teklife girecek ürün kodları",
},
},
"required": ["musteri_id", "urunler"],
"additionalProperties": False,
},
},
]
Ajan döngüsü
from anthropic import Anthropic
client = Anthropic()
SISTEM = """Sen bir B2B satış ön eleme asistanısın.
Gelen talebi değerlendirir, CRM'i kontrol eder ve uygun olanlar için
teklif taslağı hazırlarsın. Fiyat pazarlığı yapmaz, müşteriye
doğrudan mesaj göndermezsin. Emin olmadığın bilgiyi tahmin etmez,
eksik olarak işaretlersin."""
messages = [{"role": "user", "content": kullanici_talebi}]
while True:
response = client.messages.create(
model="claude-opus-5",
max_tokens=16000,
system=SISTEM,
thinking={"type": "adaptive"},
output_config={"effort": "high"},
tools=tools,
messages=messages,
)
# Model işi bitirdiyse döngüden çık
if response.stop_reason == "end_turn":
break
# Modelin ürettiği içeriği olduğu gibi geçmişe ekle
messages.append({"role": "assistant", "content": response.content})
# Talep edilen araçları çalıştır, sonuçları tek mesajda geri ver
sonuclar = []
for blok in response.content:
if blok.type == "tool_use":
try:
cikti = araci_calistir(blok.name, blok.input)
sonuclar.append({
"type": "tool_result",
"tool_use_id": blok.id,
"content": cikti,
})
except Exception as e:
sonuclar.append({
"type": "tool_result",
"tool_use_id": blok.id,
"content": f"Hata: {e}",
"is_error": True,
})
messages.append({"role": "user", "content": sonuclar})
Bu döngüde dikkat edilecek dört nokta var:
response.content’i olduğu gibi ekleyin. Sadece metni alıp eklerseniz araç çağrı blokları kaybolur ve bir sonraki istek hata verir.- Paralel araç çağrılarını tek mesajda döndürün. Model bir turda birden fazla araç isteyebilir; sonuçları ayrı mesajlara bölerseniz model zamanla paralel çağrı yapmayı bırakır.
- Hatayı yutmayın. Başarısız aracı listeden düşürmek yerine
is_error: trueile geri verin — model o zaman farklı bir yol dener. - Döngüye üst sınır koyun. Sonsuz döngüye karşı basit bir tur sayacı (örn. 25) her zaman bulunsun.
SDK’nın kendi tool_runner yardımcısı bu döngüyü sizin yerinize yürütür ve tur başına araya girme noktaları sunar (onay kapısı, sonuç düzenleme, yeniden deneme). İnsan onayı için döngüyü elle yazmanız gerekmez.
Model seçimi ve maliyet
| Model | Bağlam | Girdi $/1M | Çıktı $/1M | Ne için |
|---|---|---|---|---|
| Claude Opus 5 | 1M | $5 | $25 | Karmaşık, uzun soluklu ajan işleri |
| Claude Sonnet 5 | 1M | $3 | $15 | Dengeli — çoğu üretim ajanı |
| Claude Haiku 4.5 | 200K | $1 | $5 | Sınıflandırma, okuma yoğun alt görevler |
Pratik kurgu: planlama ve karar güçlü modelde, okuma/ayıklama gibi hacimli alt görevler ucuz modelde. Bir araştırma ajanında token’ın çoğu okumaya gider ve bu okuma güçlü modele ihtiyaç duymaz.
effort parametresi ikinci maliyet kolunuzdur: low–max arasında düşünme derinliğini ayarlar. Kodlama ve ajan işlerinde high iyi bir başlangıç noktasıdır; rutin işlerde medium veya low çoğu zaman yeterli sonucu çok daha ucuza verir. Kurulumdan sonra bunu mutlaka kendi işinizde ölçerek seçin — varsayılanı olduğu gibi bırakmak en pahalı seçenektir.
MCP: Araçları Her Seferinde Yeniden Yazmamak
Her ajan projesinde aynı entegrasyonları (Google Drive, GitHub, veritabanı, CRM) baştan yazmak büyük israftır. MCP (Model Context Protocol), bu araçları standart bir arayüz arkasına koyar: bir kez MCP sunucusu olarak tanımlarsınız, tüm ajanlarınız aynı aracı kullanır.
Kurulumda MCP’yi ne zaman düşünmeli:
- Evet: Birden fazla ajan aynı sistemlere bağlanacaksa; hazır MCP sunucusu olan bir servis kullanıyorsanız (GitHub, Linear, Notion vb.)
- Hayır / henüz değil: Tek ajan, iki–üç özel araç. Bu durumda doğrudan araç tanımı daha basit ve daha hızlıdır.
Güvenlik notu: MCP kimlik doğrulaması araç tanımının içine gömülmez. Kimlik bilgileri ayrı bir kasada (vault) tutulur ve isteğe sistem tarafından, sandbox’ın dışında eklenir. Bu ayrım önemlidir: ajanın çalıştırdığı hiçbir kod anahtarı okuyamaz. API anahtarını sistem talimatına veya mesaj içine yazmak — ne kadar pratik görünürse görünsün — o anahtarı oturum geçmişine kalıcı olarak yazmak demektir.
Kurulumun En Çok Atlanan Parçası: Denetim Katmanı
Ajan kurulumunun teknik kısmı bir–iki haftada biter. Projeyi başarılı ya da başarısız yapan kısım denetim katmanıdır ve genellikle “sonra ekleriz” diye ertelenir.
Log: her karar kaydedilmeli
Ajan bir işi yanlış yaptığında sorulacak soru “neden böyle yaptı?” olacak. Bu soruya cevap verebilmek için her tur şunlar kaydedilmeli:
- Hangi hedefle başladı
- Hangi araçları hangi parametrelerle çağırdı
- Her araç ne döndürdü
- Hangi noktada insana devretti
- Toplam token ve süre
Bütçe sınırı: teknik değil, finansal fren
Otonom bir ajan, kötü bir döngüye girdiğinde saatlerce çalışabilir. İki ayrı fren kurun:
- Tur sınırı: Görev başına maksimum araç çağrısı sayısı
- Token/tutar sınırı: Oturum başına üst limit; sınıra ulaşınca ajan durur ve insana düşer
Bu ikisi olmadan üretime çıkan bir ajan, er ya da geç sürpriz bir fatura üretir.
İnsan onay noktaları
Onay noktasını “önemli işlerde” değil, geri alınabilirliğe göre konumlandırın:
| İşin niteliği | Kurgu |
|---|---|
| Geri alınabilir, düşük etkili | Tam otonom, sonradan denetim |
| Geri alınabilir, dışa görünür | Ajan hazırlar → insan onaylar → gider |
| Geri alınamaz (ödeme, silme, imza) | Ajan yalnızca öneri üretir |
Değerlendirme seti
Kurulumdan önce 20–30 gerçek örnek toplayın ve beklenen çıktıyı yazın. Her sistem talimatı değişikliğinden sonra bu seti çalıştırın. Bu olmadan yapılan her prompt değişikliği, tahmine dayalı bir müdahaledir — bir şeyi düzeltirken başka bir şeyi bozduğunuzu fark etmezsiniz.
AI Agent Projeleri Neden Başarısız Oluyor?
1. Yanlış görev seçimi
En sık hata, ilk ajanı en görünür süreçte kurmak: müşteriye bakan chatbot. Ekip henüz ajanın nasıl davrandığını öğrenmeden, en yüksek görünürlüklü riske girilmiş olur. Doğru başlangıç, iç süreçlerdeki tekrarlı bir iştir.
2. Araç açıklamalarının zayıf yazılması
Ajanın yanlış aracı seçmesinin sebebi neredeyse her zaman modelin “anlamaması” değil, aracın kötü tarif edilmiş olmasıdır. Tek satırlık açıklamalar, parametresi tarif edilmemiş alanlar, “ne zaman kullanılmayacağı” yazılmamış araçlar. Araç açıklaması bir kılavuz sayfası gibi yazılmalı.
3. Çok fazla araç
Otuz araçlı bir ajan, beş araçlı bir ajandan daha yetenekli değildir — daha kararsızdır. Araç sayısı arttıkça seçim kalitesi düşer. Sınırlarını net çizilmiş az sayıda araç, birbirine benzeyen çok sayıda araçtan iyidir.
4. Bozuk süreci otomatikleştirmek
Ajan bir süreci hızlandırır, düzeltmez. Teklif süreciniz yanlış fiyat listesinden besleniyorsa, ajan yanlış teklifleri daha hızlı üretir. Önce süreç düzelir, sonra ajan kurulur.
5. Denetim olmadan üretime çıkmak
Log yok, bütçe sınırı yok, onay noktası yok. İlk ciddi hata müşteriye gider, güven kaybolur ve proje “yapay zeka bizde işe yaramadı” sonucuyla kapanır. Oysa sorun modelde değil, kurulum tasarımındadır.
6. Tek seferde her şeyi otomatikleştirme hevesi
Kapsamı geniş tutulan projelerin ortak sonu, altı ay sonra kimsenin kullanmadığı bir sistemdir. Tek bir görevle başlayın, ölçün, ikinciye geçin.
30 Günlük Kurulum Planı
| Hafta | Yapılacak | Çıktı |
|---|---|---|
| 1 | Görev seçimi, araç envanteri, otonomi seviyesi kararı, 20 örnekli değerlendirme seti | Yazılı ajan tanımı |
| 2 | No-code prototip, araç bağlantıları, sistem talimatının ilk sürümü | Çalışan ama onaylı (L2) ajan |
| 3 | Değerlendirme setiyle test, sistem talimatı ince ayarı, log ve bütçe sınırlarının kurulması | Ölçülebilir ajan |
| 4 | Sınırlı kullanıcıyla pilot, paralel çalıştırma (ajan + mevcut süreç), metrik toplama | Karar verilebilir veri |
Dördüncü haftanın sonunda üç sorunun cevabı elinizde olur: tamamlama oranı kaç, düzeltme oranı kaç, görev başı maliyet ne. Bu üç sayı olmadan “işe yarıyor mu?” sorusu bir kanaat tartışmasına dönüşür.
Sık Sorulan Sorular
Vaka Kurgusu: 40 Kişilik Bir Muhasebe Ofisinde Ajan Kurulumu
Aşağıdaki senaryo, sahada sık karşılaşılan bir kurulum örüntüsünü göstermek için kurgulanmıştır; belirli bir müşteriye ait gerçek veri içermez.
Başlangıç durumu: 40 kişilik bir muhasebe ofisi, ayda ortalama 900 fatura ve masrafı elle sınıflandırıp muhasebe yazılımına giriyor. İki kişi, günün büyük kısmını bu işe ayırıyor. Hata oranı düşük ama iş yükü tekrarlı ve sıkıcı; personel devri yüksek çünkü kimse bu işte uzun süre kalmak istemiyor.
Görev tanımı: Gelen fatura PDF’i veya fotoğrafını oku → tutarı, tarihi, vergi numarasını ve KDV oranını çıkar → gider kategorisini tahmin et → muhasebe yazılımına taslak kayıt olarak gir → kategori güven skoru düşükse insana işaretle.
Neden ajana uygun: Süreç bir akış şeması olarak çizilemiyor çünkü fatura formatı, dil ve kalite her seferinde değişiyor. Kural tabanlı bir OCR şablonu, format değiştiğinde kırılıyordu — ekip bunu daha önce denemiş ve üç ayda terk etmişti.
Kurulum kararları:
- Otonomi seviyesi: L2 (ajan hazırlar, muhasebeci onaylar) ilk üç ay boyunca sabit tutuldu. Kategori güven skoru yüzde 90 üzerindeyse bile otomatik geçiş yapılmadı — ekip önce ajana güvenmeyi öğrenmek istedi.
- Araçlar:
belge_oku(OCR + alan çıkarma),kategori_tahmin_et,taslak_kayit_olustur. Silme veya onaylanmış kaydı değiştirme aracı hiç tanımlanmadı. - Hafıza: Kalıcı hafıza yalnızca “bu tedarikçi her zaman şu kategoriye girer” türünden öğrenilmiş eşleştirmeler için kullanıldı; kişisel veya finansal detay hiç yazılmadı.
- Değerlendirme seti: İşe başlamadan önce geçmiş üç aydan 30 gerçek fatura örneği ve doğru kategorileri bir tabloya çıkarıldı. Her sistem talimatı değişikliğinden sonra bu 30 örnek yeniden çalıştırıldı.
İlk iki hafta: Tamamlama oranı yüzde 61’de kaldı — düşük çünkü el yazısı notlu faturalar ve düşük çözünürlüklü telefon fotoğrafları sık hatalıydı. Düzeltme oranı yüzde 35’ti. Ekip, sistem talimatına “görüntü kalitesi düşükse veya alan okunamıyorsa tahmin etme, ‘okunamadı’ olarak işaretle” cümlesini ekledi — bu tek değişiklik düzeltme oranını yüzde 22’ye indirdi çünkü ajan artık belirsiz durumlarda yanlış tahmin üretmek yerine insana devrediyordu.
Dördüncü hafta sonu ölçümü:
| Metrik | Başlangıç (elle) | 4. hafta (ajanla) |
|---|---|---|
| Fatura başına süre | ~4 dakika | ~40 saniye (onay dahil) |
| Günlük işlenen fatura | ~35/kişi | ~85/kişi (onaycı olarak) |
| Düzeltme oranı | — | %18 |
| Token maliyeti/fatura | — | ~0.4 TL karşılığı |
Sonuç: İki kişilik ekip aynı işi üçte bir sürede yapar hale geldi; tasarruf edilen zaman, yeni müşteri onboarding sürecine kaydırıldı. Otonomi seviyesi altıncı ayda L3’e (ajan yapar, insan sonradan denetler) yükseltildi — ama yalnızca güven skoru yüzde 95 üzerindeki kategoriler için. Ödeme veya banka entegrasyonu hiçbir aşamada ajana verilmedi; bu, ekibin baştan koyduğu ve hiç esnetmediği tek kesin sınırdı.
Çıkarılacak ders: Projeyi başarılı yapan şey ajanın kendisi değil, düşük görünürlüklü ve geri alınabilir bir süreçle başlamak, hatayı erken yakalayacak bir değerlendirme seti kurmak ve otonomiyi kademeli artırmaktı. Aynı ekip, ilk ajanını doğrudan müşteriyle konuşan bir chatbot olarak kurmuş olsaydı, hata toleransı çok daha düşük olurdu.
(Vaka temsilidir.)
Kurulum Sonrası: İlk 90 Günde Neye Dikkat Edilmeli
Ajan canlıya alındıktan sonra proje bitmiş sayılmaz — asıl öğrenme bu noktadan sonra başlar. İlk 90 gün için pratik bir kontrol listesi:
- İlk hafta: Her kararı manuel olarak gözden geçirin, otomatik onaya güvenmeyin. Log kayıtlarını günlük okuyun.
- İkinci–dördüncü hafta: Düzeltme oranını haftalık izleyin. Belirgin bir düşüş yoksa sistem talimatı değil, muhtemelen görev tanımı veya araç seti hatalı.
- İkinci ay: Değerlendirme setini gerçek üretim hatalarıyla büyütün. Ajanın yanlış yaptığı her örnek, sete eklenmesi gereken yeni bir test vakasıdır.
- Üçüncü ay: Otonomi seviyesini kademeli yükseltmeyi değerlendirin — ama yalnızca metrikler bunu destekliyorsa. “Şimdiye kadar sorun çıkmadı” bir metrik değildir; düzeltme oranı ve devir oranı metriktir.
- Sürekli: Bağlı olduğu API’ler ve iş kuralları değiştiğinde ajanı güncelleyin. Bir ajan, kurulduğu andaki kurallara göre donmuş kalır — çevresi değiştiğinde o da güncellenmelidir.
Bu dönemde en sık gözden kaçan şey, ekibin ajana olan güveninin metrikten önce oluşmasıdır. Bir hafta sorunsuz geçtiğinde ekip gözlemi gevşetme eğilimine girer; oysa asıl risk, nadir görülen ama maliyetli uç durumlardadır ve bunlar haftalar sonra ortaya çıkabilir.
Sahiplik kimde olmalı?
Ajanın “sahibi” olmadan kurulum çürür. Sahiplik genellikle üç rol arasında paylaştırılmalı:
- Süreç sahibi: İşin doğru yapılıp yapılmadığına karar veren kişi — genellikle o departmandan biri, teknik ekipten değil. Değerlendirme setini bu kişi onaylar.
- Teknik sorumlu: Araç bağlantılarını, sistem talimatını ve bütçe sınırlarını güncelleyen kişi. Genellikle geliştirici veya otomasyon uzmanı.
- Onaycı(lar): Günlük işte ajanın önerdiği eylemleri onaylayan kullanıcılar. Bu kişiler eğitilmeden ajan devreye alınmamalı — “onayla” düğmesine körlemesine basmak, otomasyonun amacını boşa çıkarır.
Küçük ekiplerde bu üç rol aynı kişide birleşebilir, ama büyük ekiplerde net olarak yazılı hale getirilmesi gerekir. Aksi halde ilk hata çıktığında “bu kimin sorumluluğuydu?” sorusu cevapsız kalır ve proje güvenini kaybeder.
Sonuç
AI agent kurulumunda zorluk model değil, sıralama ve sınır tasarımı.
Doğru sıra şu: önce görevi net tanımla, sonra araçları ve yetki sınırlarını çiz, sonra onay noktalarını yerleştir, sonra kur, sonra ölç. Bu sıra bozulduğunda ortaya çıkan şey otonom bir asistan değil, denetlenemeyen bir belirsizlik olur.
Teknik kurulum bir–iki haftalık iştir. Projeyi ayakta tutan şey ise log, bütçe sınırı, onay tasarımı ve değerlendirme seti gibi “sonra ekleriz” denilen parçalardır. Bu parçalar olmadan ilk ciddi hata, projenin de sonu olur.
Küçük başlayın, ölçün, otonomi seviyesini kademeli yükseltin. Tek seferde bütün şirketi ajanlara devretmeye çalışan projelerin ortak sonu, altı ay sonra kimsenin kullanmadığı bir sistemdir.
İşletmenizde hangi sürecin ajana uygun olduğunu konuşmak isterseniz AI agent geliştirme sayfasına bakabilir veya iletişime geçebilirsiniz.