AI Agent Geliştirme

AI agent geliştirme projesinde kaliteyi seçilen modelden çok, model çalışmaya başlamadan önce yazılan kurallar belirler: ajanın hangi görevi üstlendiği, hangi araçlara hangi yetkiyle dokunduğu, ne zaman durup bir insana sorduğu ve yaptığı her şeyin nasıl kayda geçtiği. Bu rehber, bu kararları işletme sahibinin vereceği sırayla ele alıyor.

Teknik terimleri ilk geçtikleri yerde kısaca açıklıyoruz. Amaç, teklif aldığınız her ekiple aynı dili konuşabilmeniz ve pilot sonunda ajanın gerçekten işe yarayıp yaramadığını kendi verinizle görebilmenizdir.

01Ajan kararını tek sayfalık görev kartıyla sınayın

Bir işin ajana uygun olup olmadığını tek sayfalık bir görev kartı gösterir. Kartta işi başlatan olay, ulaşılacak hedef, işin bittiğini kanıtlayan koşul, dokunulacak sistemler ve bir şey ters giderse bunu kimin fark edeceği yazılır. Bu beş satır doldurulamıyorsa sorun teknolojide değil, sürecin tanımındadır; AI agent geliştirme o tanım netleşmeden başlamamalıdır.

Kart hazır olduğunda kararı dört soruyla verin:

• Yol değişkenliği: Son yirmi talebi alt alta yazın; çoğu aynı sırayla ilerliyorsa kural tabanlı bir iş akışı otomasyonu yeterlidir.
• Doğrulanabilirlik: Ajanın çıktısını ekipten birinin birkaç dakikada kontrol edebilmesi gerekir; kontrolü ancak bir uzman uzun uğraşla yapabiliyorsa pilot ölçülemez.
• Hata bedeli: Yanlış bir adımın sonucu geri alınabiliyor mu; geri alınamayan işlemler yalnız onay kapısının arkasında kalabilir.
• Hacim: Haftada birkaç kez yapılan bir iş için kurulum, test ve bakım emeği çoğu zaman karşılığını vermez.

Bu soruların ikisinden fazlası olumsuz çıkıyorsa ajanı ertelemek dürüst bir karardır. Aynı kart, ileride ajan kurulduğunda görev tanımının ve test setinin ilk taslağı olarak da kullanılır; yani hazırlık hiçbir durumda boşa gitmez.

02Şirket tipine göre ilk ajan görevleri

İlk ajan görevi dar, sık tekrarlanan ve sonucu kolay kontrol edilen bir iş olmalıdır. Aşağıdaki örnekler gerçek müşteri sonuçları değil; farklı şirket tiplerinde bu ölçütlere uyan tipik başlangıç noktalarıdır.

• E-ticaret mağazası: İade talebini okuyup sipariş tarihini, kargo hareketini ve iade koşullarını karşılaştıran, temsilciye hazır bir karar notu bırakan ajan; iadeyi onaylamak temsilcide kalır.
• Üretici ya da distribütör: Teklif isteğiyle gelen teknik şartnameyi okuyup katalogdaki karşılık gelen ürünleri ve eksik bilgileri listeleyen ajan.
• Muhasebe ya da danışmanlık bürosu: Ay sonunda hangi müşteriden hangi belgenin eksik olduğunu bulup hatırlatma taslaklarını hazırlayan ajan.
• Randevulu hizmet işletmesi: İptal edilen saati bekleme listesindeki uygun kişilerle eşleştirip öneri sunan ajan.
• B2B satış ekibi: Toplantı notlarından CRM kaydına girilecek sonraki adımları çıkaran ajan; kayıt kurallarını önce CRM otomasyonu tarafında sabitlemek bu işi kolaylaştırır.

Ekip içi soru yanıtlama ise çoğu zaman ajan değil, kaynak gösteren bir arama asistanı ister. Hiçbir sistemde işlem yapılmayacaksa kurumsal bilgi asistanı daha sade ve daha ucuz bir yoldur. İlk görevin başarısı, ikinci görev için ekibin güvenini de hazırlar; bu yüzden en iddialı işle değil, en kolay ölçülen işle başlamak mantıklıdır. Seçtiğiniz görevin sahibi olan çalışanı projeye baştan dahil edin; test setindeki doğru sonuçları en sağlıklı o kişi yazar.

03Sade dille mimari: döngü, durum ve orkestratör

