Welcome to Agents Week · Rita Kozlov
Cloudflare bir haftalık duyuru serisi açıyor ve açılış yazısı teknik değil, kavramsal. Sordukları soru şu: bugünkü bulut ve üstündeki web, insanlar için tasarlandı. Her katman ekranın başında bir insan olduğunu varsayıyor — dikkat çekmek için tasarlanmış sayfalar, tıklanacak panolar, insan okuma hızına göre ayarlanmış arayüzler.
Yazılım agent’ları böyle çalışmıyor. Dikkatleri dağılmıyor, yorulmuyor; buna karşılık hız, yapı ve erişim konusunda kendi ihtiyaçları var. Cloudflare'in iddiası bir "Agent Cloud"un iki işi aynı anda yapması gerektiği: agent’lar için sıfırdan tasarlanmış temel yapıtaşları sunmak, ve bu arada bugünkü insan-şekilli web ile agent-şekilli web arasında bir çeviri katmanı olarak durmak.
Öne çıkanlar
- Bugünkü web'in her katmanı "karşıda bir insan var" varsayımıyla tasarlandı; agent’lar bu varsayımı bozuyor.
- İki ayrı ihtiyaç var: agent-yerel (agent-native) yeni yapıtaşları, ve mevcut web'i agent’lara çevirecek bir ara katman.
- Yazının kendisi bir duyuru değil, çerçeve kurma denemesi — asıl teknik içerik haftanın geri kalanında geliyor.
Neden önemli?
Bu tür "çerçeve kurma" yazıları genelde pazarlama olur, ama buradaki gözlem gerçek bir mühendislik sorusuna işaret ediyor: bir API'yi insan geliştiriciler mi yoksa bir LLM mi tüketecek, tasarımı değiştirir. Hata mesajları, sayfalama, kimlik doğrulama akışları, dokümantasyon biçimi — hepsi consumer’ın insan olup olmamasına göre farklılaşır.
Pratikte
Bunu somut bir tasarım kontrolüne çevir: bir LLM bir API’ni çağıracaksa dönen hata mesajı ‘400 Bad Request’ değil ‘tarih formatı YYYY-MM-DD olmalı, sen 12/03/2026 gönderdin’ olmalı, çünkü modelin kendini düzeltmesi için okunabilir bir sinyal gerekiyor. Aynı şekilde pagination: insan ‘sonraki sayfa’ düğmesine basar, agent ise toplam sayıyı ve kalanı bilmek ister. Bu küçük kararlar, LLM tabanlı bir istemcinin çalışıp çalışmamasını belirliyor.
Sözlük
- agent
- Bir hedefi verilen, hangi araçları hangi sırayla çağıracağına kendisi karar veren LLM tabanlı program.
- primitive
- Bir platformun sunduğu en küçük yapı birimi (kuyruk, nesne deposu, çalıştırma birimi gibi).
Bugün az yayın çıktı. Bu yazılar daha eski tarihli ama hâlâ öğretici;
her birinin gerçek yayın tarihi başlığın üstünde yazıyor.
Building Effective AI Agents
Anthropic onlarca ekiple LLM tabanlı agent kuruldu ve şu sonuca varmış: en başarılı uygulamalar karmaşık framework'ler kullanmıyordu, basit ve birleştirilebilir desenler kullanıyordu.
Yazının en değerli kısmı bir ayrım: workflow (workflow) ile agent aynı şey değil. Workflow'da adımlar önceden kodla tanımlanır; agent'ta hangi aracı ne zaman kullanacağına modelin kendisi karar verir. Workflow öngörülebilir ve tutarlıdır, iyi tanımlanmış görevler için doğru seçimdir. Agent ise esneklik ve ölçekte model-güdümlü karar gerektiğinde kazanır. Anthropic'in tavsiyesi net: en basit çözümle başla, ancak gerektiğinde karmaşıklığı artır — çoğu uygulama için tek bir LLM çağrısını retrieval ve örneklerle güçlendirmek zaten yeterli.
Öne çıkanlar
- Agent sistemleri gecikme ve maliyeti, görev başarısıyla takas eder. Bu takasın ne zaman mantıklı olduğunu bilerek karar ver.
- Framework'ler başlangıcı kolaylaştırır ama araya soyutlama katmanı koyar; altındaki prompt'u ve çağrıları göremezsen hata ayıklamak zorlaşır.
- Tavsiye: doğrudan LLM API'siyle başla. Çoğu desen birkaç satır kod.
- Temel yapıtaşı "güçlendirilmiş LLM": retrieval + araçlar + hafıza eklenmiş bir model.
Pratikte
Eğer 10.000+ kaydı işleyen bir LLM sınıflandırma pipeline’ı yazdıysan, bu yazının tanımıyla o bir *workflow*, agent değil ve doğrusu da o. Bunu mülakatta böyle anlatabilmen değerli: ‘sınıflandırma adımları sabit olduğu için agent kurmadım, deterministik bir pipeline yazdım; model kararı yalnızca sınıflandırma noktasında devreye giriyor.’ Bir doküman aramada ise agent mantıklı olabilir, çünkü hangi belgeye bakılacağı sorudan soruya değişiyor. Ayrımı bilerek seçmek, ikisini de körlemesine kullanmaktan iyi.
Sözlük · 3 terim
- workflow
- Adımların ve sıralarının önceden kodla belirlendiği sistem; model sadece belirli noktalarda karar verir.
- agentic system
- Modelin araç seçimini ve sırasını kendi belirlediği sistem; esnek ama daha az öngörülebilir.
- augmented LLM
- Retrieval, araç kullanımı ve hafıza yetenekleriyle desteklenmiş dil modeli — agent mimarilerinin temel birimi.
How Uber Conquered Database Overload: The Journey from Static Rate-Limiting to Intelligent Load Management
Uber'in binlerce mikroservisi 170 milyondan fazla aylık aktif kullanıcıya hizmet veriyor. Altta Docstore ve Schemaless var: MySQL üzerine kurulmuş, binlerce küme, onlarca petabyte veri, saniyede on milyonlarca istek.
Bu ölçekte küçük aşırı yüklenmeler izole kalmıyor, çığ etkisi yaratıyor: bir yerdeki kısa ani yük aşağı akıştaki servislerin zaman aşımına uğramasına, yeniden denemelerin (retry) birikmesine ve bozulmanın büyüyerek genel bir arızaya dönüşmesine yol açıyor.
İlk denedikleri çözüm klasik: sorgu motoru katmanında kota tabanlı rate limiting. Her isteğe işlenen bayta göre bir maliyet ver, kullanıcılara sabit kota tanı, aşınca 429 dön. Ama işe yaramamış. Sebebi öğretici: her istek için Redis'e gitmek gerekiyordu — yani yeni bir hata noktası ve fazladan bir ağ turu. Yükü korumak için eklenen mekanizmanın kendisi yük ve kırılganlık üretiyordu.
Öne çıkanlar
- Multi-tenant (multitenant) bir sistemde tek bir tenant’ın tüm kaynağı yutmasını engellemek, korumanın yarısı kadar önemli.
- Statik kota işe yaramıyor çünkü iş yükleri trafik şekli, gecikme profili ve sistem etkisi bakımından birbirine benzemiyor.
- Mimari üç katman: durumsuz sorgu motoru (yönlendirme, şema, yetkilendirme), durumlu depolama motoru (işlem, replikasyon), ve Raft ile koordine edilen 1 lider + 2 takipçi bölümler.
- Çözüm tek bir sinyale değil, birden fazla sinyalden aşırı yükü tespit eden bir yük yöneticisine dayanıyor.
Pratikte
Piyasa verisi ya da harici bir API çekerken rate limit mantığı kurduysan, oradaki tasarıma bu gözle bir daha bak. Redis’i sayaç olarak kullanıyorsan Redis düştüğünde ne oluyor: istekler geçiyor mu (fail-open) yoksa duruyor mu (fail-closed)? İkisi de geçerli bir karar ama bilinçli verilmiş olmalı. Ayrıca yerel bir token bucket (in-process) ile merkezî sayacı birleştirmek, her istekte ağ turu ödemekten çok daha ucuz; Uber’in tam da kaçındığı maliyet bu.
Sözlük · 4 terim
- cascading failure
- Bir bileşendeki küçük bir sorunun, yeniden denemeler ve zaman aşımlarıyla büyüyerek tüm sistemi düşürmesi.
- multitenant
- Aynı altyapıyı birden fazla bağımsız kullanıcının/servisin paylaşması; adil kaynak paylaşımı gerektirir.
- Raft
- Bir lider ve takipçiler arasında verinin tutarlı kopyalanmasını sağlayan uzlaşı (consensus) protokolü.
- rate limiting
- Belirli bir sürede kabul edilecek istek sayısını sınırlayarak sistemi aşırı yüklenmeden koruma tekniği.