Ajan tasarımı hâlâ zor

• Ajan geliştirme süreci hâlâ karmaşık ve SDK soyutlamalarının gerçek araç kullanım aşamasında sık sık bozulması sorunu sürüyor
• Önbellek yönetimi platforma göre değişiyor; manuel yönetim daha öngörülebilir ve verimli, Anthropic SDK'nın açık önbellek noktası yaklaşımı tercih ediliyor
• Güçlendirme döngüsü (reinforcement loop) görev durumunu izleme ve hata kurtarmada kilit rol oynuyor; döngünün çökmesini önlemek için hataların ayrı yalıtılması gerekiyor
• Paylaşılan durum yönetimi için dosya sistemi benzeri bir hiyerarşi önemli; kod çalıştırma ve çıkarım araçları arasındaki veri alışverişinin temel yapısı olarak kullanılıyor
• Çıktı aracı ve model seçimi hâlâ zorlu; Haiku, Sonnet ve Gemini modelleri başlıca seçenekler olarak kalırken ajan tasarımının karmaşıklığı sürüyor

---

Ajan SDK seçimi

• Ajan geliştirirken OpenAI, Anthropic gibi temel SDK'ları doğrudan mı kullanacağınıza, yoksa Vercel AI SDK veya Pydantic gibi üst düzey soyutlama katmanlarını mı seçeceğinize karar vermek gerekiyor
  • Yazar geçmişte yalnızca Vercel AI SDK'nın provider abstraction katmanını kullandığını, ancak bugün olsa aynı seçimi tekrarlamayacağını belirtiyor
• Modeller arasındaki farklar büyük olduğu için ajan soyutlama katmanını doğrudan kendiniz kurmanız gerekiyor; mevcut SDK soyutlamaları uygun değil
  • Önbellek kontrolü, güçlendirme gereksinimleri, araç prompt'ları gibi alanlarda ince farklar var
• Vercel SDK'da sağlayıcı taraflı araç işleme sırasında sorun çıkıyor
  • Anthropic'in web arama aracının mesaj geçmişini bozduğu durumlar var
  • Anthropic SDK doğrudan kullanıldığında önbellek yönetimi ve hata mesajları daha açık oluyor
• Sonuç olarak şu anda soyutlama katmanı olmadan SDK'ları doğrudan kullanma yaklaşımının daha avantajlı olduğu değerlendiriliyor

Önbellek yönetiminden çıkarılan dersler

• Platformlara göre önbelleğe alma yaklaşımı farklı; Anthropic önbellekleme için ücret alıyor ve açık yönetim istiyor
  • Manuel yönetim maliyetleri ve önbellek kullanımını öngörülebilir hâle getirdiği için tercih ediliyor
• Açık önbellekleme, konuşma dallarını çalıştırmayı veya bağlam düzenlemeyi mümkün kılıyor
  • Sistem prompt'undan sonra, konuşmanın ilk bölümü gibi çeşitli önbellek noktaları ayarlanıyor
• Önbelleği korumak için sistem prompt'u ve araç seçimi statik tutuluyor, zaman gibi dinamik bilgiler ise sonraki mesajlarla aktarılıyor
• Güçlendirme döngüsü önbellekle birlikte etkin biçimde kullanılarak maliyet öngörülebilirliği ve kontrol seviyesi artırılıyor

Ajan döngüsü içinde güçlendirme (Reinforcement)

• Araç çalıştırıldığında yalnızca basit sonuç döndürmek yerine hedef, görev durumu ve hata nedenleri gibi bilgiler döngüye yeniden enjekte edilebiliyor
• Claude Code'un todo write aracı gibi öz-güçlendirme (self-reinforcement) araçları döngünün ilerlemesine yardımcı oluyor
• Ortam değiştiğinde veya hata kurtarma anında durum değişikliği bilgisinin enjekte edilmesi döngü kararlılığını sağlıyor
  • Örneğin bozulmuş veriye dayanarak yeniden deneme yapılırken, önceki aşamaya dönülmesini söyleyen bir mesaj ekleniyor

Hataları yalıtma (Isolate Failures)

• Tekrarlayan hata beklenen işler alt ajanlara (subagent) ayrılarak çalıştırılıyor ve yalnızca başarılı sonuç üst döngüye bildiriliyor
  • Başarısız denemelerin özeti bir sonraki görev için öğrenme materyali olarak kullanılıyor