Teknik açıdan bir ajan bir döngüdür: model durumu okur, bir araç çağırmaya karar verir, aracın sonucunu görür ve hedefe ulaşana ya da bir durma kuralına takılana kadar tekrar eder. Bu döngüyü yöneten parça orkestratör denilen sıradan bir koddur; modelin önerisini alır, izin listesine bakar ve aracın gerçekten çalışıp çalışmayacağına o karar verir.

Mimariyi konuşurken üç kavramı netleştirin:

• Durum: Görevin hangi adımda olduğu, hangi aracın ne döndürdüğü ve kalan tavanlar. Bu bilgi modelin hafızasına bırakılmaz, veritabanında tutulur; görev kesilirse kaldığı yerden sürer.
• Bağlam: Modelin bir anda görebildiği metin sınırlıdır. Uzun yazışmalar ve büyük tablolar olduğu gibi verilmez, gereken parça seçilerek verilir.
• Bellek: Görev içi notlar görev bitince silinir; uzun süre hatırlanması gereken bilgiler, örneğin bir müşterinin teslimat tercihi, ayrı ve denetlenen bir kayıtta durur.

Birden çok ajanın birbirine iş verdiği yapılar cazip görünür ama hata ayıklamayı zorlaştırır. Biz önce tek ajanla başlıyor, ancak bir alt görev gerçekten ayrı yetki ya da ayrı model gerektiriyorsa ikinci ajanı ekliyoruz. Sabit adımlı bölümler döngünün dışında, düz kodla çalışır; böylece model yalnız yorum gereken anda devreye girer. Teklif aldığınız ekipten bu döngünün basit bir çizimini isteyin; hangi kararın modelde, hangisinin kodda olduğu çizimde açıkça görünmelidir.

04Araç tanımı: ajanın elindeki tek iş yapan parçalar

AI agent geliştirme sürecinde en çok emek araç tasarımına gider, çünkü ajanın kalitesini çoğu zaman model değil, eline verilen araçlar belirler. Her araç bir adla, ne işe yaradığını anlatan kısa bir açıklamayla, kabul ettiği parametrelerle ve döndürdüğü sonucun biçimiyle tanımlanır. Model aracı bu açıklamayı okuyarak seçtiği için açıklama, yeni bir çalışana yazılan iş tarifi kadar özenle yazılmalıdır.

• Tek iş: "CRM'i yönet" gibi geniş bir araç yerine "müşteriyi e-posta adresiyle bul" ve "kayda not ekle" gibi ayrı araçlar tanımlanır; yetki de araç başına verilir.
• Tekrar güvenliği: Yazma araçları, aynı istek iki kez gelirse ikinci kaydı açmayacak biçimde bir işlem anahtarıyla kurulur; ağ hatasından sonraki yeniden deneme çift fatura üretmez.
• Anlaşılır hata: Araç başarısız olduğunda "yetki yok" ya da "kayıt bulunamadı" gibi, modelin anlayıp yolunu değiştirebileceği bir mesaj döndürür.
• Dar çıktı: Araç binlerce satır yerine sayfalanmış ve yalnız gereken alanları içeren bir sonuç verir.
• Prova modu: Yazma araçları önce "şunu yapacaktım" diyen bir prova sürümüyle çalışır; onaydan sonra gerçek sürüm devreye girer.

Araç listesi kısa tutulmalıdır. Ajana çok sayıda benzer araç vermek yanlış aracı seçme olasılığını artırır; görev büyüdükçe araç eklemek yerine görevi bölmek genellikle daha sağlıklıdır.

05Veri kaynakları, kimlik bilgileri ve bağlantı yolları

Ajanın bağlanacağı her sistem için önce erişim yolu, sonra kimlik bilgisi, en son veri kalitesi netleşir. Erişim yolu genellikle sistemin API'si, bir olay olduğunda haber veren webhook ya da araçları standart biçimde sunan bir MCP sunucusudur; MCP, modelin farklı sistemlerdeki araçları aynı dille çağırmasını sağlayan açık bir protokoldür.

• Ayrı hizmet hesabı: Ajan bir çalışanın kullanıcı adıyla değil, yalnız gereken kapsamlara sahip kendi hesabıyla bağlanır; kayıtlarda kimin ne yaptığı böylece ayrışır.
• Sırlar promptta durmaz: API anahtarları bir kasada saklanır ve araç çalışırken eklenir; model anahtarı hiç görmez.
• Deneme ortamı: Sistemin test ortamı varsa kullanılır; yoksa ilk haftalarda yazma araçları kapalı tutulur.
• İstek sınırları: Sağlayıcının sınırları önceden okunur; ajan sınıra takıldığında beklemeyi bilir, sistemi kilitlemez.

