Bir Yapay Zekâ Ajanını İşe Aldınız: Peki Başında Kim Duracak?

Bir yapay zekâ ajanına bilgisayarınızı teslim edip uyumaya gider miydiniz?

Gece boyunca kod yazabildiğini, paket kurabildiğini, internette araştırma yapabildiğini, dosyaları değiştirebildiğini ve sabah size tamamlanmış bir iş bırakabildiğini düşünün. Kulağa iyi geliyor. Peki aynı ajan görevi bitiremezse kaç saat çalışacak? Ne kadar token harcayacak? Hangi sitelere bağlanacak? Yanlış dosyayı silerse veya aynı işlemi iki kez yaparsa onu kim durduracak?

Yapay zekâ ajanlarını konuşurken çoğunlukla zekâlarına odaklanıyoruz: Hangi model daha iyi düşünüyor, hangisi daha iyi kod yazıyor, hangisi daha fazla araç kullanabiliyor? Oysa bir ajanı gerçek hayatta çalıştırmaya başladığınız anda asıl soru değişiyor.

Bir ajanı yalnızca ne yapabildiğiyle değil, siz yokken ne yapmasına izin verildiğiyle tasarlarsınız.

Bir çalışanı yalnızca yetenekli olduğu için işe almazsınız. Ona bir görev tanımı, çalışma alanı, bütçe, mesai, erişim kartı ve yönetici verirsiniz. Yapay zekâ ajanları için de artık aynı yönetim katmanına ihtiyacımız var. Teknoloji dünyası buna giderek daha sık agent runtime, yani ajanın içinde çalıştığı operasyon ortamı diyor.

Model çağrısı ile dijital çalışan arasındaki fark

Klasik bir model çağrısı oldukça kısa bir ilişki kurar. Bir girdi gönderirsiniz, model bir çıktı üretir ve işlem biter. Ajan ise tek bir cevapla yetinmez. Hedefi yorumlar, plan yapar, araç kullanır, sonucu okur, gerekirse yeniden dener ve birden fazla tur boyunca durum taşır.

Model çağrısı:
İstek → Model → Cevap

Ajan çalışması:
Hedef → Plan → Araç → Sonuç → Doğrulama
          ↑                         │
          └──────── yeni tur ───────┘

İkinci yapı daha güçlüdür; fakat aynı nedenle daha pahalı ve daha risklidir. Her yeni turda token harcanır. Her araç çağrısı dış dünyada bir değişiklik yapabilir. Her korunan dosya bir sonraki çalışmayı etkileyebilir. Modelin zekâsı ajanın ne yapacağını belirlerken runtime, hangi sınırlar içinde yapabileceğini belirler.

Managed agent neden şimdi önemli?

Google AI Studio, 16 Temmuz 2026’da Gemini API’deki Managed Agents özelliklerini genişlettiğini duyurdu. Duyuruda ücretsiz önizleme erişimi, toplam token bütçesi ve zamanlanmış tetikleyiciler öne çıkıyor. Yönetilen ajan tek bir istekle akıl yürütme, kod çalıştırma, paket kurma, dosya yönetimi ve web araştırması yapabiliyor; bütün bunlar izole bir bulut ortamında gerçekleşiyor.

Asıl önemli olan yeni bir ürün adı değil. Bu özellikler, ajan geliştirmenin model seçmekten runtime tasarlamaya doğru kaydığını gösteriyor. Bir ajanı üretimde çalıştırmak için en az altı soruya cevap vermeniz gerekiyor:

1. Nerede çalışacak? Kendi makinenizde mi, container içinde mi, yönetilen bir cloud sandbox’ında mı?
2. Ne kadar harcayabilir? Tur, zaman, token veya para sınırı nedir?
3. Ne zaman başlayacak? İnsan komutu, cron, webhook veya başka bir olay mı tetikleyecek?
4. Neyi hatırlayacak? Dosyalar, önceki sonuçlar ve çalışma durumu ne kadar süre korunacak?
5. Nereye erişebilir? Hangi dosyaları, API’leri ve internet domainlerini kullanabilir?
6. Kim denetleyecek? Logları kim okuyacak, hatayı kim fark edecek, geri dönüşü zor işi kim onaylayacak?

Bu soruların hiçbirini “daha zeki bir model” tek başına çözmez. Bunlar ürün ve altyapı tasarımıdır.

Dijital çalışanın çalışma sözleşmesi

Runtime kavramını teknik terimlerle değil, işe aldığınız bir çalışan üzerinden düşünmek daha kolaydır.

• Prompt ve hedef, görev tanımıdır. Çalışanın ne üretmesi gerektiğini söyler.
• Sandbox, çalışma odasıdır. Ajanın çevresindeki sistemin tamamına değil, sınırlandırılmış bir alana dokunmasını sağlar.
• Token bütçesi, şirket kartının limitidir. İş önemli olsa bile sınırsız harcama yapılamaz.
• Tetikleyici, mesai programıdır. Ajanın ne zaman iş başı yapacağını belirler.
• Ağ izin listesi, erişim kartıdır. Hangi servislerin kapısından geçebileceğini tanımlar.
• Kalıcı ortam, çalışma masasıdır. Dünkü dosyalar ve notlar bugün de yerinde durur.
• Log ve insan onayı, yöneticidir. İşin yapıldığını değil, doğru yapıldığını kontrol eder.

