Geçen ay bir müşteri projesi için farklı Google Workspace servislerini tek bir yapay zekâ akışı altında birleştirmem gerekiyordu. Sheets’ten veri çek, Drive’a yaz, Calendar’da etkinlik oluştur — hepsini tek bir komutla. Kulağa basit geliyor, değil mi? Değil. En azından Gemini CLI’a uzak alt ajan desteği gelene kadar öyleydi. Şimdi işler değişti ve ben de bu değişimi sizinle paylaşmak istiyorum.
Araya gireyim: Agent-to-Agent (A2A) protokolü denen bir yapı var — Google’ın ajanlar arası iletişim için geliştirdiği standart. Gemini CLI bunu artık destekliyor ve Google Apps Script (GAS) Web Apps üzerinden inşa ettiğiniz sunucularla doğrudan konuşabiliyor. Yani elinizde ciddi bir otomasyon makinesi var. Üstelik altyapı maliyeti neredeyse sıfır.
A2A Protokolü Nedir, Neden Önemli?
Bak şimdi, agent dediğimiz yapılar — yani otonom çalışan yapay zekâ birimleri — tek başlarına güçlü olsalar da asıl potansiyellerini birlikte çalışırken ortaya koyuyorlar (ben de ilk duyduğumda şaşırmıştım). A2A protokolü tam olarak bu “birlikte çalışma” kısmını standartlaştırıyor. Bir ajan diğerine görev verebiliyor, sonuç alabiliyor, hatta zincirleme iş akışları kurulabiliyor (bizzat test ettim). Düşünün bir kere: bir şirkette herkes kendi işini biliyor ama birbirleriyle iletişim kuramıyorsa ne olur? Kaos — itiraf edeyim, beklentimin üstündeydi —. İşte A2A bu iletişimin kurallarını belirliyor — hangi formatta veri göndereceksin, nasıl kimlik doğrulaması yapacaksın, hata durumunda ne olacak, bunların hepsi tanımlı.
Ha bu arada, daha önce Wilmer’e Tool Calling Geldi: Yerel AI Akışı Değişiyor yazısında tool calling meselesine değinmiştik. A2A bunu bir adım öteye taşıyor çünkü artık sadece araç çağırmıyorsunuz — başka bir ajanı çağırıyorsunuz ve o da kendi araçlarını kullanıyor.
Tool Space Interference (TSI) Sorunu
Size bir şey söyleyeyim, Bir dakika, şunu da ekleyeyim. Çok sayıda aracı tek bir ajana yüklediğinizde “Tool Space Interference” denen bir problem çıkıyor. 50-60 tane tool tanımladığınızda model hangisini ne zaman kullanacağını karıştırmaya başlıyor. Ben bunu kendi projelerimde fena halde yaşadım — 2024 başında bir otomasyon pipeline’ı kurarken 40’tan fazla fonksiyon tanımlamıştım ve model sürekli yanlış tool’u seçiyordu, saçma sapan yerlerden veri çekiyordu, gerçekten sinir bozucuydu.
Aslında, A2A yaklaşımı bu sorunu köküne iniyor. Her alt ajan sadece kendi uzmanlık alanındaki araçları barındırıyor. Sheets ajana Sheets işleri, Calendar ajanına Calendar işleri. Kafası karışmıyor. Sınırlı ve odaklanmış bir araç setiyle muhatap olduğunda model çok daha isabetli kararlar veriyor — bunu sayılarla da gördüm, geçiş sonrası hata oranı ciddi düştü (buna dikkat edin)
Google Apps Script Neden İdeal Bir A2A Sunucusu?
Bu soruyu çok duyuyorum: “Neden Flask ya da Express değil de GAS?” Açık konuşayım — GAS’ın bazı ciddi avantajları var ama dezavantajları da yok değil, ikisini de masaya yatıralım.
Dürüst olmak gerekirse, Öncelikle şu: GAS Google hesabınızla geliyor. Ek sunucu kurmanıza gerek yok. Web App olarak deploy ettiğinizde size bir URL veriyor ve bu URL hemen çalışıyor. Sunucu yönetimi, SSL sertifikası, port açma — bunların hiçbiriyle uğraşmıyorsunuz. Küçük ekipler ve solo geliştiriciler için bu fena bir avantaj değil, aksine bayağı kurtarıcı bir şey. Bir de şu var: GAS’ın Google Workspace API’larıyla doğal entegrasyonu var, OAuth scope’larını bir kere tanımlıyorsunuz, gerisini GAS hallediyor. Advanced Google Services üzerinden Sheets, Drive, — itiraz edebilirsiniz tabi — Calendar, Gmail — hepsine direkt erişebiliyorsunuz. Başka bir platformda aynı şeyi yapmak için servis hesabı oluşturup, token yönetimi yapıp, refresh mekanizması kurmanız gerekirdi. Uğraştırıcı.
GAS, low-code yapısı sayesinde hem insan geliştiriciler hem de üretken yapay zekâlar tarafından kolayca yazılabilir ve düzenlenebilir bir platform. Bu da onu A2A sunucuları için biçilmiş kaftan yapıyor.
Ama — dur bir saniye. Her şey güllük gülistanlık değil tabi. GAS’ın execution time limiti 6 dakika. Ağır işler için uygun değil. Ayrıca hata ayıklama deneyimi… nasıl desem… acı veriyor. Console.log ile debug yapıyorsunuz, breakpoint falan hayalini kurmayın. Yine de hafif, kategori bazlı ajanlar için baya iş görüyor.
Adım Adım Kurulum: GAS ile A2A Sunucusu Oluşturmak
1. Script Projesini Hazırlamak
İlk adım olarak Google hesabınızla script.google.com adresine gidiyorsunuz. Yeni bir standalone proje oluşturuyorsunuz — ya da GitHub’daki hazır şablonu kopyalıyorsunuz ki ben bunu öneriyorum,. A2A endpoint yapısı zaten kurulmuş oluyor.
Durun, bir saniye.
GAS projesinde iki ana fonksiyon var: doGet() ve doPost(). Agent Card bilgisi GET isteğiyle, görev yürütme ise POST isteğiyle gerçekleşiyor. Agent Card dediğimiz şey aslında ajanın kendini tanıttığı bir JSON yapısı — “ben şu işleri yapabilirim, bana şu formatta veri gönder” diyor kısaca. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
function doGet(e) {
// Agent Card bilgisini döndür
const agentCard = {
"name": "Google Sheets Agent",
"description": "Manages spreadsheet operations",
"url": ScriptApp.getService().getUrl(),
"capabilities": {
"streaming": false,
"pushNotifications": false
},
"skills": [
{
"id": "readSheet",
"name": "Read Spreadsheet Data",
"description": "Reads data from a specific Google Sheets range"
}
]
};
return ContentService
.createTextOutput(JSON.stringify(agentCard))
.setMimeType(ContentService.MimeType.JSON);
}
function doPost(e) {
const request = JSON.parse(e.postData.contents);
// Gelen goreve göre işlem yap
const taskId = request.params?.id || Utilities.getUuid();
//... is mantigi burada
const response = {
"jsonrpc": "2.0",
"id": request.id,
"result": {
"id": taskId,
"status": { "state": "completed" },
"artifacts": [{ "parts": [{ "text": "Işlem tamam!" }] }]
}
};
return ContentService
.createTextOutput(JSON.stringify(response))
.setMimeType(ContentService.MimeType.JSON);
}2. Web App Olarak Yayınlama
Kodu yazdıktan sonra Deploy > New Deployment yolunu izliyorsunuz. Type olarak “Web app” seçiyorsunuz. İşte burada kritik bir ayar var: “Who has access” kısmını “Anyone” olarak işaretlemeniz gerekiyor ki Gemini CLI erişebilsin. Execute as “Me” olarak kalacak — böylece GAS kodunuz sizin OAuth yetkilerinizle çalışıyor.
Çok konuştum, örnekle göstereyim.
Deploy ettikten sonra size bir URL veriyor — Bu URL’yi not edin. — Birazdan Gemini CLI yapılandırmasında kullanacaksınız. Copilot Alanları Neden Şaşırıyor: Grafikle Düzelen Hafıza yazımızda bu konuya da değinmiştik.
3. Kimlik Doğrulama Meselesi — Yerel Agent Card Çözümü
Şimdi gelelim işin pürüzlü kısmına. Gemini CLI normalde A2A sunucularına bağlanırken standart bir kimlik doğrulama akışı bekliyor. GAS Web Apps’in yapısı buna tam uymuyor. Hmm, biraz düşünmek gerek burada… Yapılan şey şu: yerel bir agent card dosyası oluşturup Gemini CLI’a “kardeşim, bu ajanı tanıyorum, doğrulamayı atla” diyorsunuz. Güvenlik açısından biraz riskli mi? Evet. Ama lokal geliştirme ortamı için gayet yeterli, ben de öyle kullanıyorum.
Gemini CLI Tarafında Yapılandırma
Gemini CLI’ı yapılandırmak için proje dizininizde veya ev dizininizde bir GEMINI.md ya da settings.json dosyası oluşturmanız gerekiyor. Uzak alt ajan tanımları buraya gidiyor.
Bir arkadaşım geçen ay bunu kendi startup’ında kurdu — müşteri destek taleplerini Gmail’den çekip, Sheets’e kaydedip, Calendar’a takip toplantısı atan bir pipeline yaptı. 3 farklı GAS alt ajanı Gemini CLI üzerinden orkestra ediyordu. “İlk gün 4 saat uğraştım ama sonra günde 2 saat kazanıyorum” demişti. Ben de inanamadım açıkçası. Rakamları gösterince ikna oldum. Nvidia Blackwell Kiraları Neden Uçtu? AI Faturası Büyüyor yazımızda bu konuya da değinmiştik.
Şimdi gelelim işin can alıcı noktasına. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
| Parametre | Açıklama | Örnek Değer |
|---|---|---|
| url | GAS Web App deploy URL’si | https://script.google.com/macros/s/AKfy…/exec |
| name | Ajanın tanımlayıcı adı | sheets-agent |
| description | Ajanın ne yaptığının kısa açıklaması | Google Sheets okuma/yazma işlemleri |
| auth | Kimlik doğrulama tipi | none (yerel card ile bypass) |
Gerçek Dünya Senaryoları ve Karşılaştırma
Peki bu yapı kimin ne işine yarıyor? Lafı gevelemeden söyleyeyim: herkesin değil.
Küçük bir ekip ya da solo geliştirici iseniz — şaşırtıcı derecede iyi iş çıkarıyor aslında (en azından benim deneyimim böyle). GAS’ın bedava kotası günlük 90 dakika execution time ve 20.000 URL fetch çağrısı veriyor. Çoğu otomasyon senaryosu için bu fazlasıyla yeterli. Ek sunucu masrafı yok, bakım derdi yok, Gemini CLI zaten bilgisayarınızda çalışıyor, GAS sunucuları Google’ın altyapısında. Toplam maliyet: sadece Gemini API key. Daha fazla bilgi için Yapay Zekâ Kod Yazıyor Ama İsim Vermek Hâlâ Zor yazımıza bakabilirsiniz.
Enterprise seviyede ise… işler biraz karışıyor. GAS’ın execution limitleri, hata yönetimi kısıtlamaları ve monitoring eksiklikleri büyük ölçekli deploymentlar için sorun olabiliyor. Böyle durumlarda Cloud Run ya da Cloud Functions üzerinde A2A sunucusu kurup Gemini CLI ile entegre etmek daha mantıklı. Ama prototipleme ve konsept kanıtlama aşamasında GAS yaklaşımı muazzam hız kazandırıyor — bunu deneyimle söylüyorum, boşuna övmüyorum.
Daha önce API Anahtarı Olmadan LLM: Ollama ile Yerelde Başlamak yazısında yerel çalışan modellere değinmiştik. Gemini CLI + GAS alt ajan yapısı da benzer bir felsefe taşıyor: mümkün olduğunca az bağımlılıkla, hızlıca çalışan bir şey kurmak. Sade. Etkili.
Dikkat Edilmesi Gerekenler ve Sınırlamalar
Açık konuşayım, Güzel bir yapı. Ama henüz ham — biraz daha pişmesi lazım. Birkaç şeyi not düşmek istiyorum:
- Streaming desteği yok: GAS Web Apps yapısı gereği streaming response döndüremiyor. Uzun süren işlemlerde kullanıcı “acaba çalışıyor mu” diye bekleyebilir. Biraz sinir bozucu oluyor.
- Cold start süresi: GAS Web Apps ilk istekte birkaç saniye gecikebiliyor. Etkileşimli kullanımda bu gecikme fark ediliyor, özellikle sık sık tetiklenen senaryolarda.
- Hata mesajları: GAS’ın hata mesajları genellikle kriptik. “Exception: Service invoked too many times” gibi bir şey gördüğünüzde ne yapacağınızı bilemeyebilirsiniz — ben de bir dönem bu yüzden saatler harcadım.
- Güvenlik: Web App URL’sini “Anyone” erişimine açtığınızda, URL’yi bilen herkes ajanınızı kullanabilir. Rate limiting veya IP kısıtlaması GAS tarafında mümkün değil. Bunu aklınızda tutun. — ciddi fark yaratıyor
Az önce “herkes için ideal” gibisinden bir izlenim vermiş olabilirim — aslında hedef kitle oldukça spesifik. Google Workspace kullanan, hızlıca otomasyon kurmak isteyen, altyapıyla uğraşmak istemeyen geliştiriciler için bu yaklaşım çok mantıklı. Diğerleri için muhtemelen daha geleneksel yollar daha sağlıklı. Kendinize göre değerlendirin.
Sıkça Sorulan Sorular
Gemini CLI ile GAS alt ajanı bağlamak için ücretli hesap gerekiyor mu?
Hayır, GAS tarafı büyük ölçüde ücretsiz Google hesabıyla çalışıyor. Ancak Gemini CLI için bir Gemini API anahtarına ihtiyacınız var (en azından benim deneyimim böyle). API’nin ücretsiz kotası var ama yoğun kullanımda ücretli plana geçmeniz gerekebilir.
A2A protokolü sadece Gemini CLI ile mi çalışıyor?
Hayır, A2A açık bir protokol. Google ADK, farklı A2A SDK’ları ve uyumlu diğer istemcilerle de çalışıyor. GAS üzerinde kurduğunuz A2A sunucusunu farklı platformlardan da çağırabilirsiniz.
Birden fazla GAS alt ajanını aynı anda kullanabilir miyim?
Evet, Gemini CLI birden fazla uzak alt ajanı eş zamanlı olarak yönetebiliyor. Her biri farklı bir GAS Web App olarak deploy edilmiş olabilir — biri Sheets için, biri Drive için, biri Calendar için gibi.
GAS’ın 6 dakikalık execution limiti sorun yaratır mı?
Çoğu A2A isteği saniyeler içinde tamamlanıyor, o yüzden genellikle sorun olmuyor. Ama büyük veri setleri üzerinde işlem yapıyorsanız (mesela 10.000 satırlık bir Sheets dosyasını parse etmek) limite takılabilirsiniz. Bu durumda işlemi parçalara bölmeniz gerekir.
Bu yapı production ortamında güvenli mi?
Geliştirme ve prototipleme için gayet uygun (yanlış duymadınız). Ancak production ortamında ek güvenlik katmanları eklemeniz gerekiyor — en azından Web App URL’sini gizli tutmak, mümkünse Cloud Endpoints arkasına almak önerilir. Yerel agent card yaklaşımı production için yeterli güvenlik sağlamıyor.
Kaynaklar ve İleri Okuma
Gemini CLI — GAS A2A Subagents GitHub Deposu
Google Apps Script Web Apps Resmi Dokümantasyonu
Google Agent-to-Agent (A2A) Protokolü Tanıtımı
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