Faturalar, sözleşmeler ve taranmış formlar gibi yapısız belgeler ajana ham haliyle verilmemelidir. Önce yapay zeka ile belge işleme adımında alanlara ayrılmaları, sonuçların denetimini kolaylaştırır.

API'si olmayan eski bir programda dışa aktarma, ara veritabanı ya da küçük bir özel yazılım katmanı gerekir. Ekrandaki düğmelere tıklayan otomasyonlar, arayüz her değiştiğinde bozulduğu için son çare olarak kalmalıdır.

Veri kalitesi de bağlantı kadar önemlidir. Aynı müşteri iki sistemde farklı adla kayıtlıysa ya da sipariş durumları elle ve tutarsız giriliyorsa ajan bu karışıklığı çözmez, çoğaltır. Keşif sırasında her kaynaktan örnek kayıtlar çekip eşleşmeyen alanları listelemek, sonradan çıkacak pek çok hatayı baştan görünür kılar.

06Model seçimi, barındırma ve sürüm sabitleme

Model seçimi genel karşılaştırma tablolarına göre değil, görevin en zor adımını sizin test setinizde kaç kez doğru yaptığına bakılarak yapılır. Ajan görevlerinde belirleyici olan; aracı doğru parametreyle çağırma tutarlılığı, uzun bağlamda talimata bağlı kalma ve yanıt süresidir.

• Rol ayrımı: Planlama ve karar adımı için daha yetenekli bir model, alan çıkarma ya da sınıflandırma gibi basit adımlar için daha hızlı ve hafif bir model kullanmak maliyeti dengeler.
• Barındırma: Sağlayıcının kendi API'si, bölge seçilebilen bulut platformları ve kendi sunucunuzda çalışan açık ağırlıklı modeller arasında veri konumu, işletim yükü ve kalite birlikte tartılır.
• Sürüm sabitleme: Sağlayıcılar modelleri güncelledikçe davranış değişebilir; üretimde belirli bir sürüm kullanılır, yeni sürüm test setinden geçmeden devreye alınmaz.
• Kesinti planı: Sağlayıcı yanıt vermediğinde ajan ya bekler ya da görevi yarım kalmış haliyle insana devreder; aynı promptun başka bir modelde sorunsuz çalışacağı varsayılmaz.

Kendi sunucusunda model çalıştırmak, veri yurt dışına çıkmadığı için cazip görünür; ancak donanım, güncelleme ve güvenlik sorumluluğu tümüyle size geçer. Bu tercihi kişisel veri yoğunluğu ve ekibinizin bir sunucuyu sürekli işletebilme kapasitesi belirlemelidir. Kararı verirken her seçenek için aynı test setini çalıştırmak, tartışmayı görüşten veriye taşır.

07Onay kuyruğu ve adım kaydının tasarımı

Onay kapısı, onaylayanın birkaç saniyede doğru karar verebileceği kadar açık tasarlanmazsa ya görmezden gelinir ya da her şey düşünülmeden onaylanır. Ekranda ajanın yapmak istediği işlem, dayandığı kayıtlar, değişecek alanların önceki ve sonraki hali ile gerekçesi tek bakışta görünmelidir.

• Üç seçenek: Onayla, düzenleyip onayla ve reddet. Red seçildiğinde kısa bir neden kodu istenir; bu kodlar sonraki iyileştirmenin girdisidir.
• Sorumlu kişi: Her işlem türünün bir onaylayıcısı ve o kişi yokken devreye giren bir yedeği vardır.
• Zaman aşımı: Onay belirlenen sürede gelmezse işlem kendiliğinden yapılmaz; hatırlatma gider ya da görev kapanır.
• Toplu onaya sınır: Birbirinden farklı işlemler tek tuşla onaylanamaz; toplu onay yalnız aynı türden düşük riskli işlemlere açılır.

Adım kaydı ise sonradan "ajan bunu neden yaptı" sorusunu yanıtlamak içindir. Her kayıtta görev kimliği, zaman, çağrılan araç, girdiler, sonuç, kullanılan model sürümü ve onaylayan kişi bulunur.

