Maven Apps: Ajanlarınızın ihtiyacı şalter panelleri değil, operatörler

Bir anahtar paneli, nasıl kablolandıysa tam olarak onu yapar: Anahtarı çevirirsiniz, her seferinde aynı sabit yanıtı alırsınız. O devrenin dışında kalan bir şeyi ondan istediğinizde yapamaz; çünkü değişkenliği değil, yalnızca kabloları yönetir.

Bir santral operatörü ise farklıdır. Operatöre bir talep iletin, örneğin "beni resepsiyona bağlayın", nasıl yapacağını kendisi bulur: hangi hattı kullanacağını, hat meşgulse ne yapacağını, talebin kendisi belirsizse ne yapacağını. Sinyali yalnızca bir uçtan diğerine taşımaz; onu yorumlar ve buna göre harekete geçer.

Maven Apps anahtar paneli değil, operatördür. App altyapımıza güç veren framework'ü oluşturmaya oturduğumuzda bilinçli bir tercih yaptık: Bir entegrasyon katmanı daha inşa etmek yerine gerçek bir uygulama platformu kurmak ve yapay zekâ ajanlarını bu platformun birinci sınıf vatandaşları yapmak.

Bugün framework'ümüz üzerinde binlerce uygulama çalışıyor. Evet, bunlar arasında Salesforce, Zendesk ve Notion gibi büyük üçüncü taraf sistemler için uygulamalar var. Ama canlı ajanlarda production ortamında çalışan yüzlerce özel uygulama da var.

Temel entegrasyonlar neden yetersiz kalıyor

10 farklı tedarikçiye ürünleri için "Salesforce ile entegre" olmanın ne anlama geldiğini sorun, 10 farklı yanıt alırsınız; çünkü Salesforce, Zendesk ya da Front gibi bir sistem hiçbir zaman tek bir şey değildir. Şunlar olabilir:

• Ajanınızın bilgi bulmak için başvurması gereken bir yer (bir bilgi bankası, bir vaka geçmişi)
• Ajanınızın işlem yapmak için gitmesi gereken bir yer (destek talebi oluşturmak, kayıt güncellemek, iade yapmak)
• Ajanınızın görünmesi gereken bir yüzey (destek ekibinizin zaten tüm gününü geçirdiği konsolun içinde bir agent-assist co-pilot'u)

Yalnızca makalelerden haberdar olan bir "Salesforce entegrasyonu", vaka da açabilen bir entegrasyonla aynı ürün değildir; temsilci konsolunun içinde co-pilot olarak yer alabilen bir entegrasyonla da aynı ürün değildir. Bunlar çoğu zaman tek bir pazarlama kelimesi altında paketlenir ve eksikleri implementasyon sırasında keşfetmek size kalır.

Bu, otomat sorunudur: Sabit bir menü, ihtiyacınız olan şey listede olmayana kadar tam da vaat edildiği gibi çalışır; o noktaya geldiğinizde ise taahhüdü çoktan vermiş olursunuz. Maven Apps'in böyle çalışmasını istemedik; bu yüzden framework'ü genel bir "connector" etrafında değil, sorulan asıl soru (bilgi, yetenek ya da kanal) etrafında kurduk.

Maven Apps: entegrasyondan fazlası

Maven Apps pek çok biçim alabilir, ancak çoğu birkaç ortak kalıp üzerine kurulur. Uygulamaların neler yapabileceğine dair birkaç örnek:

• Bilgi uygulamaları, ajanın yanıtlarını dayandırabilmesi için harici bir sistemdeki içeriği okur ve indeksler: salt okunur, sürümlenmiş ve hedef kitleye göre etiketlenebilir.
• Yetenek uygulamaları, ajanın o sistemde gerçekten bir şey yapmasını sağlar: tek bir konuşma içinde, çok adımlı bir iş akışına bağlanan gerçek bir API çağrısı (siparişi bul, iade politikasını kontrol et, iadeyi yap, müşteriye onayla). ATM sabit bir menüden senaryosu belli tek bir işlem yürütürken, bir yetenek uygulaması daha çok kişisel bankacı gibi davranır: Menü öğesini değil sonucu alır ve istisnaları ele almak da dahil, oraya ulaşmak için ne gerekiyorsa yapar.
• Kanal uygulamaları, ajanı müşterilerinizin ya da destek ekibinizin zaten bulunduğu yere taşır: gömülü bir widget, bir telefon görüşmesi, bir gelen kutusu ya da temsilcilerinizin her gün kullandığı konsolun içinde bir co-pilot paneli.

Dizinimizdeki hazır bir uygulama genellikle dakikalar içinde kurulabilir. Bir müşterinin sistemi katalogda yoksa, geliştiricinin özel bir uygulama oluşturmak için kullandığı da aynı framework, aynı SDK, aynı lifecycle hook'ları ve aynı güvenlik modelidir.

Framework'ün yalnızca bizim mühendislerimizin kullandığı ayrı bir "kurumsal sınıf" katmanı yoktur; uygulama geliştirmeye yönelik geliştirici platformumuz App Studio, birebir aynı mimari üzerinde çalışır. Gerçek TypeScript, gerçek bir SDK (@mavenagi/mavenagi) ve gerçek bir deploy pipeline'ı söz konusu; yalnızca bizim için öğrenmeniz gereken tescilli bir betik dili değil.

Daha önce MCP ile geliştirme yaptıysanız, Maven App size benzer bir fikri tamamen yönetilen biçimde sunar. Standart bir MCP sunucusu hâlâ onu kendiniz ayağa kaldırmanız, kaydetmeniz, çalışır durumda tutmanız ve ölçeklendirmeniz anlamına gelir. Maven App ise bu altyapının hiçbir parçasını size bırakmayan, otomatik kaydolan ve otomatik ölçeklenen bir MCP endpoint'ine daha yakındır: Siz mantığı yazarsınız; endpoint, kimlik doğrulama ve barındırma sizin için halledilir.

Apps güçlü olacak şekilde nasıl tasarlandı

Maven App, güvenli ve izole bir ortamda çalışan ve Maven platformuyla tanımlı bir SDK üzerinden iletişim kuran serverless bir uygulamadır. Somut olarak:

Multi-tenant'tır. Tek bir uygulama bir kez geliştirilir ve farklı kuruluşlar ile ajanlar genelinde birçok kez kurulur. Her kurulum kendi kapsamlı bağlamına (kendi kuruluş ID'si, ajan ID'si ve çalışma zamanı yapılandırması) sahiptir, ancak aynı temel kodu paylaşır. Yani Salesforce uygulamasında bir iyileştirme yayınladığımızda, onu kullanan her müşteri bundan yararlanır ve kimse "kendi" entegrasyonunun eskimiş, elle yazılmış bir sürümünde takılı kalmaz.

Sonradan eklenmiş değil, izoledir. Her uygulama, Maven'ın çekirdek backend'inden ve diğer müşterilerin uygulamalarından ayrı, güvenli bir ortamda kendi fonksiyonu olarak çalışır. Özel mantığınız hiçbir zaman başka birinin kodunun yanında, paylaşılan bir monolitin içinde çalışmaz. Kayıt sistemlerinize giden bağlantılar VPN, VPC peering, OIDC ya da IP allowlisting ile düz HTTPS üzerinden kurulabilir; seçim bizim değil, sizin.

Polling takvimlerine değil, gerçek olaylara tepki verir. Gece çalışan bir senkronizasyon işi yerine bir uygulama, trigger adı verilen event hook'ları uygulayabilir: Bir konuşma oluşturuldu, geri bildirim geldi, bir bilgi bankası yenilendi ve platform, olay gerçekleştiği anda uygulamayı bilgilendirir. Bu, tanıyor olabileceğiniz otomasyon araçlarından farklı bir yapıdır. Maven trigger'ı pasiftir: Durum değişikliklerini dinleyen platformun kendisidir ve bunları ilgilenen her uygulamaya iletir; olaya neden olan uygulama ile ona tepki veren uygulama arasında hiçbir bağımlılık yoktur. Pratikte bu, bir e-posta yanıt uygulaması ile tamamen ayrı bir Salesforce senkronizasyon uygulamasının aynı "conversation updated" olayına birbirinden bağımsız olarak tepki verebileceği, her birinin kendi işini yaparken diğerinin varlığından haberdar bile olmayacağı anlamına gelir.

Bu, bir karınca kolonisinin kullandığı koordinasyon mekanizmasının aynısıdır. Hiçbir karınca kolonisinin davranışını tek başına planlamaz ve hiçbiri diğerine doğrudan mesaj göndermez; bir karınca ortak ortamda bir şeyi değiştirir (bir feromon izi) ve diğer tüm karıncalar, her biri kendi basit kuralını izleyerek bu değişikliğe bağımsız şekilde tepki verir. Koloni düzeyindeki zekâ (optimize edilmiş yiyecek arama rotaları, yük dengeleme, hatta yuvayı taşımak gibi kolektif kararlar) buradan doğar; merkezi bir koordinatör yoktur ve hiçbir karınca planın farkında değildir. Maven Apps da aynı şekilde koordine olur: Bir olay ortak durumu değiştirir ve ilgilenen her uygulama kendi başına tepki verir.

Gerçek bir yaşam döngüsü vardır. Her uygulama küçük bir lifecycle hook seti uygular:

• preInstall: Herhangi bir şey canlıya geçmeden önce kimlik bilgilerini ve yapılandırmayı doğrular. API anahtarınız yanlışsa kurulum, 3 hafta sonra sessizce değil, tam burada açıkça başarısız olur.
• postInstall: Kurulum başarılı olduğunda uygulamanın aksiyonlarını kaydeder ve ihtiyaç duyduğu kaynakları sağlar.
• executeAction: Ajanın istediği asıl işi yürütür ve bunu müşterilere bir yetenek olarak sunar: sipariş sorgulamak, vaka oluşturmak, iade yapmak, hesap bakiyesini kontrol etmek.

Çoğu entegrasyon bir ışık anahtarıdır: açık ya da kapalı, arası yok. Bizimkiler ise kurulum, doğrulama, çalıştırma ve kaldırma adımlarından oluşan eksiksiz bir yaşam döngüsü yürütür; 2 konumlu bir anahtardan çok, bağlamı okuyup uyum sağlayan bir rutine yakındır (neyin açık olduğunu kontrol et, neyin güvenli olduğunu teyit et, sonra harekete geç). Bu da bir production yazılımından tam olarak beklenecek disiplindir, çünkü tam olarak odur.

Apps ve Entegrasyonlar

Tipik bir entegrasyon tek ve dar bir soruyu yanıtlar (genellikle "veri A'dan B'ye ulaşabiliyor mu?") ve bunu bitiş çizgisi sayar. Maven App ise daha zor ve daha faydalı bir soruyu yanıtlamak için tasarlanmıştır: Bir yapay zekâ ajanı, sistemlerinizde şu anda neyin doğru olduğunu güvenilir biçimde bilebilir mi ve gerektiğinde sizin adınıza harekete geçeceğine güvenilebilir mi?

Kurumsal platformların çoğu, "kutudan çıktığı haliyle sunmuyorsak kendiniz geliştirin" yaklaşımının bir versiyonunu sunar. Genellikle söylemedikleri şey, kendiniz geliştirmenin kendi sunucunuzu, kendi ölçeklendirmenizi ve kendi güvenlik incelemenizi kendi altyapınızda yürütmek anlamına geldiğidir. Bu da connector kataloğundaki basit bir eksikliği bir kadro kararına dönüştürür: Mühendislik ve altyapı bütçesi mi alacaksınız, yoksa hazır olanlarla mı sınırlı kalacaksınız? Maven Apps ile müşterilerimiz en az kötü seçeneği seçmeye zorlanmaz. Sizin ya da geliştiricinizin oluşturduğu özel bir uygulama, dizinimizdeki her hazır uygulamayla aynı izleme, ölçeklendirme ve güvenlik duruşuyla bizim altyapımızda çalışır. Kodu siz yazarsınız; çalıştırmayı biz üstleniriz.

Mimarinin, basit bir webhook'un asla dert etmesi gerekmeyen konularda ısrarcı olmasının nedeni de budur:

• Yapılandırılmış, boyutu sınırlı yanıtlar. Bir uygulamanın yürüttüğü her aksiyon, ajanın tahmin yürütmek zorunda kalacağı ham ve sınırsız bir veri yığını değil; net bir yanıt ile ajanın üzerinde akıl yürütebileceği yapılandırılmış veriler döndürür.
• İmzalı, karşılıklı kimlik doğrulama. Platform, bir uygulamaya gönderdiği her isteği imzalar; böylece uygulama, çağrıyı gerçekten Maven'ın yaptığını doğrulayabilir. Uygulama da kendi kimlik bilgileriyle platforma karşı kimliğini doğrular. Hiçbir taraf yalnızca ağa güvenmek zorunda kalmaz.
• Production'a ulaşmadan önce doğrulanan yapılandırma. preInstall bir uygulama canlıya geçmeden önce çalıştığı için, hatalı bir kimlik bilgisi ya da eksik bir ayar, bir müşteri ona ilk kez güvendiğinde değil, kurulum aşamasında yakalanır.
• Altta yalnızca bir fonksiyon çağrısı değil, gerçek altyapı. Uygulamalar tam teşekküllü uygulamalar olduğu için durumsuz bir istek-yanıt döngüsünün ötesinde gerçek durum tutabilir: bir önbellek, bir hız sayacı, küçük bir veritabanı. Belirli bir alandaki çözüm oranının son 24 saatte %10'dan fazla düşüp düşmediğini takip etmek ve düştüğünde ekibinizi uyarmak gibi şeyleri mümkün kılan da budur. Yalın bir API çağrısı bu tür bir hafızayı tutamaz. Gerçek bir uygulama ise tutabilir; tıpkı hiçbir karınca tek başına bilmese de bir karınca kolonisinin yiyeceğin nerede olduğunu hatırlaması gibi.
• Hassas verileri modelden uzak tutmak. Bazı adımlar hiç yapay zekâdan geçmemelidir. Bir müşteri sepetindekileri satın almaya hazır olduğunda ajan, uygulamanın ödeme adımını tetikler ve uygulama, ödeme ve kişisel bilgileri kendi güvenli arayüzü üzerinden doğrudan müşteriden toplar. Akışı ajan yönetir, ancak kart numaraları ve diğer hassas bilgiler yapay zekâyla yapılan konuşmaya hiçbir zaman girmez.
• Tek kod tabanı, tüm müşteriler, izole etki alanı. Multi-tenancy sayesinde düzeltmeler ve iyileştirmeler bir kez yayınlanıp herkese ulaşır; izolasyon ise bir müşterinin özel mantığının bir başkasınınkini asla etkilememesini sağlar.

Sizin için anlamı

Maven'ı değerlendiriyorsanız, pratikteki çıkarım şu: Bir ajanın bir soruyu yanıtlayıp buna göre harekete geçebildiğini söylediğimizde, o aksiyonun arkasında gerçek bir uygulama olduğunu kastediyoruz; sürümlenmiş, kimliği doğrulanmış, izole ve ister bizim ekibimizden ister sizinkinden çıkmış olsun aynı framework üzerine kurulmuş. Sistemleriniz hakkında konuşabilen bir ajan ile sistemlerinize gerçekten bağlı bir ajan arasındaki fark budur.

Maven Apps'i geliştirdik, çünkü "entegrasyon"un baştan beri bu anlama gelmesi gerektiğini düşünüyoruz.