Bu parçalar bir araya gelmeden “otonom ajan” dediğimiz şey, ne kadar çalışacağını ve ne zaman duracağını bilmeyen güçlü bir yazılımdır.

Bütçe sınırı yalnızca faturayı korumaz

Google’ın yeni yaklaşımında max_total_tokens değeri bir ajanın girdi, çıktı ve düşünme tokenlarının toplamına sınır koyuyor. Limit dolduğunda çalışma başarısız olmuş gibi çöpe atılmıyor; incomplete durumuyla güvenli biçimde duruyor. Dosya sistemi ve çalışma ortamı korunabildiği için yeni bir bütçeyle kaldığı yerden devam edebiliyor.

agent_config:
  max_total_tokens: 10000

Limit dolduğunda:
  status: incomplete
  ortam: korunur
  sonraki karar: devam et veya incele

Bu küçük görünen ayrım önemli. İyi bir bütçe sınırı ajanın işini yarıda kesen kör bir sigorta değildir; işi kontrol noktasına getirir. Sistem “daha fazla harcayayım mı, yaklaşımı değiştireyim mi, insana mı sorayım?” kararını verebilir.

Ancak token sınırı tek başına yeterli değildir. Ajan on bin tokenı aynı hatayı tekrar ederek de tüketebilir. Bu nedenle bütçenin yanında başarı ölçütü ve ilerleme kontrolü bulunmalıdır:

Çalışma sınırı =
başarı kanıtı
+ token bütçesi
+ maksimum süre
+ ilerleme kontrolü
+ başarısızlık raporu

Döngü tasarımı yazısında konuştuğumuz durma koşulu burada finansal ve operasyonel bir kurala dönüşüyor. Runtime, promptta verdiğiniz tavsiyeyi sistem seviyesinde uygular.

Tetikleyici, ajanın mesaisidir

Yönetilen ajanlardaki zamanlanmış tetikleyici; ajanı, ortamı, görevi ve cron programını kalıcı bir kaynakta birleştiriyor. Böylece her sabah açık issue’ları incelemek, gece regresyon raporu hazırlamak veya belirli aralıklarla içerik kaynaklarını kontrol etmek için dışarıda ayrı bir cron sunucusu kurmak gerekmeyebiliyor.

Her sabah 09.00:
1. Yeni kayıtları kontrol et.
2. Daha önce işlenenleri atla.
3. Uygun olanları sınıflandır.
4. Raporu çalışma alanına kaydet.
5. Geri dönüşü zor işlem için onay iste.

Fakat programlanmış olmak, güvenilir olmak değildir. Zamanlanmış bir ajan aynı girdiyi iki kez görürse aynı işlemi iki kez yapmamalıdır. Buna yazılım dünyasında idempotency denir. Örneğin aynı içeriği tekrar yayınlamamalı, aynı müşteriye ikinci mesajı göndermemeli veya aynı issue için yeniden branch açmamalıdır.

Ayrıca her iş cron gerektirmez. Dış sistem webhook gönderebiliyorsa ajanı beş dakikada bir “bir şey değişti mi?” diye uyandırmak yerine yalnızca gerçek olay geldiğinde çalıştırmak daha ucuz ve daha hızlıdır.

Hafıza verimlilik kadar risk de taşır

Kalıcı çalışma ortamı güçlüdür. Ajan ilk çalışmada repoyu klonlar, bağımlılıkları kurar ve sonuçları kaydeder; sonraki çalışmada aynı hazırlığı tekrarlamaz. Önceki raporları okuyabilir, işlenmiş kayıtları ayırabilir ve uzun süren göreve kaldığı yerden devam edebilir.

Fakat masanın üzerindeki her şey doğru ve güncel değildir. Eski bir dosya, bozuk bağımlılık, saldırgan bir web sayfasından kaydedilmiş talimat veya önceki turun yanlış varsayımı sonraki çalışmayı etkileyebilir. Bu yüzden kalıcı ortamın da yaşam döngüsü olmalıdır:

• Hangi dosyaların kalıcı olacağı açıkça belirlenmeli.
• Geçici indirmeler ve hassas bilgiler çalışma sonunda temizlenmeli.
• Ortam belirli aralıklarla güvenilir bir snapshot’a döndürülmeli.
• Kaynağı bilinmeyen talimatlar veri olarak işlenmeli, komut olarak kabul edilmemeli.
• Bağımlılık ve yetki değişiklikleri kayda alınmalı.

Hafıza, ajanın tekrar öğrenmesini önler; temizlik politikası ise eski hataların geleceği yönetmesini önler.

Ağ erişimi: İnternet var mı sorusundan daha fazlası