Kişisel veri içeren kayıtların saklama süresi baştan belirlenir. Kayıtlara erişim rolle sınırlanır ve kayıt sisteminin kendisi de kimin hangi kayda baktığını tutar; böylece denetim izi, denetleyenleri de kapsar.

08Ajan güvenliği: dış içerik, sırlar ve çıkış izinleri

Bir ajanın en riskli hali, özel verilere erişebildiği, dışarıdan gelen güvenilmez içeriği okuduğu ve dışarıya veri gönderebildiği durumdur. Bu üç yetenek aynı görevde birleşirse gizli komut taşıyan tek bir e-posta ajanı veri sızdırmaya yönlendirebilir; tasarımda bu üçlünün en az bir ayağı kırılmalıdır.

• Çıkış izin listesi: Ajan yalnız tanımlı alan adlarına ve tanımlı alıcılara yazabilir; listede olmayan bir adrese giden her mesaj onaya düşer.
• Ayrık bağlam: Dış içerikten çıkarılan bilgi, ajanın talimatlarıyla aynı yere değil, işaretli bir veri alanına konur.
• Gönderim kanalı: Ajan sizin alan adınızdan e-posta gönderecekse SPF, DKIM ve DMARC kayıtları doğru olmalıdır; durumu SPF, DKIM ve DMARC kontrol aracıyla birkaç dakikada görebilirsiniz.
• Yalıtılmış ortam: Kod çalıştıran ya da dosya işleyen ajanlar, ağ erişimi kısıtlı ayrı bir ortamda çalışır.

Güvenlik denemeleri de test setinin parçasıdır. İçine talimat gizlenmiş bir belge, sahte bir yönetici talebi ya da ajanın yetkisi dışındaki bir işlemi isteyen müşteri mesajı bilinçli olarak denenir.

Bu denemeler her prompt ya da araç değişikliğinden sonra yeniden çalıştırılır. Bir deneme başarılı olursa düzeltme modelin talimatına değil, önce yetki ve izin katmanına yapılır; çünkü kalıcı koruma kodda tanımlı sınırlardan gelir.

09KVKK, GDPR ve AB tüzüğü açısından ajan

Ajan işlem yaptığı için veri koruma soruları bir sohbet botundan daha geniştir: hangi veriyi okuduğu, nereye gönderdiği ve kişiler hakkında ne ürettiği ayrı ayrı yazılmalıdır. Aşağıdaki noktalar hukuki görüş yerine geçmez; kurulumdan önce hukukçunuzla birlikte ele alınacak bir kontrol listesidir.

• Yurt dışına aktarım: Model ya da otomasyon platformu yurt dışındaysa KVKK'nın 9. maddesi uygulanır. Yeterlilik kararı yoksa uygun güvencelerden biri gerekir; standart sözleşme seçilirse imzadan itibaren beş iş günü içinde Kurula bildirilir.
• Aydınlatma: Ajanın işlediği veriler ve aktarıldığı alıcılar, 10. madde kapsamındaki aydınlatma metninize yansıtılır.
• Hizmet sağlayıcılar: 12. madde, verileri sizin adınıza işleyenlerle güvenlik tedbirlerinden müştereken sorumlu olduğunuzu söyler; model ve platform sözleşmelerindeki veri kullanım ve saklama koşulları okunur.
• Otomatik karar: 11. madde, yalnız otomatik analizle aleyhe çıkan sonuca itiraz hakkı tanır; kişiyi etkileyen işlerde son söz insanda kalır.
• AB'deki kişiler: Avrupa Birliği'ndeki kişilerle yazışan ajanlarda GDPR ve AB Yapay Zeka Tüzüğü'nün 50. maddesindeki şeffaflık kuralı da değerlendirilir.

Pratik kural şudur: ajanın görmesine gerek olmayan alanları araç düzeyinde maskeleyin. Kimlik numarası gerekmeyen bir görevde ajan o alanı hiç görmez, dolayısıyla yanlışlıkla bir yere de yazamaz. Veri akışı haritası her yeni araç eklendiğinde güncellenir. AI agent geliştirme sözleşmesinde de verinin hangi sağlayıcılarda işlendiği, ne kadar saklandığı ve modelin eğitiminde kullanılıp kullanılmadığı açıkça yazılmalıdır.

10Pilottan tam kullanıma geçiş adımları

Ajanı tek seferde açmak yerine yetkiyi ölçüme bağlı adımlarla genişletmek, hem riski hem de ekibin direncini azaltır. Uyguladığımız sıra şöyledir:

1. Örnek toplama: Geçmiş haftalardan görev örnekleri ve ekibin bu işleri nasıl çözdüğü toplanır; kişisel veriler test için maskelenir.
2. Test seti: Örnekler kolay, zor ve yanıltıcı olarak etiketlenir; her biri için doğru sonuç ekipçe yazılır.
3. Gölge çalışma: Ajan gerçek talepleri işler ama hiçbir sisteme yazmaz; önerileri ekibin kararlarıyla karşılaştırılır.
4. Taslak modu: Ajan yazma işlemlerini hazırlar, her biri onay kuyruğuna düşer.
5. Sınırlı yazma: Riski düşük ve geri alınabilir işlem türleri onaysız açılır, diğerleri kuyrukta kalır.
6. Düzenli gözden geçirme: Red nedenleri, maliyet ve hata kayıtları ayda bir incelenir; yetki genişletme ya da daraltma kararı buna göre verilir.

Her adımın geçiş ölçütü baştan yazılır; örneğin son iki haftada red oranının ekiple belirlenen eşiğin altında kalması. Ölçüt tutmazsa bir önceki adıma dönmek başarısızlık değil, kontrolün çalıştığının işaretidir.

AI agent geliştirme burada bitmez; bağlı sistemler, modeller ve iş kuralları değiştikçe ajan da bakım ister. Kurulum sonrası izleme, test setinin güncellenmesi ve küçük düzeltmeler yapay zeka otomasyonu hizmetimizin kapsamında yürür.

11Ajanın değerini ölçmek için doğru göstergeler

Ajanın değeri, bir görevin baştan sona kaça mal olduğu ve ne kadar insan müdahalesi gerektirdiğiyle ölçülür; tamamlanan görev sayısı tek başına yanıltıcıdır. Ölçüme başlamadan önce aynı işin elle ne kadar sürdüğünü bilmek gerekir; ekibin haftalık kayıtlarından bu süreyi çalışma saati hesaplama aracıyla kabaca çıkarabilirsiniz.

• Müdahale oranı: Görevlerin ne kadarında bir insanın düzeltme yapması, ajanı yeniden yönlendirmesi ya da işi devralması gerektiği.
• Görev başına adım: Aynı tip görevde adım sayısı artıyorsa ajan dolaşıyordur; araç açıklamaları ya da bağlam düzeni gözden geçirilir.
• Onayda bekleme: Ajan hızlı ama onay saatlerce bekliyorsa darboğaz insandadır; onay sahipliği yeniden düzenlenir.
• Toplam maliyet: Model kullanımı, platform ücretleri ve onaya harcanan çalışan zamanı birlikte hesaplanır.
• Kaçan hata: Onaydan geçip sonradan fark edilen hatalar ayrıca sayılır; bu sayı onay ekranının yeterince açık olup olmadığını gösterir.

Bu göstergeler aylık bir tabloda yan yana izlenir. Değer görünmüyorsa ajanı genişletmek yerine görevi daraltmak ya da o bölümü sabit bir akışa çevirmek çoğu zaman daha doğru karardır. Göstergeleri ekibin görev sahibiyle birlikte okumak, sayıların arkasındaki nedeni bulmayı hızlandırır; örneğin artan müdahalenin yeni bir ürün grubundan mı, değişen bir kuraldan mı geldiği tablodan değil, işi yapan kişiden öğrenilir.

12Sınırlar, riskler ve projeyi durdurma ölçütleri

Ajanlar olasılığa dayalı çalışır; aynı girdiye her seferinde aynı yanıtı vermeyebilir ve kendinden emin biçimde yanlış bir araç parametresi uydurabilir. Uzun görev zincirlerinde küçük hatalar birbirinin üstüne biner, bu yüzden adım sayısı arttıkça kontrol noktaları da artmalıdır.

• Sessiz bozulma: Bağlı bir sistemde alan adları değişince ajan hata vermeden yanlış alanı okuyabilir; bunu düzenli çalışan test seti yakalar.
• Maliyet oynaklığı: Zor talepler daha çok adım ve daha çok model çağrısı demektir; aylık bütçe tavanı ve alarm baştan kurulur.
• Gecikme: Çok adımlı görevler saniyeler değil dakikalar sürebilir; müşteri anlık yanıt bekliyorsa ajan arka planda çalışmalıdır.
• Sağlayıcı bağımlılığı: Promptlar ve araç tanımları belgelenmezse model değişikliği projeyi baştan yazdırır.

