AI Agent ≠ Model: OpenClaw + Bedrock ile Altyapı, Maliyet ve Hafıza Gerçekleri

Son zamanlarda popülerleşen ve hızlı büyüyen Openclaw’u Vinu Digital için deneyimledik. Başlangıç hedefimiz oldukça basitti; kendi AI destekli asistanımızı kurmak ve günlük işlerde kullanmak. Bunu ilk başta bir kişisel bilgisayar yerine boş bir bilgisayar ile Ollama kurduk. Tabii model seçimi sadece model seçimi değildi, memory, security, erişim kontrolü, loglama, maliyet yönetimi ve mimari entegrasyon sorularıyla birlikte geliyordu.

Bu rehberde, OpenClaw agent runtime'ı ve AWS Bedrock kombinasyonuyla yaşadığımız dönüşümü, otonom döngülerle ilgili acı gerçekleri ve kurumsal AI altyapısını yeniden tanımlayan "keşke baştan bilseydik" anlarımızı paylaşıyoruz.

Hızlı Yanıt: Model ve OpenClaw Runtime Farkı Nedir? Bir yapay zeka modeli (LLM) yalnızca çağrıldığında çalışır; bir yaşam döngüsü, hafızası veya otonomisi yoktur. OpenClaw ise modeli bir "agent"a dönüştüren çalışma zamanı ortamıdır. Olayları dinler, durumu yönetir, araçları kullanır ve döngüleri tetikler. Kısacası; model cevabı üretirken, runtime o cevabın ne zaman, nasıl ve neden üretileceğini belirleyen ana katmandır.

Neden OpenClaw? Neden Bedrock?

OpenClaw Nedir?

OpenClaw, AI agent'larının nasıl çalıştığını yeniden tasarlayan bir runtime ortamıdır. Bir LLM'nin tek bir call'da yanıt vermesinden farklı olarak, OpenClaw'da agent'lar zaman içinde gelişen bir döngü içinde çalışır:

Time → Events → Agents → State → Loop

Bu basit formül, agent'ların otonom gibi davranmasını sağlar. Ama burada kritik olan nokta: bu loop, belirli girdilere tepki verir. OpenClaw'ın temel girdileri şunlardır:

• Messages: Kullanıcı input'ları
• Heartbeats: Periyodik kontrol pulları
• Crons: Zamanlı görevler (task automation)
• Hooks: Event-driven tetikleyiciler
• Webhooks: Dış sistemlerden gelen bildirimler

Sektör uzmanı Claire Vo'nun da belirttiği gibi, "Bu yapay zekanın bir kalp atışı var ama beyni yok." Doğru tasarlanmış bir otonom agent, temelde basit bir mekanizmadır; ancak kurumsal ölçekte olağanüstü sonuçlar verir.

Model != Openclaw

Bunu basit bir cümle ile açıklayacak olursam; “Model yalnızca çağrıldığında çalışır ama bir yaşam döngüsü yoktur.”

OpenClaw ise modeli sürekli çalışan bir sistemin parçası haline getirir. Event’leri dinler, state tutar, memory yönetir, tool çağırır ve gerektiğinde tekrar kendini tetikler. Yani model sadece cevap üretirken, OpenClaw o cevabın ne zaman üretileceğini, hangi context ile çalışacağını ve sonrasında ne olacağını yöneten katmandır.

Neden Sadece Model Yetmez?

Bir bireysel kullanıcı olarak "Claude API çalıştırmak ve sonucu göstermek" belki yeterlidir. Ancak operasyonel ortamda, özellikle agent'lar söz konusu olduğunda, asıl zor olan taraf; agent’ın neye erişeceği, memory’nin nasıl yönetileceği, hangi event’in neyi tetikleyeceği, oluşan loop’ların nasıl kontrol edileceği ve tüm bunların maliyet ile gözlemlenebilirlik tarafına nasıl yansıyacağıydı.

1. Gerçek Zamanlı Veri ve Çevrimdışı Kısıtlamalar

Ollama Qwen 3.5 modeleri

Başta bilgisayarın RAM kapasıtesine uygun bazı Ollama modelleri kullandım. Ardında Openclaw ile bağlanıp yapılandırdım. Tabii bunun eksik yönü, internete erişip güncel veri ile çalışmaması. Günün sonunda Openclaw bu modeli kullanırken modelin context’ini önce RAM’a yüklediği için yavaş çalışabilir. Bu yüzden;