• Anthropic SDK'da bağlam düzenleme (context editing) özelliğiyle hata kayıtları kaldırılabiliyor
  • Tüm hata bilgisini tutmak yerine yalnızca gereken kısımlar bırakılıyor
  • Ancak bağlam düzenleme önbelleği geçersiz kıldığı için maliyeti artırabiliyor

Alt ajanlar ve paylaşılan dosya sistemi

• Çoğu ajan kod çalıştırma ve üretim tabanlı olduğu için ortak bir veri deposuna ihtiyaç duyuyor
  • Bunun için sanal dosya sistemi (VFS) kullanılıyor
• Görsel üretimi, sıkıştırma, çıkarım gibi farklı araçların aynı dosya yolunu paylaşması gerekiyor
  • ExecuteCode ve RunInference araçlarının aynı dosya sistemine erişebilmesi gerekiyor
• Bu yapı, veri alışverişindeki darboğazları ortadan kaldırmak ve döngü içindeki ardışık işleri işlemek için vazgeçilmez

Çıktı aracı (Output Tool)

• Ajanlar bir sohbet oturumu değil, özel bir iç mesaj döngüsü olarak çalışıyor; dış dünyayla iletişim ise çıktı aracı üzerinden kuruluyor
  • Çıktı aracı e-posta gönderimi gibi dış iletişimi üstleniyor
• Çıktı aracında ton ve üslup kontrolü zor; yardımcı LLM (Gemini 2.5 Flash) kullanıldığında kalite düşüşü ve gecikme yaşanıyor
  • Alt araç yeterli bağlama sahip olmadığı için hatalı sonuçlar üretebiliyor
• Döngü bitiminde çıktı aracı çağrılmamışsa, güçlendirme mesajı eklenerek çağrılması teşvik ediliyor

Model seçimi

• Haiku ve Sonnet, araç çağırma performansı güçlü olduğu için ana döngü modelleri olarak kullanılıyor
• Gemini 2.5, büyük belge özetleme, PDF işleme ve görselden bilgi çıkarma için uygun
  • Sonnet modelinin sık sık güvenlik filtrelerine takılması bir dezavantaj
• GPT serisi modeller ana döngüde kayda değer bir başarı göstermedi
• Toplam maliyet yalnızca token maliyetine bakılarak değerlendirilemez
  • Araç çağırmada daha iyi bir model, aynı işi daha az token ile yapabiliyor

Test ve değerlendirme (Evals)

• Ajan testlerini ve değerlendirmelerini otomatikleştirmek en zor sorun olarak gösteriliyor
  • Prompt'lardan farklı olarak, dış sistemlerde basitçe değerlendirmek mümkün değil
  • Gerçek yürütme verisine dayanan gözlemlenebilirlik (observability) veya enstrümantasyon (instrumentation) gerekiyor
• Şu ana kadar tatmin edici bir değerlendirme yöntemi bulunamadığı belirtiliyor

Kodlama ajanı güncellemesi

• Kodlama ajanlarıyla ilgili değişiklikler büyük değil
  • Son dönemde Amp ajanı deneniyor ve Oracle alt ajanı ile ana döngü arasındaki etkileşim yapısı yüksek değerlendiriliyor
• Amp ve Claude Code, kendi araçlarını gerçekten kullanan geliştiriciler odaklı bir tasarım hissi veriyor

[GN⁺]

Hacker News yorumu

• Yaklaşık 2 yıl önce bu alanda bir şirket kurdum. Şu anda iyi gidiyor
  Son 2 yılda öğrendiğim şey, birçok tekniğin LLM’lerin mevcut sınırlarını telafi etmek için yapılmış geçici optimizasyonlar olduğuydu. Teknoloji çok hızlı ilerlediği için bugünün sorunu yarın ortadan kalkabiliyor
  Eskiden AWS’de disk şifreleme özelliği yokken, ekip bunu kendisi uygulamak için 3 ay harcamıştı; hemen ardından AWS tek tıklamayla çalışan standart şifrelemeyi çıkardı. Sonuçta bu zaman kaybı oldu
  Bu yüzden öğrendiğim şey, bazen hiçbir şey yapmamanın en iyisi olabildiği

  • Bence asıl içgörü bu. Şirketteki çalışma arkadaşlarım bugünlerde AI atölyeleri düzenleyip yeni kalıplar “icat ettiklerini” söylüyor ama çoğu gelecek hafta demode oluyor
    Eskiden ortak bir dille kalıpları öğrendiğimiz dönem bitti; artık AI kalıplarının yarı ömrü bir hafta kadar. Hatta 10 uzmana “agent”ın ne olduğunu sorarsanız 10 farklı cevap alırsınız
  • AI’nin ilerleme hızına bakınca, yeterince beklerseniz işin sonu OpenAI’yi doğrudan kullanmaya da varabilir
  • Acaba geliriniz işletme giderlerini aşan bir kârlı yapı mı var diye merak ediyorum. Agent’larla gelir elde etmenin mümkün olduğuna inanmakta zorlanıyordum. Sırrınız nedir, bilmek isterim
  • ‘Hiçbir şey yapmamak’ gerektiğini iyi bilmek, ekibin uğraştığı problemin temel mi yoksa çevresel bir problem mi olduğunu değerlendirme becerisiyle ilgili
  • Katılıyorum. Bugünlerde beklemek de bir strateji olabilir. Ama fazla beklerseniz, AGI çıkana kadar hiçbir şey yapmama tuzağına da düşebilirsiniz

