LLM ajanları 20 yıllık web mimarisini zorluyor

Son yirmi yıldır web servisleri tek bir varsayım üzerine inşa edildi: durum veritabanında tutulur, uygulama sunucuları ise durumsuzdur (stateless). Ölçeklenmek istediğinizde veritabanını büyütür ya da parçalarsınız, sunucuları ise yatayda çoğaltırsınız; hangi isteğin hangi sunucuya gittiği önemli değildir çünkü gerçek kaynak veritabanıdır. LLM tabanlı ajanlar bu varsayımı sessizce kırıyor: uzun süren işler artık tek bir 'istek' değil, dakikalarca sürebilen asenkron süreçler; ajan birden fazla tur ve araç çağrısı boyunca bağlam biriktiriyor, bu durum veritabanı durumu değil ajanın belleği; ve kullanıcı süreci izlemek, kesip yönlendirmek istiyor — bu da durumsuz bir API sorgusundan çok, çalışan bir sürece konuşmak anlamına geliyor.

Temporal, Inngest gibi dayanıklı yürütme (durable execution) çözümleri işi güvenilir hale getiriyor ama alttaki mimari yine durumsuz varsayılıyor. Asıl sorun yönlendirme: HTTP, yük dengeleyici ve durumsuz sunucu üçlüsü yalnızca veritabanına yönlendirme yapabilir, belirli bir çalışan sürece değil. Bu yüzden herkes polling'e geri dönüyor — veritabanına yazılan güncellemeleri sürekli sorgulamak, gecikme, gereksiz istek ve kötü kullanıcı deneyimi pahasına.

Çözüm önerisi, sunucudan bağımsız, adreslenebilir bir taşıma katmanı: pub/sub kanalları. WebSocket'ler bir bağlantı sağlar ama bağlantı koptuğunda adres de kaybolur; pub/sub kanalları ise sahipliği tersine çevirir, kanalın kendisi kalıcı adres olur, hem istemci hem de süreç bu isimle bağlanıp kopsa bile aynı kanala yeniden bağlanabilir. Bu, LLM'lere özgü bir sorun değil; asıl mesele LLM'lerin deterministik olmaması ve pahalı olmasının, zaten var olan mimari eksikliği görünür kılmasıdır. Mühendisler için çıkarım net: dayanıklı yürütme, pub/sub ve durumsuz HTTP'yi birlikte, her birini kendi işini yaparak kullanan yeni bir mimari yaklaşıma ihtiyaç var.