• Hava durumu verisi çeken bir cron job mu lazım? Çevrimdışı model başarısız olur.
• Gerçek zamanlı API yürütmesi mi gerekiyor? İzole ortamda imkansızdır.
• Binlerce eşzamanlı isteği yönetmek mi istiyorsunuz? Yerel RAM tüketimi ölçeklenmeyi imkansız hale getirir.

2. Gözlemlenebilirlik ve Güvenlik Açıkları

Agent tam olarak ne yaptı? Bir görev neden başarısız oldu? Hafızasında neler var?

Yapılan araştırmalarda (Cisco Security Research, IBM Analysis), AI agent'ların hafızalarında hassas bilgiler (API keys, user credentials) biriktiği ve bu verilerin güvenliksiz şekilde loglandığı ortaya çıkmıştır. OpenClaw'da bu sorunu çözmek için:

• Memory'ye nelerin yazılacağını kontrol etmemiz gerek
• Logging'i şifreli ve erişim kontrollü tutmamız gerek
• Periyodik olarak sensitive data'yı temizlememiz gerek

İşte bu noktada AWS Bedrock ve CloudWatch entegrasyonu devreye giriyor. Bu logları yönetilen bulut hizmetleri üzerinden güvenli bir şekilde takip etmek kurumsal bir zorunluluktur.

3. Maliyet Yönetimi

"Ne kadar harcadık?" sorusu, birkaç ay sonra çok önemli hale gelir.

Agent'lar, insan kullanıcısından farklı olarak, süreklı API çağrısı yaparlar. Heartbeat'ler, cron job'lar, hafıza okumaları—her şeyin bir maliyeti vardır. Vinu Digital’in sunduğu Bulut Çözümleri ve Maliyet Optimizasyonu stratejilerine göre, mesele sadece "daha ucuz" bir model seçmek değildir; asıl mesele tetikleyicileri optimize etmektir.

Maliyet Optimizasyonu: Asıl Problem Model Değil, Tetikleyiciler

OpenClaw + Bedrock tarafında fark ettiğimiz en önemli şey şuydu: maliyet sadece kullanıcı bir şey sorduğunda oluşmuyor. Heartbeat, cron, hook, memory okuma, tool çağrısı, uzun Notion sayfaları ve tekrar eden agent loop’ları da arka planda token tüketebiliyor.

Bu yüzden maliyet optimizasyonunu sadece “daha ucuz model seçelim” diye ele almadık. OpenClaw cost-token optimization yaklaşımına göre önce şu soruları sorduk:

• Agent gerçekten çalışmalı mı?
• Çalışıyorsa tüm context’e ihtiyacı var mı?
• Notion’dan her seferinde tüm sayfa/body okunmalı mı?
• Ön analiz lokal modelle yapılabilir mi?
• Bedrock sadece final üretimde kullanılabilir mi?

Çünkü uzun Notion sayfalarını veya takvimleri doğrudan modele vermek hem context’i şişiriyor hem de cache üzerinden bile maliyet çıkarabiliyor.

Uzun Notion içerikleri için ön özetleme ve sınıflandırmayı lokal Ollama tarafına aldık. Böylece Bedrock, ham veriyi temizlemek veya anlamlandırmak için değil, sadece final üretimi için kullanılıyor. Bu ayrım pratikte çok önemli oldu: lokal model hazırlık işini yapıyor, Bedrock ise kalite gereken son üretim aşamasında devreye giriyor.

Yani Notion otomasyonu artık geniş database taramasıyla değil, sadece kullanıcı tarafından verilen task title veya Notion link ile başlıyor.

4. Agent Loop Paradoksu

OpenClaw'ın en büyük gücü, agent'ların loop içinde "düşünüyor" gibi görünmesidir. Ancak bu loop, her iterasyonda bir LLM çağrısı anlamına gelir. Eğer loop 10 kere dönerse, 10 çağrı (ve 10 maliyet) bedeli ödersiniz.

Başta bu loop'un ne kadar sık çalıştığını kontrol etmemek , beklenmedi maliyetler oluşturabilir.

Agent loop konusu teoride basit görünüyor ama pratikte en tehlikeli yerlerden biri oldu.

Çünkü agent bazen gerçekten “takılıyor”. Aynı tool’u tekrar çağırıyor, aynı reasoning’i tekrar ediyor veya çözülmeyen bir task’ın etrafında dönmeye başlıyor.

Örneğin, iki farklı rolle agent’lar oluşturdum, her biri ayrı konudan sorumlu, Orchestrator agent, Event agent ve Marketing agent. Burada Orchestrator Telegram’dan gelen talimatı alıp uygun agent’i seçer ve cevabı Orchestrator agent’a geri verir, bu noktada cevap gelmeyince loop’a takılmış oluyor.