• Son 2 yılda çeşitli agent SDK’larını kullandım; kendim yapmayı deneyince bunun düşündüğümden çok daha karmaşık olduğunu gördüm
  Claude Code SDK (şimdiki Agent SDK) harika ama hâlâ Claude Code’a bağlılığı tamamen ayrılmış değil. Örneğin skills dosya sistemine doğrudan yerleştirilmeli
  OpenAI SDK, platformla güçlü entegrasyonu sayesinde panoda otomatik izleme ve değerlendirme sağlıyor ama üçüncü taraf modelleri entegre etmek zor
  Google Agent Kit’in hâlâ Typescript SDK’sı yok ve Mastra’da sunucu ayağa kaldırmak gerekiyor, bu da kullanışsız
  Şu anda SmythOS SDK’yı test ediyorum; model sağlayıcısı seçimi ve mimari tanımı konusunda yüksek özgürlük sunuyor
  Şu an kullandığınız yapının Agent → SubAgents → SubSubAgents şeklinde mi, yoksa Planner-Executor tipi mi olduğunu merak ediyorum

  • Çoğu SDK, temel özelliklerin ötesine geçince bir kâbusa dönüşüyor. Bu yüzden OpenRouter istemci kütüphanesini kullanıp kendim uyguladım
    Kod miktarı artıyor ama zihinsel model basit olduğu için anlaması çok daha kolay. ReAct yaklaşımıyla bir döngü kurup reasoning ve tool çağrılarını tekrar ediyorum
    Sonuçta SDK olmadan da agent handoff veya iş akışlarını doğrudan kendiniz uygulayabilirsiniz
  • ‘Sub-agent’ teriminin neredeyse işe yaramaz olduğunu düşünüyorum. Sonuçta bu sadece tool çağrılarının soyutlanmış hâli; ana döngünün dışında önemli olan yalnızca basit girdi/çıktı sözleşmesi
  • Claude Code’un yalnızca Anthropic modellerini desteklediği söylenmişti ama Claude Code Router kullanılırsa başka modeller de entegre edilebilir
  • Google ADK’nin Go sürümünü kullanıyorum; henüz olgun değil ama iş akışı kurgusu ve sağlayıcı uyumluluğu açısından memnunum
  • AWS’nin Strands Agents SDK’sını da kullandım; Bedrock olmadan da başlıca sağlayıcı API’lerini destekliyor ve API tasarımı çok esnek (AWS çalışanıyım ama bu kişisel görüşüm)

• Öğrendiğimiz bazı agent tasarım ilkelerini paylaşayım

  1. Çok fazla kod üretiliyorsa Claude Code / Agent SDK en verimli seçenek
  2. Sağlayıcı bağımlılığından daha büyük risk, ChatGPT’den daha kötü bir ürün yapmak
  3. Claude Code’un öz farkındalığı yüksek; kendisiyle ilgili sorulara anında ve doğru cevap veriyor
  4. Agent’a gerçek bir bilgisayar verirseniz çok daha güçlü oluyor. Biz e2b.dev kullanıyoruz ama Modal da iyi
     Bu arada şirketimiz Definite bir veri platformu ve Heroku gibi, bunu yapay zeka veri mühendisi işletiyor
  • Claude yaratıcı ama karmaşık kod tabanlarında uydurma yanıtlar ve reward hacking yapabiliyor. Böyle durumlarda Codex daha istikrarlı
  • Pek çok ürünün ChatGPT web’den daha düşük kaliteyle piyasaya çıkmasının sorun olduğunu düşünüyorum
  • Kendi agent sisteminizi kurmak yerine Claude Code gibi tamamlanmış araçlardan yararlanıp gerçek değer yaratmaya odaklanmak daha iyi olabilir
  • Elbette “her şeyi büyük teknoloji şirketlerine bırakalım” demek de riskli. Doğrudan inşa etme, öğrenme ve paylaşma süreci önemli. Ben de ADK ve VS Code uzantılarıyla hızla gelişiyorum