Projeye başlarken durdurma ölçütlerini de yazın. Pilot sonunda müdahale oranı düşmüyorsa, toplam maliyet elle yapılan işi geçiyorsa ya da ekip onay kuyruğunu yönetemiyorsa ajan kapatılır ve görev sabit akışa ya da insana döner. Bunu baştan konuşmak, yapılan yatırım yüzünden işe yaramayan bir sistemi yaşatma eğilimini önler. Durdurma kararı verilse bile görev kartı, test seti ve süreç haritası işletmede kalır; sabit akışa geçişte doğrudan kullanılır.

13AI agent geliştirmede sık yapılan hatalar

Aşağıdaki hatalar, ajan projelerinin neden güven kaybettiğini açıklayan tekrar eden örüntülerdir; her birinin daha sağlıklı karşılığı yanında yazılı.

• Demoyla karar vermek: Seçilmiş birkaç örnekte etkileyici çalışan ajanı gerçek yükle sınamadan açmak yerine, geçmiş işlerden oluşan ve yanıltıcı örnekler içeren bir test setiyle karar verin.
• Tam yetkiyle başlamak: Ajanı yönetici hesabıyla bağlamak yerine salt okuma ile başlayın, yazma yetkisini işlem türü bazında açın.
• Her şeyi modele yüklemek: Sabit adımlı kısımları da ajana bırakmak yerine kuralı yazılabilen her adımı düz koda alın, ajanı yalnız yorum gereken yerde kullanın.
• Promptu kayıt dışı değiştirmek: Promptu sürüm takibi olmadan düzenlemek yerine her değişikliği kayda alın ve yayına çıkmadan test setinden geçirin.
• Onaycıyı tasarlamamak: Onay kuyruğunu sahipsiz bırakmak yerine her işlem türüne bir sorumlu ve bir yedek atayın.
• Maliyeti sonradan izlemek: Kullanım faturasını ay sonunda görmek yerine görev başına tavanı, günlük bütçeyi ve alarmı ilk günden kurun.

Bu hataların ortak noktası, ajanı bir ürün özelliği gibi açıp kapatmaktır. Ajan; kuralları, sorumluları ve sınırları olan bir iş süreci olarak yönetildiğinde bu sorunların çoğu ortaya çıkmadan önlenir. Bir hatayı fark ettiğinizde ilk soru "model neden yanıldı" değil, "yapı bu yanılgıya neden izin verdi" olmalıdır.

14İş ortağı seçimi ve sonraki adım

AI agent geliştirme için çalışacağınız ekibi, ajanın neler yapabildiğini göstermesinden çok neyi yapmasını nasıl engellediğini anlatabilmesine göre seçin. Görüşmede şu soruların net yanıtını isteyin:

• Hangi işimizi ajan yerine sabit bir akışla çözmeyi önerirsiniz ve neden?
• Araç listesi ve her aracın yetkisi teslimde yazılı olarak bize kalacak mı?
• Model, otomasyon ve bulut hesapları kimin adına açılıyor; ayrılırsak neyi taşıyabiliriz?
• Test seti nasıl oluşuyor ve prompt değişiklikleri yayına çıkmadan önce nasıl sınanıyor?
• Pilotu hangi ölçütle başarılı ya da başarısız sayacağız?
• Ajan durduğunda ya da hata verdiğinde kime, hangi kanaldan ve hangi bilgiyle haber gidiyor?

Yanıtlar somut değilse, örneğin araç listesi yerine yalnız model adı konuşuluyorsa, teklifin kapsamı da belirsiz demektir. Yazılı bir görev kartı ve test planı istemek, farklı tekliflerin aynı ölçüyle karşılaştırılmasını sağlar.

Bizimle başlamak için ajana bırakmak istediğiniz işi, bağlı sistemleri ve bu işin bugün nasıl yapıldığını kısaca anlatmanız yeterli; iletişim sayfasından yazabilirsiniz. Görev kartını birlikte doldurur, hangi bölümün ajan, hangi bölümün sabit akış olacağını ve kapsamı yazılı olarak paylaşırız.

Başlangıç seçeneklerini yapay zeka otomasyonu fiyatları bölümünde görebilirsiniz; model ve platform kullanım ücretleri ayrıca, kendi hesabınızdan sağlayıcıya ödenir. Ajan gerekmediği sonucuna varırsak bunu da açıkça söyler, daha sade yolu öneririz.