Neden AWS Bedrock Tercih Edildi?

AWS Bedrock'ı daha "iyi" modelleri olduğu için mi seçtik? Hayır. Üstün bir kontrol katmanı sunduğu için seçtik. Özellikle birden fazla agent’ın çalıştığı, cost takibinin önemli olduğu ve sistemi gözlemlemek istediğimiz noktalarda AWS tarafındaki IAM, CloudWatch ve billing entegrasyonu avantaj sağlayabilir.

Ama her senaryoda gerekli değil. Hızlı prototip, lokal kullanım veya tek kullanıcıya yönelik basit sistemlerde doğrudan Claude API ya da Ollama çok daha pratik olabiliyor.

AWS Ekosistemi ile Uyum

Şirket olarak halihazırda AWS kullandığımız için, model tarafında da AWS Bedrock’ı deneyimlemek istedik. Amaç sadece bir modeli çalıştırmak değildi; mevcut altyapının içine oturan, kontrol edilebilir bir çözümle ilerlemekti.

Verimlilik vs. Maliyet

Bir task'ı çözmek için agent'ın kaç loop çalıştırması gerekiyor?

Agent sistemlerinde maliyeti belirleyen şey sadece model seçimi değildir; agent’ın bir task için kaç kez modele gittiği de en az o kadar önemlidir.

Normal yaklaşımda agent her adımı ayrı loop’a böler: önce veriyi alır, sonra parse eder, sonra hesaplar, sonra karar verir, sonra alert ya da çıktı üretir. Bu basit görünen akış 4 ayrı LLM Model çağrısına dönüşebilir.

Daha verimli yaklaşımda agent önce planı netleştirir ve mümkün olan adımları tek kontrollü akışta toplar. Böylece veri okuma, hesaplama, karar ve çıktı üretimi daha az model çağrısıyla tamamlanır.

Buradaki önemli nokta şu: Tek çağrı bazen daha uzun prompt kullanabilir, ama gereksiz loop’ları azalttığı için toplam maliyet daha düşük ve daha öngörülebilir olur.

Bedrock bizim için “daha iyi model” değil, daha kontrollü bir kullanım katmanı oldu.

Bir Agent Yalnızca Altyapısı Kadar İyidir

OpenClaw + Bedrock kombinasyonu bize şunu net gösterdi: AI agent kurmak sadece model seçmek değildir. Model işin görünen kısmı; asıl sistem event’ler, memory, tool kullanımı, güvenlik, logging, maliyet kontrolü ve loop tasarımıyla birlikte anlam kazanıyor.

Bedrock bizim için “daha iyi model” değil, daha kontrollü bir çalışma katmanı oldu. IAM, CloudWatch, billing ve inference profile gibi parçalar sayesinde agent maliyetini ve davranışını daha yönetilebilir hale getirdi. Buna karşılık her iş için Bedrock kullanmak mantıklı değil. Heartbeat, özetleme, sınıflandırma ve Notion ön hazırlığı gibi düşük riskli işler lokal Ollama’ya alınabilir.

Bu deneyimden çıkan en net ders şu oldu:

AI agent’lar sadece kullandıkları LLM kadar iyi değildir; onları çalıştıran altyapı, context yönetimi ve tetikleyici tasarımı kadar iyidir.

Başta dikkat edilmesi gerekenler:

• Agent ne zaman çalışacak, açıkça belirlenmeli.
• Memory’ye ne yazılacağı kontrol edilmeli.
• Notion gibi uzun kaynaklar doğrudan modele verilmemeli.
• Fallback ve loop davranışı sınırlandırılmalı.
• Bedrock sadece gerçekten değer kattığı final üretimlerde kullanılmalı.
• Maliyet tracking en baştan kurulmalı.

OpenClaw güçlü bir runtime, Bedrock güçlü bir managed model katmanı. Ama ikisini verimli kullanmanın yolu, her şeyi modele göndermek değil; doğru bilgiyi, doğru zamanda, doğru modele göndermek.

Vinu Digital olarak, gerçek dijital dönüşümün güvenli, istikrarlı ve ölçeklenebilir yazılım çözümleri gerektirdiğini biliyoruz. Merkezi sistemler kuruyor veya karmaşık Cloud, Web3 ve AI mimarilerini entegre ediyor olun, başarınızı her zaman altyapınız belirler.

Deneyleri bırakıp kurumsal düzeyde otonom sistemler devreye almaya hazır mısınız? Maliyet ve güvenlik konusunda verileriniz kadar akıllı AI altyapıları oluşturmak için Vinu Digital’in bulut ve mimari uzmanlarıyla bugün iletişime geçin!