Benim Agentic Yığınım: Claude Code + Skills + MCP, Tek Kişilik Sürüm
Benim agentic yığınım dört katmandan oluşuyor: Claude Code ana ajan olarak terminalde çalışıyor, Skill’ler tekrar eden işleri SKILL.md dosyalarına döküyor, MCP sunucuları ve API bağlantıları Google Ads’ten WordPress’e kadar her araca erişim veriyor, insan onayı ise canlı sistemde her yazma işleminden önce devreye giriyor. Türkiye’de 43 Google Ads hesabını, onlarca GA4/GSC/GTM hesabını ve kendi sitemi bu dört katmanla tek başıma yönetiyorum — bildiğim kadarıyla bu ölçekte, bu şeffaflıkta anlatan başka biri yok.
Katman 1: Claude Code — Terminaldeki Ana Ajan
Yığının merkezinde Claude Code var; terminalde çalışan, dosya sistemine ve komut satırına doğrudan erişimi olan bir ajan. Bana chat penceresinde soru cevap veren bir asistan değil, bash, PowerShell, dosya okuma/yazma ve SSH bağlantısı gibi gerçek araçları kendi başına çağırabilen bir çalışma ortamı. Bir GA4 raporu istediğimde tarayıcıya girip tıklamıyorum; Claude Code terminalde kendi yazdığım bir Python betiğiyle GA4 API’sine sorgu atıp çıktıyı yorumluyor. Bir müşteri sitesinde WordPress ayarı değişecekse SSH üzerinden sunucuya bağlanıp WP-CLI komutlarını sırayla yürütüyor.
Bu katmanın kritik özelliği devamlılık: her proje kendi klasöründe yaşıyor, her klasörün kendi CLAUDE.md dosyası var — o hesaba özel erişim bilgisi, kurallar, öğrenilmiş tuzaklar orada duruyor. Yeni bir oturum açtığımda Claude Code önce o dosyayı okuyor, biriken deneyimi (‘bu hesapta şunu böyle yap, şu hatayı bir daha yapma’) sıfırdan tekrar etmeden devralıyor. Tek kişilik bir ajans için bu, işe alınmış ve hiç unutmayan bir operasyon asistanı gibi çalışıyor; sürekliliği sağlayan insan hafızası değil, dosya sistemi.
Katman 2: Skills — Tekrarlayan İşin SKILL.md’ye Dökülmesi
Skill’ler, sık tekrarlayan işlerin tarifini SKILL.md dosyalarına yazıp Claude Code’a görevi görünce nasıl yapacağını önceden anlatmanın yolu. Bir sayfanın SEO kalitesini denetlemek örneğin her seferinde aynı beş kontrolü gerektiriyor: title uzunluğu, description, görsel, JSON-LD, İngilizce karşılık. Bunu her defasında baştan anlatmak yerine bir kere bir denetim skill’ine yazdım; artık ‘şu sayfayı denetle’ dediğimde aynı standarda göre, aynı sırayla kontrol ediliyor.
Aynı mantık Google Ads hesap yönetimi için de geçerli: ajans mantığıyla, çoklu hesap prensipleriyle nasıl optimize edileceğini tarif eden ayrı bir skill var. GEO/AI-arama denetimleri ve site çeviri kalitesi kontrolü için de kendi skill’leri var. Skill’ler olmadan her görev sıfırdan tarif edilir ve tutarlılık kişisel hafızaya bağlı kalır; skill’lerle 43 hesaplık bir portföyde bile aynı standardı tekrarlamak mümkün oluyor. Bu yaklaşımı somut örneklerle nasıl kullandığımı Danışman Olarak Kullandığım Claude Skills Örnekleri sayfasında ayrıca anlattım.
Katman 3: MCP Sunucuları ve API Bağlantıları
Üçüncü katman Claude Code’u dış dünyaya bağlayan katman: MCP (Model Context Protocol) sunucuları ve doğrudan API bağlantıları. Google tarafında hepsi tek bir kimlik üzerinden çalışıyor; kendi Google hesabım, on bir kapsamlı tek bir OAuth token’ı. Bu tek kimlik GA4 (82 property), Search Console (26 site), Google Ads (43 hesap, bir MCC üzerinden login-customer-id başlığıyla), Tag Manager (63 hesap) ve Sheets/Drive’a aynı anda erişim veriyor. Ayrı ayrı servis hesabı kurmuyorum; yeni bir müşteri geldiğinde tek yapılan, o hesaba kendi hesabımı yönetici olarak eklemek.
Meta Ads için resmî Meta MCP kullanılıyor. WordPress tarafında ise bilinçli olarak MCP değil, SSH ve WP-CLI tercih ettim; aynı işi bir MCP eklentisiyle yapmak işlem başına dört ile otuz iki kat daha fazla token yakıyor, üstelik 12 canlı siteye HTTP üzerinden komut kabul eden bir eklenti kurmak gereksiz bir saldırı yüzeyi demek. Cloudflare, Adobe, Canva ve Figma gibi katmanlarda da aynı mantık geçerli: hangi erişim yolu en dar ve en verimliyse o seçiliyor. Bu bağlantıları kavramsal olarak Agentic AI’de Skills vs Tools vs MCP sayfasında ayırdım; 43 hesaplık Google Ads yönetiminin somut hâli için Claude Skills ile 43 Google Ads Hesabı Yönetimi sayfasına bakılabilir.
Katman 4: İnsan Onay Noktaları — Otomasyonun Freni
Dördüncü katman insan onayı; ve bu yığının en az otomatik ama en önemli parçası. Kural basit: okuma her zaman serbest, canlı sistemde yazma her zaman durur. Bir Google Ads bütçesi veya teklifi değişecekse, bir GTM konteyneri yayına alınacaksa, bir WordPress veritabanına dokunulacaksa, Claude Code önce mevcut değeri okuyup kaydediyor, ne değişeceğini ve geri alma yolunu yazıyor, sonra onay bekliyor. Onay gelmeden hiçbir mutasyon çalışmıyor.
WordPress tarafında bu protokol somut adımlara dökülü: değişiklikten önce git anlık görüntüsü alınır, veritabanı yedeklenir, hedef sunucu doğrulanır (aynı veritabanı adı yedi farklı sunucuda var, bu yüzden isme değil host’a güvenilir), sonra tek tek uygulanıp doğrulanır. Bu adımları atlamak hızlı görünür ama geri dönüşü olmayan tek hata kaynağı burasıdır; bu yüzden hız veya kolaylık gerekçesiyle atlanmaz. Otomasyonun değeri hız değil tekrarlanabilirlik; karar hâlâ bana ait.
Bir Günlük Akış: Sabah Rutini Nasıl İşliyor
Sabah rutini şöyle işliyor: Claude Code’a güne başlamasını söylediğimde önce gece boyunca neyin değiştiğine bakılıyor; birkaç Google Ads hesabında harcama ve dönüşüm bir sorguyla çekiliyor, GA4’te önceki güne göre anomali var mı kontrol ediliyor, Search Console’da yeni bir indeksleme hatası çıkıp çıkmadığına bakılıyor. Bunların hiçbiri panellere tek tek girmeden, birkaç komutla toparlanıp bana özet olarak geliyor: ‘şu hesapta CPA yüzde otuz arttı, şu sayfada tıklama düştü’ gibi.
Buradan sonrası insan işi: hangi anomalinin gerçek bir sorun, hangisinin gürültü olduğuna ben karar veriyorum. Bir teklif değişikliği gerekiyorsa Claude Code önce mevcut teklifi kaydediyor, önerisini gerekçesiyle yazıyor, onay istiyor. Onaylarsam mutasyon çalışıyor, sonuç doğrulanıyor. Günün geri kalanında aynı döngü müşteri işlerinde de tekrarlanıyor; fark eden tek şey hangi hesaba, hangi skill’e bakıldığı. Genel çerçeveyi Agentic AI Rehberi hub sayfasında topladım.
Bu Yığının Sınırları — Nerede İşe Yaramaz
Dürüst olmak gerekirse bu yığın her işte işe yaramıyor. Yaratıcı veya görsel karar gerektiren işler; bir reklam kreatifinin doğru hissettirip hissettirmediği, bir tasarımın marka diline uyup uymadığı; hâlâ tamamen elle, gözle yapılıyor. Ajan burada sadece taslak veya öneri üretebiliyor, son kararı vermiyor. Aynı şekilde müşteri ilişkisi yönetimi, fiyat pazarlığı ve beklenmedik bir kriz anında ne söylenmesi gerektiği kararı bu yığının dışında kalıyor; bunlar insan yargısı gerektiriyor, otomasyonla hızlandırılamıyor.
Teknik tarafta da sınır var: ilk kez görülen, dokümantasyonu zayıf bir API’ye bağlanmak genelde deneme yanılma gerektiriyor; bir skill veya MCP’nin hazır olduğu işler hızlanıyor, hiç görülmemiş bir entegrasyon yine saatler alıyor. Bu yığın hız değil tutarlılık ve ölçek problemi çözüyor; aynı kaliteyi kırk üç hesapta da beş hesapta da tekrarlamak. Tek bir hesap için, tek seferlik bir işse, klasik yöntemle yapmak çoğu zaman daha hızlı.
Bu İşi Benden İsteyebilirsiniz
Kendi ajanik yığınınızı kurmak, mevcut bir Google Ads/GA4/WordPress operasyonunu Claude Code + Skills + MCP mantığıyla otomatikleştirmek ya da hangi işlerin otomasyona, hangilerinin elle kalması gerektiğine karar vermek istiyorsanız bu benim yaptığım işlerden biri. Genelde 2 saat–2 hafta arası süren, uzaktan, saatlik ücretle yürüttüğüm bir danışmanlık kapsamında ele alıyorum. Detaylar ve iletişim için yapay zeka danışmanlığı sayfasına bakabilirsiniz.
Sıkça Sorulan Sorular
Bu yığını kurmak için hangi araçlara ihtiyaç var?
Temelde üç şey yeterli: bir ajan çalışma ortamı (benim tercihim Claude Code), tekrarlayan işleri tarif edecek bir skill veya prompt kütüphanesi, ve hedef sistemlere (Google API’leri, WordPress, reklam platformları) kimlik doğrulamalı bir erişim katmanı. Maliyet çoğunlukla API kullanım ücretleri ve ajan aboneliğinden ibaret; ayrı bir sunucu veya altyapı kurulumu şart değil.
MCP sunucusu ile doğrudan API bağlantısı arasındaki fark nedir?
MCP, bir aracın yeteneklerini ajana standart bir arayüzle sunan bir katman; kurulumu kolaydır ama her araç çağrısı ekstra token ve gecikme maliyeti getirir. Doğrudan API bağlantısı, benim WordPress ve Google API kullanımımda olduğu gibi, daha fazla ilk kurulum emeği ister ama tekrar eden, yüksek hacimli işlerde çok daha verimlidir. İkisini de kullanıyorum; seçim işin hacmine ve hassasiyetine göre değişiyor.
Bu tür bir ajan yığını canlı bir siteyi veya reklam hesabını riske atar mı?
Doğru kurulmamışsa evet, atar; bu yüzden yazma işlemleri için ayrı bir onay katmanı şart. Benim yığınımda okuma her zaman serbest, ama canlı sistemde herhangi bir değişiklikten önce mevcut durum yedekleniyor, ne değişeceği yazılı olarak bildiriliyor ve onay olmadan hiçbir mutasyon çalışmıyor. Risk azaltma otomasyonun kendisinde değil, bu insan onay adımındadır.
Bu yığın kaç hesap veya site ile ölçekleniyor?
Şu an 43 Google Ads hesabı, onlarca GA4/Search Console/Tag Manager hesabı ve 12 WordPress sitesi tek kişilik bu yığınla yönetiliyor. Ölçeklenmenin sınırı araç sayısı değil, skill kütüphanesinin ne kadar iyi yazıldığı; yeni bir hesap eklemek genelde yeni bir skill yazmak değil, var olan skill’i o hesaba çalıştırmak anlamına geliyor.