Özetle: Yapay zeka ajanları, kurumsal yazılımlardan kullanıcı arayüzünü sessizce kaldırıyor. API'ler ve MCP aracılığıyla açığa çıkan veri katmanı, yeni ürün yüzeyi haline geliyor. API ekiplerinin bu çeyrekte yapması gereken beş değişiklik, ayrıca henüz kimsenin çözemediği o tek sorun.
Kullanıcı arayüzü, eskiden B2B yazılımlarındaki en derin hendekti. Satış temsilcileri Salesforce'ta, destek ekipleri Zendesk'te, tedarik ekipleri SAP'de yaşıyordu. Erişim sıklığı, kas hafızası, bir arayüzün her girişi bir form aracılığıyla zorlayarak veri hijyeni sağlama biçimi: işte bu bir hendekti. Veri ise bu süreçte depolanan şeydi.
Bu dönem kapanıyor. Yapay zeka ajanları artık bir tarayıcı açmaya gerek kalmadan, API'ler aracılığıyla kurumsal verileri doğrudan okuyup yazabiliyor. Salesforce, veri katmanını ajanlara açan başsız bir ürününü şimdiden duyurdu. Diğer kayıt sistemleri de yıllar değil, haftalar geriden geliyor. Kullanıcı arayüzü artık bir hendek değilse, API bir hendektir. Bu da API'nin ne olması gerektiğini değiştirir.
Uygulamada “başsız yazılım” ne anlama geliyor
Başsız yazılım, ajanların doğrudan okuyup yazabilmesi için veri katmanını API'ler aracılığıyla açığa çıkaran kurumsal yazılımdır. Kullanıcı arayüzü ortadan kalkmaz. Yalnızca tek kapı olmaktan çıkar.
Bu, “API-öncelikli” (bir tasarım metodolojisi) ve “başsız CMS” (bir içerik mimarisi) kavramlarından farklıdır. Her ikisi de yazılımın nasıl inşa edildiğini tanımlar. Başsız yazılım ise bir *tüketici* değişimini anlatır. Verilerinizi okuyup yazan artık tarayıcısı olan bir insan değil. MCP erişimi ve bir hedefi olan bir ajandır.
Üç şey aynı anda bunu mümkün kıldı: denetimsiz olarak araçları planlayabilen ve seçebilen Büyük Dil Modelleri (LLM'ler), ajanların harici sistemleri keşfetme şeklini standartlaştıran MCP ve veri çıkarmanın o kadar ucuz olması ki API'yi duvara çevirmenin altındaki veriyi artık koruyamaması.
Eğer API'niz, bir geliştiricinin bir kez bir istemci yazıp sonra bir kişinin o istemciyi her gün kullanacağı varsayımıyla tasarlandıysa, yapacak işiniz var demektir.
Artık geçerli olmayan beş bağlılık faktörü
Tarihsel olarak beş şey kurumsal sistemleri bağlı tutmuştur. Her birine bir ajanın merceğinden bakın, çoğu bozulur.
Erişim sıklığı kullanıcıları kas hafızası yoluyla kilitli tutuyordu. Satış temsilcileri yıllarca günde sekiz kez Salesforce'a giriş yapıyordu. Ajanların kasları yoktur ve araçlarını değiştirmenin maliyeti bir yapılandırma dosyasını düzenlemenin maliyetidir.
Okuma-yazma iş akışları geçişi tehlikeli hale getiriyordu çünkü veriler sürekli hareket halindeydi. Ajanlar makine hızında okur ve yazar; sözleşme stabil olduğu sürece API'nin arkasındaki veritabanının ne olduğu umurlarında değildir.
Belgelenmemiş Standart Operasyon Prosedürleri (SOP'lar) kimsenin yazmadığı kurallardır: "100.000 dolardan fazla anlaşmaların Başkan Yardımcısı onayı gerekir." Ajanların hala gezinmesi zordur, bu da mevcutlara nefes alma alanı sağlar. Ancak iş akışını yürüten her ajan kuralları öğrenir ve kurallar okunabilir bir yerde kodlanır.
Dahili alışkanlık döngüleri, bir ekibin günlük toplantısının (standup) paylaştıkları araç etrafında şekillenmesi, ekibin günlük işleri ajanlar aracılığıyla aktığında çözülür.
Uyumluluk kritikliği ayakta kalan tek faktördür. Yasal risk, veriyi bir insanın mı yoksa bir ajanın mı taşıdığını önemsemez; denetim izinin hala mevcut olması gerekir. Buna geri döneceğiz.
Beş hendekten dördü zayıflıyor. Beşincisi ise yeni savunulabilirliğin filizleneceği noktadır.
API ekiplerinin bu çeyrekte değiştirmesi gereken beş şey
API yeni ürün yüzeyi ise, işte onda farklı olması gerekenler.
1. API'nizi boru hattı olarak değil, ürün yüzeyi olarak ele alın
"Ön uç çağırabilsin diye" var olan bir REST uç noktası, bir ajanın üzerinde düşündüğü ve çağırmayı seçtiği bir REST uç noktasından farklı bir yapıdır. İlki tutarsız, belgelenmemiş ve bu çeyrekte kullanıcı arayüzünün ihtiyaç duyduğu her şey tarafından şekillendirilmiş olabilir. İkincisi olamaz.
Eğer yapay zeka ajanları için API tasarlıyorsanız, sözleşme arayüz olmak zorundadır. Bu, açıklayıcı isimler, tahmin edilebilir yapılar, bağlama göre üç farklı anlama gelen aşırı yüklü alanların olmaması ve bir modelin üzerinde işlem yapabileceği bir dilde neyin yanlış gittiğini söyleyen hata yanıtları anlamına gelir. "400 Bad Request" yeterli değildir. "400: gerekli customer_id alanı eksik; bu faturanın ait olduğu müşterinin kimliğini iletin" yeterlidir.
Turnusol testi: Yetkin bir ajan, yalnızca OpenAPI spesifikasyonu ve alan açıklamaları ile API'nizi doğru bir şekilde çağırabilir mi? Eğer yanıt, bir uç noktanın ne yaptığını anlamak için eski kullanıcı arayüzünüzün kaynak kodunu da okumayı gerektiriyorsa, API hala bir boru hattıdır.
2. MCP'yi REST ve GraphQL ile birlikte sunun
REST, ajanların API'nizin var olduğunu öğrendikten sonra onu nasıl çağırdığıdır. MCP ise başlangıçta neler yapabileceğini nasıl keşfettikleridir. Bir MCP sunucusu olmayan bir REST API, `robots.txt` ve site haritası olmayan bir web sitesi gibidir; teknik olarak çağrılabilir olsa da, ona ulaşmak isteyen sistemler için pratik olarak görünmezdir.
Bu, mevcut API yüzeyinizi değiştirme meselesi değildir. REST'i koruyun. Eğer varsa GraphQL'i de koruyun. Aynı yetenekleri ajanların zaten konuştuğu bir protokol aracılığıyla açığa çıkaran üçüncü bir lehçe olarak MCP'yi ekleyin. Anthropic MCP spesifikasyonu sözleşmeyi kapsar; Apidog ise bunun etrafında yapılması gereken test ve belgeleme işlerini kapsar.
MCP'nin ne olduğu ve API ekipleri için neden özellikle önemli olduğu hakkında bir giriş isterseniz, derinlemesine incelememize bakın.
3. Şemaları CRUD nesneleri etrafında değil, niyetler ve sonuçlar etrafında yeniden tasarlayın
Salesforce'un veri modelinde Fırsatlar (Opportunities), Potansiyel Müşteriler (Leads), Hesaplar (Accounts), Kişiler (Contacts) bulunur. Bir ajan bu isimlerle düşünmez. Hedeflerle düşünür: "ayrılmak üzere olan her hesabı bul," "dünkü kapanan anlaşma için teklif taslağı oluştur," "gece P0 bileti açan hesabı yükselt."
Yeni nesil kayıt sistemleri, 2000'li yılların başından beri modellediğimiz CRUD nesneleri etrafında değil, görevler, niyetler, iş akışları, politikalar ve sonuçlar etrafında inşa edilecek.
Bu, şemanızı bir gecede yeniden yazmak anlamına gelmez. Üzerine bir katman eklemek demektir. Ajanı üç ayrı yazma işlemi yapmaya zorlamak yerine, "bu potansiyel müşteri satın alıyor" ifadesini alıp doğru Fırsat + Aktivite + Görev kayıtlarını döndüren bir /intents/capture uç noktası. Niyet API haline gelir; CRUD ise bir uygulama detayı olur.
API'nizi yapay zeka ajanlarına hazır hale getirme rehberimiz, desenleri daha derinlemesine ele alıyor.
4. Ajan kimliğini ve kapsamlı izinleri çözün
Bu, henüz kimsenin tam olarak çözemediği ve bu yüzden aşağıda ayrı bir bölüm olarak ele alınan konudur. Kısa versiyonu: her ajan çağrısının kullanıcınınkinden farklı bir kimliğe, kullanıcınınkinden farklı izinlere sahip ve ayrı bir eylem sınıfı olarak denetlenen bir kimliğe ihtiyacı vardır. Eğer API'niz "Alice düğmeye tıkladı" ile "Alice'in ajanı o uyurken sabah 3'te onun adına düğmeye tıkladı" arasındaki farkı ayırt edemiyorsa, bir sorununuz var demektir.
Güncel desenler için MCP güvenlik politikalarına bakın.
5. Eylem katmanını denetim izi ve kapalı döngü geri bildirimle oluşturun
Yeni savunulabilirlik, kaydı depolamakta değildir. Eylemi gerçekleştirmekte, sonucu yakalamakta ve bu geri bildirimi gelecekteki kararları iyileştirmek için kullanmaktadır. CRM verilerinizi tutan bir SaaS ürünü, kullanıcı arayüzü olan bir veritabanıdır. Sizin adınıza eylemler gerçekleştiren, ne olduğunu gözlemleyen ve zamanla bu eylemde daha iyi hale gelen bir SaaS ürünü ise bambaşka bir şeydir.
API ekipleri için bu üç değişiklik anlamına gelir. Eylem uç noktalarının, ajanın ne olduğunu öğrenmesi için sonuç geri aramalarına (callback) veya webhook'lara ihtiyacı vardır. Her eylem yeniden oynatılabilir olmalıdır, aksi takdirde ajanın ne yaptığını hata ayıklayamazsınız. Ve her eylemin girişler, çıkışlar, ajan kimliği ve eğer alabiliyorsanız akıl yürütme izini içeren bir denetim satırına ihtiyacı vardır.
Veri kaybetmeden ajan iş akışlarını test etmek, bu değişimin operasyonel versiyonudur.
Çözülmemiş kısım: ajan yetkilendirmesi
Ajanlara hazır yazılımlardaki tüm boşluklar arasında, bu en az çözülmüş ve en önemli olandır. Hangi ajanlar kimin adına, hangi denetlenebilirlik ile ne yapmaya yetkilidir?
2026'daki dürüst yanıt, neredeyse kimsenin bunu iyi bir şekilde sunamadığıdır. OAuth, yetkilendirilmiş kullanıcı erişimi için inşa edildi, ajanlar için değil. RBAC, insan rolleri için inşa edildi. Denetim günlükleri, kullanıcıların ne yaptığını izlemek için inşa edildi, hangi kullanıcının ajanının hangi politika altında ne yaptığını izlemek için değil.
Standartlar henüz oturmadan bile bugün işe yarayan dört model ortaya çıkıyor.
Ajan kimliği başına kapsamlı token'lar. Bir kullanıcının oturum token'ını, onun adına hareket eden bir ajan için asla yeniden kullanmayın. Kullanıcının tam izinlerinden daha dar olsa bile, ayrı bir kapsamda ayrı bir token düzenleyin ve bunu bağımsız olarak döndürün. Eğer token sızarsa, ajanı iptal edersiniz, kullanıcıyı değil.
Her istekte delegasyon meta verisi. Her API çağrısı, X-Acting-On-Behalf-Of: user_id ve X-Agent-Identity: agent_name@version gibi bir başlık taşımalıdır. İki ekstra başlık, uç nokta mantığınızda sıfır değişiklik ve denetim hikayeniz on kat daha iyi hale gelir.
Ajan eylemleri için sadece eklemeye açık denetim günlükleri. Ajan eylemleri, kullanıcı eylemlerinden ayrı bir denetim tablosunda yer almalıdır. Sorgu desenleri farklıdır; uyumluluk ekipleri insan etkinlikleri arasında gezinmeden "ajanlar bu hafta ne yaptı" sorusuna yanıt arayacaktır.
Kod olarak politika. Sürüm kontrollü bir yapılandırma dosyasında, her ajan sınıfının ne yapmasına izin verildiğini belirtin. "Müşteri destek ajanı faturaları okuyabilir ve 50 dolara kadar iade yapabilir; hesapları silemez." Bunu kontrol edin. Test edin. Farkları inceleyin. İzin politikası bir derleme yapıtı olmalı, bir wiki sayfası değil.
Bunların hiçbiri tamamlanmış bir standart değildir. Hepsi şimdi gönderilebilir.
Apidog nerede devreye giriyor
API'nizi bir ürün olarak ele alacaksanız, tasarım, sözleşme, taklit (mocking), MCP, test ve denetimi tek bir yerde yöneten bir çalışma tezgahına ihtiyacınız var. Apidog'u bunun için inşa ettik ve bu beş değişiklik, zaten desteklediği işlere sorunsuz bir şekilde uyuyor.
- Değişim 1 (Ürün olarak API): şema-öncelikli tasarım ve otomatik oluşturulan dokümantasyon, böylece sözleşme, ajanlarınızın okuduğu tek doğruluk kaynağı olur.
- Değişim 2 (REST ile birlikte MCP): MCP sunucunuzu göndermeden önce doğrulamak için özel MCP sunucu test araçları.
- Değişim 3 (niyet odaklı API'ler): dinamik yanıtlarla taklit (mocking), böylece bir niyet uç noktasını prototipleştirebilir ve arka uç var olmadan önce ajan istemcinizin onu çağırmasını sağlayabilirsiniz.
- Değişim 4 (yetkilendirme): ajan token'larını kullanıcı token'larından ayırmak için ortam yönetimi, ayrıca politika uygulama için iddia testi.
- Değişim 5 (eylem katmanı + denetim): Nisan ayında çıkan Yapay Zeka Ajan Hata Ayıklayıcı ve A2A Hata Ayıklayıcı, ajan odaklı API çağrılarını baştan sona izlemenizi, tekrar oynatmanızı ve üzerinde iddialarda bulunmanızı sağlar.
Henüz denemediyseniz, Apidog'u indirin ve mevcut OpenAPI spesifikasyonunuzu onun üzerinden geçirin. Sadece taklit (mock) sunucu bile genellikle geçiş maliyetini karşılar.
İddia
API ekiplerinin şu anda yapması gereken iddia basittir. API'nin kendisi üründür. Eğer o bir boru hattıysa, o bir meta'dır. Eğer ajanların üzerinde düşündüğü, seçtiği, güvendiği ve eylemde bulunduğu yüzey ise, o bir hendektir.
Bu çeyrekte ürün çıkaran ekipler, beş yıl önce inşa edilenlere hiç benzemeyen API yüzeyleriyle karşılaşacaklar. Bekleyen ekipler ise 2027'de, büyük bir müşteri ajan entegrasyonunun neden "doğru çalışmadığını" sorduktan sonra, son teslim tarihi baskısı altında onları yeniden yazacaklar.