Yapay zekâ ajanlarıyla çalışan herkesin bir noktada yaşadığı o tuhaf gerilim var ya… Hani her şey yolunda gidiyor gibi görünür, sonra bir reboot ihtiyacı kapıyı çalar ve bütün düzen bir anda pamuk ipliğine bağlıymış gibi hissedersiniz. İşte OpenRig fikri biraz tam da oradan çıkıyor. Açık konuşayım, bu hikâyeyi okuyunca aklıma geçen yıl İstanbul’da bir startup ekibiyle yaptığım uzun sohbet geldi; üç ayrı agent, iki farklı görev zinciri. Üst üste açılmış terminal sekmeleri arasında kim ne yapıyordu, kim kimi besliyordu, insanın kafası çorba oluyordu.
İşin aslı şu: mesele sadece “çok ajan” çalıştırmak değil. Asıl dert, onları kaybetmeden yönetmek. Bir ajan kod yazıyor, biri PR inceliyor, biri araştırma yapıyor… sonra sistem büyüyor ve siz artık orkestra şefi gibi değil de sahnede koşuşturan teknik ekip gibi hissediyorsunuz. OpenRig’in anlattığı şey de bu karmaşaya bir tür anlık görüntü alma isteği — snapshot al, yeniden başlat, sonra aynı topolojiyi geri çağır. Kulağa basit geliyor ama pratikte, yani gerçekten üretimde iş gören sistemlerde, bayağı can kurtarıcı.
Ajanlar çoğalınca neden içimiz daralıyor?
Garip gelecek ama, Bir ajanla başlarsınız. Sonra ikinci gelir. Üçüncü derken olay artık küçük bir otomasyon denemesi olmaktan çıkar; kendi içinde bağlantıları olan, yaşayan bir yapıya dönüşür. Buradaki sıkıntı teknikten çok psikolojik bile olabilir. Çünkü elinizde çalışan bir düzen vardır. Ve onu bozmak istemezsiniz. Reboot? Güncelleme? Güvenlik yaması? Bunlar normalde rutin işlerdir ama ajanlar üretimde iş görüyorsa insanın eli frene gidiyor — bunu yaşadıysanız ne demek istediğimi çok iyi anlarsınız.
Peki neden?
Ben buna ilk kez 2023 sonbaharında, Kadıköy’de çalışan küçük bir ürün ekibinde denk geldim (en azından benim deneyimim böyle). Ekip lideri bana “Makineyi kapatmaya korkuyoruz” demişti; yarı şaka yarı ciddi. Çünkü ajanların oluşturduğu bağları elle yeniden kurmak zaman alıyordu, sinir alıyordu, bazen de tamamen imkânsız hale geliyordu. Tmux oturumları açık kalmıştı ama hangi oturumun hangi rolü taşıdığını kimse net hatırlamıyordu. Bir oturum QA notlarını tutuyor, öbürü mimari kararları taşıyor, üçüncüsü araştırma geçmişini saklıyordu… Ve biri unutulunca o bilgi fiilen kayboluyordu.
Asıl korku veri kaybı değil; bağlam kaybı. Ajan sistemlerinde bazen tek problem dosya değildir, ilişkilerin kendisidir.
Bu yüzden OpenRig’in doğuş hikâyesi bana çok tanıdık geldi. Çünkü burada çözülmeye çalışılan şey yalnızca otomasyon değil; hafızanın da korunması.
OpenRig neyi değiştiriyor?
Kaynak yazıda hoşuma giden en net fikir şu: eskiden terminalde tek tek oturum bakarken şimdi “hangi node nerede duruyor?” sorusuna daha düzenli cevap verilebiliyor. Yani ortada dağınık tmux pencereleri yerine isimlendirilmiş roller var gibi düşünün — orch-lead, dev-qa, review-r1… Bu yaklaşım küçük ekiplerde bile fark yaratır çünkü zihinsel yükü azaltır (buna dikkat edin). Basit ama güçlü bir fikir.
Bunu mutfak benzetmesiyle anlatayım. Eskiden tezgâhta beş ayrı tencere vardı ve hangisinde çorba kaynıyor bilmiyordunuz; şimdi etiketlenmiş kaplar var ve kapağı kaldırmadan önce ne olduğunu az çok biliyorsunuz. Çok süslü değil belki. Ama iş görüyor.
Geçen ay Levent’te görüştüğüm bir kurumsal Ar-Ge ekibi de benzer dertten yakındı. Onlarda problem biraz daha ağırdı çünkü sadece kod üreten ajanlar yoktu; güvenlik taraması yapanlar, dokümantasyon hazırlayanlar (inanın bana). Test senaryosu kuranlar da vardı. Sistem iyi çalışıyordu. Güzeldi. Ama devre dışı bırakıp geri getirmek adeta arkeolojik kazıya dönüyordu — üç saatlik iş, beş saatte bitiyordu ve kimse tam olarak neden böyle olduğunu açıklayamıyordu.
| Durum | Klasik yaklaşım | OpenRig tarzı yaklaşım |
|---|---|---|
| Ajan takibi | Tmux sekmelerinde elle | Daha görünür node mantığıyla |
| Yeniden başlatma | Kafa karıştırıcı ve riskli | Snapshot/restore fikriyle daha rahat |
| Bağlam koruma | Kısmen manuel | Daha yapılandırılmış |
| Ekip ölçeği büyüdükçe yönetim | Zorlaşır | Daha sürdürülebilir olur |
Neden bu kadar kritik bir boşluk vardı?
İnanın, Şimdi gelelim asıl meseleye. Neden böyle bir — itiraz edebilirsiniz tabi — araç zaten ortada yoktu? Çünkü çoğu kişi önce modeli iyileştirmeye odaklandı, operasyon katmanını biraz arka plana itti. Oysa gerçek hayatta acı veren yer tam orasıdır. Model iyi olsa da ajanların birbirine nasıl bağlandığı belirsizse üretimde huzur yoktur. Hiç. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Ve işler burada ilginçleşiyor. MCP ve A2A: 2025’te Çok Ajanlı Mimari Neden İkisine de Muhtaç? yazımızda bu konuya da değinmiştik.
Açıkçası ben de yıllarca bunu küçümsedim. “Biraz script yazarız geçer” diye düşünüyordum. Ama 2024 başında İzmir’deki bir SaaS projesinde test ederken gördüm ki mesele script ile kapanmıyor; hata anında geri dönüş planın yoksa gecenin üçünde bütün ekip Slack’te sessizce birbirine bakıyor oluyor… Ve o sessizliğin bedeli var. Apple’ın Yapmadığı MacBook Neo: Modla Gelen Sürpriz yazımızda bu konuya da değinmiştik.
Küçük startup için durum nasıl?
İtiraf edeyim, Küçük startup’ta iş biraz daha esnek ilerler; birkaç kişi aynı anda hem ürün hem altyapıyla uğraşır. Burada OpenRig benzeri yaklaşımın değeri hızlı toparlanmada ortaya çıkar. Reboot sonrası nelerin kaldığını bilmek güzel bir şeydir çünkü zaman para demektir — hele nakit akışı hassassa, her kayıp saat can yakar. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Büyük kurumda durum nasıl?
Enterprise tarafta ise oyun başka oynanır. Burada güvenlik politikaları devreye girer, audit log isterler, erişim kontrolü isterler, hatta bazen hangi ajanın hangi klasöre baktığını bile kayıt altına almak gerekir. Kağıt üstünde zahmetli görünür. Ama dürüst olayım… mecburiyet buradan geliyor. Ve o mecburiyet olmasa kimse bu detaylara girmezdi zaten. Huawei Pura 90: Tasarımda Sınırları Zorlayan Yeni Hamle yazımızda bu konuya da değinmiştik.
Bende bıraktığı his biraz şu oldu…
Ara sıra bazı ürünler vardır ya, ilk bakışta “tamam tamam, güzel” dersiniz ama asıl etkisini birkaç gün sonra anlarsınız. OpenRig fikri bende öyle çalıştı. Çünkü başlangıçta sadece gelişmiş terminal yönetimi gibi görünüyor; halbuki altında süreklilik problemi var. Derin bir problem.
Bununla birlikte her şey güllük gülistanlık değil. Bu tip sistemlerde standardizasyon arttıkça esneklik azalabilir; bazı geliştiriciler kendi akışlarına fazla müdahale edilmesinden hoşlanmaz — bunu da anlamak lazım, haksız değiller. Bir de şu var: snapshot alıp restore etmek kulağa harika geliyor. Yanlış zamanda alınmış snapshot size eksik bağlam döndürebilir. Yani sihir değil. Siz ne dersiniz? Düzgün disiplin istiyor.
# Basitleştirilmiş düşünce modeli
rig ps --nodes
orch-lead @auth-feats READY
dev-impl @auth-feats READY
dev-qa @auth-feats READY
rig up auth-feats
# restored from snapshot
# bağlantılar tekrar kuruldu
# iş devam ediyor
Neyse uzatmayayım, bu satırlar bana yıllardır gördüğüm şeyi hatırlattı: AI araçlarının değeri bazen modelden değil, operasyonel sürtünmeyi azaltmasından geliyor. İnsanlara gerçekten nefes aldıran kısım orası.
Aynı sorun başka alanlarda da karşımıza çıkıyor mu?
Bence, Evet, fazlasıyla. Kod tarafında yaşanan bağlam kaybını bugün belge üretiminde, veri analitiğinde, hatta güvenlik izleme akışlarında bile görüyoruz. Mesela A2A Neden Önemli: Çok Ajanlı Sistemler Altyapı Oluyor yazısında anlattığımız altyapısal dönüşüm tam olarak buna dokunuyor; yani çoklu ajanların “oyuncak” olmaktan çıkıp gerçek altyapıya dönüşmesi meselesi. Bu geçiş hiç de küçük bir şey değil.
Araya gireyim: Benzer şekilde Yazılımı Yapay Zekâya Bırakmak: Çok Ajanlı Sistemler yazısında da görmüştünüz — ajan tabanlı yazılım geliştirme artık deneysel bir şey değil, yavaş yavaş günlük iş akışının parçası haline geliyor. Bu ne anlama geliyor? Ve bu dönüşüm büyüdükçe, OpenRig gibi operasyonel çözümlerin önemi de katlanarak artıyor.
Hani, Sonuç olarak şunu söyleyebilirim: eğer birden fazla ajanla çalışıyorsanız. Henüz “bunları nasıl yönetirim?” sorusunu sormadıysanız, o soru yakında sizi bulacak. Garantiyle.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