• Birkaç yıldır agent geliştiriyorum ve yaptığım en iyi şey kendi framework’ümü kurmak oldu
  Çeşitli açık kaynak soyutlama katmanları, SDK değiştikçe sürdürülemez hâle geliyor ve sonunda çöküyor

  • Ben de aynı fikirdeyim. Agent’ın özü yapılandırılmış girdi/çıktı, tool kaydı ve çağrı döngüsü, bir de agent’lar arası devretme
    PydanticAI tabanlı OpusAgents oluşturduk; MCP sunucularından daha basit ama aynı zamanda genişletilebilir bir açık kaynak framework
  • Yazının yazarı olarak katılıyorum. İlgili düşüncelerimi bu yazıda toparladım
  • Biz de müşteri destek chatbot’u geliştirirken mevcut yapı yerine chatroom tabanlı bir mimari benimsedik. Frontend sadece mesaj gönderiyor, backend’de ise işlevleri kademeli olarak genişletiyoruz
  • Yine de tamamen kendi framework’ünüzü yazmak büyük bir iş. Uzun vadede agent platformlarının oyun motorları gibi standartlaşması mümkün görünüyor

• Bugünlerde LangChain/RAG’nin ilk dönemlerindeki gibi aşırı soyutlama ve karmaşıklık yeniden yaşanıyor
  Sonuçta agent’ı basit bir REPL yapısı (Read, Eval, Print, Loop) olarak düşünmek yeterli.
  Bu fikirle doğrudan yazdığım hafif sürüm, ağır SDK’lardan çok daha kararlı çıktı

  • Ama gerçekten karmaşık kullanım senaryolarında özelleşmiş subagent’lar ve veri paylaşım yapıları gerekiyor. Sadece basit döngüyle sınır var

• Agent’ların testi ve değerlendirmesi (evals) en zor problem
  Harici sistemlerle değerlendirmek için girdi çok fazla ve çalışırken veriyi gözlemlemek gerekiyor
  Hangi yaklaşımın etkili olduğundan hâlâ emin değilim

  • Çoğu AI agent dağıtımının biçimsel testler olmadan, sadece ‘hisse’ dayanarak yapılıyor gibi görünmesi beni endişelendiriyor
  • Google’ın ADK değerlendirme belgelerine bakınca, her çalıştırmada sonuç değiştiği için geçti/kaldı ölçütü belirlemenin zor olduğu yazıyor. Sonunda değerlendirme için başka bir LLM kullanılıyor

• Agent geliştirmede en temel konularda bile net yönergeler eksik
  Örneğin fonksiyon tool’larının girdi/çıktı tiplerini işlerken, sayısal ID aktarımında serileştirme hataları veya hassasiyet kaybı yaşanıyor
  Sonunda bunu string’e çevirerek çözdüm
  OpenAI dokümantasyonu (bağlantı) ve Google ADK issue’suna (bağlantı) bakınca,
  “sonuç string olmalı” deniyor ama gerçek örnekler dict ya da sayı döndürüyor. Bu tür tutarsızlıklar kafa karıştırıyor

• Ben belirli bir agentic coding şirketinin ürününü kullanıyorum (adını vermeyeceğim)
  Model sürümleri, değerlendirmeler, sub-agent yönetimi, faturalama dâhil her şeyi üstleniyor ve ben doğrudan işime odaklanabiliyorum; bundan memnunum

  • O şirket muhtemelen Sourcegraph’un Amp’idir. İlk başta pürüzlüydü ama şimdi epey olgunlaştı

• Son iki ayda farklı işler için çeşitli agent’lar uyguladım. İlk başta Claude Code kullandım ama sağlayıcı bağımlılığı ve kullanım kısıtları yüzünden kendi runtime’ımı yazdım
  Şu anda sadece OpenAI destekleniyor ama Claude veya Gemini’yi de ekleyebilecek şekilde tasarladım
  Açık kaynak olarak yayımladım, bakabilirsiniz → agent-composer

• Benim ipucum basit: SDK kullanmayın, kendi while döngünüzü kurup JSON ile uğraşın
  Bağlam boyutunu ve hataları doğrudan kontrol etmeniz, gerçekten esnek agent’lar yapmak için şart