Bir ajana “internete çıkabilir” veya “çıkamaz” demek çoğu gerçek iş için fazla kaba bir ayrımdır. Kod ajanı GitHub’a erişirken rastgele dosya paylaşım sitelerine erişmemeli olabilir. İçerik ajanı kaynak sayfalarını okuyabilmeli ama üretim veritabanına bağlanmamalıdır.

Google’ın örneklediği network allowlist yaklaşımı, erişimi domain seviyesinde tanımlıyor. Aynı mantık hangi header’ın ekleneceği, hangi secret’ın yalnızca belirli servise gönderileceği ve hangi isteğin tamamen engelleneceği için de kullanılabilir.

En önemli kural şudur: Ajanın görevi genişledikçe yetkisi otomatik olarak genişlememelidir. Okuma, yazma, yayınlama, para harcama ve silme yetkileri birbirinden ayrılmalıdır. Özellikle internette araştırma yapan ajan, okuduğu sayfadaki kötü niyetli talimatı prompt sanabilir. Üretim tokenını aynı çalışma ortamında tutmak bu nedenle gereksiz bir risktir.

Managed servis mi, kendi altyapınız mı?

Her ajan için yönetilen bir cloud servisi kullanmak zorunda değilsiniz. Aynı mimariyi Codex CLI, Claude Code, bir queue, container, n8n veya kendi worker servisinizle de kurabilirsiniz. Seçim, ne kadar kontrol istediğiniz ve ne kadar operasyon yükü taşıyabileceğinizle ilgilidir.

İlk prototipte yönetilen servis hız kazandırabilir. Hassas veri, özel araçlar, mevcut abonelikler veya sıkı altyapı kuralları varsa kendi worker’ınız daha mantıklı olabilir. Burada doğru cevap “hangisi daha gelişmiş?” değil, hangi sorumlulukları satın almak, hangilerini kendiniz taşımak istediğinizdir.

Bir ajanı gece yalnız bırakmadan önce

Ajanınızı siz yokken çalıştırmadan önce şu kontrol listesini tamamlayın:

1. Tek bir ölçülebilir görev verin. “Projeyi geliştir” değil, doğrulanabilir bir çıktı tanımlayın.
2. Token ve süre bütçesi koyun. İkisinden biri dolduğunda güvenli durmasını sağlayın.
3. Yazabileceği alanı daraltın. Bütün sunucu yerine geçici repo veya çalışma klasörü kullanın.
4. Ağ erişimini listeleyin. “İnternet açık” yerine izin verilen servisleri tanımlayın.
5. Tekrar çalışmaya dayanıklı yapın. Aynı olay ikinci kez geldiğinde çift işlem üretmesin.
6. Geri dönüşü zor adımı ayırın. Yayınlama, ödeme, mesaj gönderme ve silme için insan onayı isteyin.
7. Ne yaptığını kaydedin. Araç çağrıları, harcama, değişen dosyalar ve sonuç görünür olsun.
8. Başarısızlığı da tasarlayın. Yeniden deneme sayısı, karantina ve insana devretme yolu belli olsun.

Intent, context, loop ve runtime

Bu seride kurduğumuz yapı artık tamamlanmaya başlıyor:

• Intent engineering, neden çalıştığımızı ve başarının ne olduğunu tanımlar.
• Context engineering, ajanın karar verirken neyi göreceğini belirler.
• Ajan tasarımı, modelin hangi araçlarla eyleme geçeceğini düzenler.
• Döngü tasarımı, ne zaman yeniden çalışacağını ve hangi kanıtla duracağını belirler.
• Runtime tasarımı, bütün bunların nerede, hangi bütçe, hafıza ve yetkiyle gerçekleşeceğini yönetir.

Güvenilir dijital çalışan =
Niyet × Bağlam × Araçlar × Döngü × Runtime × Denetim

Bu çarpanlardan biri eksikse daha güçlü model yalnızca problemi daha hızlı büyütebilir. Hedef belirsizse yanlış işe gider. Bağlam kötüyse yanlış bilgiyle karar verir. Runtime sınırsızsa yanlış kararı daha uzun süre ve daha yüksek maliyetle uygular.

Son söz

Yapay zekâ ajanlarının önündeki büyük eşik artık yalnızca daha iyi düşünmeleri değil, güvenilir biçimde çalıştırılmalarıdır. Bütçe, sandbox, tetikleyici, kalıcı durum, ağ sınırı ve gözlemlenebilirlik birer yan özellik değil; otonominin çalışma koşullarıdır.

Bir ajanı işe aldıysanız başında her saniye bir insan beklemek zorunda değildir. Fakat insanın verdiği kararlar sistemin kurallarına dönüşmelidir: Ne yapacak, ne kadar harcayacak, nereye girecek, neyi hatırlayacak ve hangi noktada sizi çağıracak?

Yapay zekâ ajanlarının geleceğini en zeki model değil, en güvenli ve yönetilebilir çalışma ortamını kuranlar belirleyecek.

Kaynaklar

• Google AI Studio — Gemini API Managed Agents: free tier, triggers & more
• Gemini API — Interactions API overview
• Gemini API — Antigravity managed agent
• Gemini API — Agent environments and network rules
• Gemini API — Managed agents quickstart