Commerce Admin'in içindeki capability'ler Admin'den çıkmaya başlıyor

Ne oldu?

Amazon’un 23 Eylül duyurusunda iki gelişme dikkatimi çekti: Seller Assistant workflows ve Amazon Selling Partner plugin.

Workflow’lar satıcı oturum açmamışken de sürekli çalışabiliyor. Hazır şablonlar account health takibi, sipariş özeti, pricing trendleri ve ürün fırsatlarını kapsıyor. Stok eşiklerini izlemek de anlatılan işler arasında. Örneklerden biri, kategoride rekabet fırsatı arayıp fiyat ve listing güncellemek.

Satıcı guardrail’leri belirliyor; yalnızca öneri veya aksiyon seçebiliyor. Ancak aksiyonlar uygulanmadan önce incelenip onaylanıyor. Her aksiyonun audit trail’i tutuluyor. Sürekli çalışma, onaysız işlem anlamına gelmiyor.

Plugin ise listing katkıları, anlık performans metrikleri, stok seviyeleri ve satış analizlerini dış AI araçlarına bağlıyor. Seller Assistant gibi aksiyon da gerçekleştirebiliyor; erişim sınırları, insan onayı ve audit burada da geçerli.

Amazon Quick entegrasyonu duyurulmuş durumda; Claude bağlantısı beta. Duyuru, plugin’in Amazon’un ABD mağazalarındaki satıcılarına beta olarak açıldığını, uluslararası genişlemenin sonradan geleceğini söylüyor. Bunu Türkiye dahil herkese açılmış bir özellik gibi okumamak gerekiyor.

Neden önemli?

Klasik commerce platform modelini kabaca şöyle düşünebiliriz:

User → Admin UI → Commerce Capability

Fiyat değiştirmek, inventory yönetmek veya listing güncellemek için Admin’e giriyoruz. Promotion oluşturmak ve sipariş operasyonlarını yürütmek için de çoğunlukla platformun kendi interface’ini kullanıyoruz. Bu nedenle Admin, ekranların toplamından fazlası; platform capability’lerine ulaşmanın ana kapısı.

Amazon örneğinde bu ilişki gevşiyor. Açıklanan erişim kapsamında üç yol birlikte var olabiliyor:

• User → Claude → Amazon Capability
• User → Amazon Quick → Amazon Capability
• User → Seller Central → Amazon Capability

Benim için önemli değişiklik, bu yollardan birinde Claude veya Amazon Quick bulunması değil. Commerce capability’nin kendi Admin interface’inden ayrılabilmesi. Kullanıcı başka bir yerde çalışırken de ticari işlemi yürüten platformun Amazon olması.

Benim yorumum

Yakın zamanda Headless commerce’tan sonra headless admin mi geliyor? diye sormuştum. O yazıda platform mimarisi açısından bir ihtimali tartışıyordum. Burada ise aynı ayrışmanın commerce operasyonundaki somut uygulamasına bakıyoruz: Bir satıcının işini yaptığı arayüz değişebiliyor, kullandığı commerce capability yerinde kalıyor.

Headless commerce bize kabaca Commerce Capability ≠ Storefront ayrımını öğretti. Product, pricing, inventory, cart veya checkout için platformun kendi storefront’unu kullanmak gerekmiyor. Şimdi platformun operasyon tarafında da aynı soruyu sorabiliyoruz:

Commerce Capability ≠ Admin UI

Buradan “Admin ortadan kalkacak” sonucu çıkarmıyorum. Seller Central’ın ortadan kalkması gerekmiyor; bence commerce Admin uygulamaları da yakın gelecekte ortadan kalkmayacak. Binlerce ürünü karşılaştırmak, karmaşık promotion’ları incelemek, istisnaları yönetmek, toplu işlem yapmak veya sonucu görsel olarak kontrol etmek için Admin hâlâ çok güçlü bir interface. Doğrudan müdahale etmek istediğimizde de aynı ekranlara ihtiyaç duyabiliriz.

Ama Admin, commerce capability’lerine ulaşmanın tek yolu olmak zorunda olmayabilir. Product Owner olarak bu ayrımı kabul ettiğimde bir özelliğin kapsamını da farklı yazmaya başlarım. “Fiyat düzenleme ekranına AI ekleyelim” demekle, fiyat değiştirme capability’sini farklı interface’lerin kullanabileceği bir ürün olarak tanımlamak aynı iş değil.

İkinci yaklaşımda yalnızca isteğin nasıl gönderileceğini değil, hangi koşullarda kabul edileceğini de tasarlamam gerekir. Bir pricing agent için şu soruların cevabını görmek isterim:

• Hangi ürünlerde, ne kadar fiyat değişikliği yapabilir?
• Minimum margin sınırı nedir; mevcut promotion ile çakışma nasıl değerlendirilir?
• Kimin adına hareket eder ve hangi durumda approval gerekir?
• Aksiyon geri alınabilir mi; ne yaptığı sonradan audit edilebilir mi?

Bunlar Amazon’un duyurduğu özelliklerin listesi değil, benim platform tasarımı sorularım. Inventory üzerinde işlem yapan veya listing değiştiren bir agent için de benzer sorular sorarım. Her capability’nin ticari etkisi farklı olduğu için tek bir “AI erişimi açık” ayarı bana yeterli gelmez.

Bu nedenle agent’ların kullanımına hazır bir commerce platformunu yalnızca API Access üzerinden tarif etmezdim. Daha çok şu bütüne bakardım:

Capability + Context + Permission + Constraint + Approval + Audit

Amazon örneğindeki kontrol mekanizmalarını bu açıdan değerli buluyorum. Bir işin sürekli izlenebilmesi ile o işte değişiklik yapma yetkisi ayrı kararlar. Benim tasarlayacağım üründe onay ekranı, hangi ürünün hangi değerinin değişeceğini anlaşılır biçimde göstermeli. İşlem kaydı da operasyon ekibinin sonradan aynı kararı inceleyebilmesine yardımcı olmalı. Yalnızca “agent başarılı çalıştı” mesajı, ticari sonucun doğru olduğunu değerlendirmek için yeterli olmaz.

Dış interface sayısı arttıkça bu davranışları her arayüzde yeniden kurmak istemem. Örneğin Admin’de izin verilmeyen bir fiyat değişikliği, farklı bir assistant üzerinden geldiğinde de aynı kurala takılmalı. Kullanıcı hangi arayüzü seçerse seçsin platformun verdiği ticari taahhüt değişmemeli. Bence capability’yi ürünleştirmenin zor ve değerli kısmı burada.

Yetki devri aynı soruyu başka bir operasyonda soruyor

Sınırlandırılmış harcama yetkisi yazısındaki delegated authority meselesiyle de kısa bir bağlantı var. Agent’a belirli bir tutara kadar ödeme yetkisi vermek ile bir ürünün fiyatını belirli sınırlar içinde değiştirme yetkisi vermek farklı operasyonlar. Ama platform tasarımı açısından ortak soru şu:

Bu agent kimin adına, hangi context’te ve hangi sınırlar içinde hareket edebilir?

Klasik permission modelinin delegation, constraint, approval ve audit ile genişlemesi gerekebileceğini düşünüyorum. Bu, Amazon’un ilan ettiği bir sektör standardı değil; bu örnekten çıkardığım ürün ve mimari yorumu. Ödeme tarafındaki bütün tartışmayı buraya taşımaya gerek yok. Yetki devrinin artık merchant operasyonlarının da tasarım konusu olması yeterince önemli.

Capability’yi ürün olarak düşünmek

AI çağında commerce platformunun interface’lerini değil, capability’lerini ürünleştirmek daha önemli hale gelebilir.

Kullanıcı aynı capability’ye Admin’den, başka bir AI assistant’tan, bir enterprise agent’tan veya bir workflow içinden ulaşabilir. Platform açısından bu yolların aynı business rules, permission modeli, constraint, approval ve audit mekanizmalarına ulaşması gerekir. Aksi halde her yeni interface, operasyon ekibinin anlamak ve kontrol etmek zorunda olduğu ayrı bir davranış üretir.

Ben böyle bir özelliğin kabul kriterlerini yazarken, yalnızca Admin’deki başarılı akışı kontrol etmek istemem. Aynı talep dışarıdan geldiğinde hangi kurala göre kabul ediliyor? Onay bekleyen işlem ile tamamlanmış işlem ayırt edilebiliyor mu? Operasyon ekibi sonucu hangi arayüzden başlatıldığına bakmadan inceleyebiliyor mu? Capability’nin ürün olarak sınırı bu cevaplarla netleşir.

Amazon haberi bana, headless admin fikrini artık yalnızca yeni ekranlar üzerinden tartışmamamız gerektiğini düşündürüyor. Asıl ürün kararı, ekranın arkasındaki işin nasıl tanımlandığında.

Bir commerce capability’sini yalnızca kendi Admin ekranımızın kullanabileceği şekilde mi tasarlıyoruz, yoksa farklı interface’lerin güvenli biçimde kullanabileceği bir platform capability’si olarak mı?

Kaynak

Amazon — Amazon gives sellers an even smarter Seller Assistant and a new plugin for Amazon Quick and Anthropic’s Claude — Kaynak tarihi: 23 Eylül 2026.