Ajan Çalışması Mesaiyi Aştığında: 18 Saatlik Ajanlar İçin Denetim Tasarımı

Öğleden sonra saat dörtte bir yeniden yapılandırma (refactor) başlatıp altıda dizüstü bilgisayarınızı kapatıyorsunuz. Ertesi sabah çalışma tamamlanmış, hâlâ devam ediyor ya da akşam 21:40'ta yanıtlayacak kimse olmadığı için bir soru sormak üzere durmuş olabilir. Üçü de birbirinden son derece farklı senaryolar; ancak dışarıdan bakıldığında bütün gece tamamen aynı görünüyorlardı.

Anthropic, Claude Opus 5.5'in 18 saat veya daha uzun süre görev başında kalabildiğini belirtiyor. Bunu mecazi değil, harfi harfine düşünün. Bir iş gününün bitiminde başlatılan bir çalışma, bir sonraki iş günü başladığında henüz sona ermiş olmuyor. Siz yokken tam on bir saattir kararlar almaya devam ediyor ve onu hatalı bir karar almaktan alıkoyan tek şey, çıkmadan önce belirlediğiniz yönergelerden ibaret.

Mesai saatinize sığan bir süreç anlık olarak denetlenir. Mesainizi aşan bir sürece ise sonradan geri dönülüp bakılır. Bunlar birbirinden tamamen farklı sistemlerdir ve çoğu ekip hâlâ ilkini kullanmaya devam ediyor.

Özetle (TL;DR)

Uzun süreli bir ajan (agent) çalışması, başında bir insanın bulunduğu süreyi aşan bir süreçtir; bu nedenle ajanın kendi başına alamadığı her kararın, kimsenin okumadığı bir terminal satırında beklemek yerine kaydedilmiş bir durum (state) olarak beklemesi gerekir. Bunun güvenli olabilmesi için üç koşulun sağlanması şarttır: ajanın siz yokken kendi uygulayabileceği bir durma koşulu, çalışıyor veya başarısız durumlardan açıkça ayırt edilebilen bir "insan yanıtı bekliyor" durumu ve sabahları sorumlu belirli bir kişinin açıp kontrol ettiği bir gelen kutusu (inbox). Ajanlar araştırır, yürütür, test eder ve raporlar. İnsanlar ise yön belirler, yetki verir ve sonucu onaylar. Sharkly, bu üç aşamayı da Task (Görev) üzerinde bir araya getirir.

22 Eylül 2026'da Neler Değişti?

İki yapay zekâ laboratuvarı aynı gün yeni modellerini yayımladı ve bu modeller hem çalışma sürelerini hem de maliyetleri kökten değiştirdi.

Anthropic; Opus 5.5'in Opus 5'e kıyasla %40 daha düşük maliyetle çalıştığını, yaklaşık %30 daha hızlı çıktı ürettiğini, 128k maksimum çıktı sınırına sahip olduğunu ve 18 saat ya da daha uzun süre görev başında kalabildiğini belirtiyor. OpenAI ise Sol ve Luna'nın, GPT-5.6'nın promosyon fiyatlarına göre bile %50 daha ucuz olduğunu ifade ediyor; burada "promosyon" OpenAI'ın kendi ifadesi olduğundan kıyaslama liste fiyatıyla değil, indirimli fiyat üzerinden yapılıyor. OpenAI ayrıca GPT-6 için önbelleğe alınmış girdi okumalarında %90 indirim sağlandığını ve akıl yürütme eforunu (reasoning effort) veya araç kullanılabilirliğini değiştirmenin artık önbelleği geçersiz kılmadığını bildiriyor; bu da tam olarak bütün gece süren çalışmalar için kritik bir avantaj sunuyor.

Kısacası, bir çalışma artık hem uzun soluklu hem de hesaplı olabiliyor. Ancak mesai saatleri bu hıza paralel olarak uzamadı; kimsenin ortaya çıkan sonuçları inceleme kapasitesi de artmadı.

İnceleme Süreci Tersine Dönüyor

Bir süreci bizzat izlerken onun hata yöneticisi (error handler) siz olursunuz. Yanlış bir dosyayı açtığını görür görmez müdahale edersiniz. Bu düzeltme hiçbir günlüğe (log) yansımaz, çünkü buna gerek kalmamıştır.

Gece boyunca ise bunların hiçbiri geçerli değildir. Yapacağınız her müdahale, ya ajanın zaten sahip olduğu bir kural olmak zorundadır ya da bir durma noktasıdır. Üçüncü bir seçenek yoktur. Uzun süreli bir ajan, gözetimsiz bırakılıp işini tamamlamış bir ajan demek değildir. Siz uyurken, bizzat sizin vermeniz gereken bir karara toslayacak olan bir ajandır. Sisteminizi işin bitişine göre değil, durma anlarına göre tasarlayın.

Anthropic ayrıca Opus 5.5'te sınırları aşma (boundary-circumvention) girişimlerinin başarı oranının %85 azaldığını aktarıyor. Düşük olasılıklar bir durma koşulu sayılmaz. Yönergelerinin dışına çıkması ne kadar zor olursa olsun, bir modelin gece saat 02:00'de takıldığı bir soruyu yöneltebileceği bir yere yine de ihtiyacı vardır.

Sağlanması Gereken Üç Temel Koşul

1. Ajanın siz yokken uygulayabileceği bir durma koşulu

Bu durum iki parçadan oluşur: platformun zorunlu kıldığı kesin bir üst sınır ve ajanın bizzat uygulayacağı yazılı koşullar.

Üst sınır bir yapılandırma konusudur. Bir Sharkly Agent'ı, her çalıştırma için ayrı ayrı değil, Agent düzeyinde belirlenen maksimum paralel Task sayısına ve Task başına bir zaman aşımı (timeout) süresine sahiptir. Bu zaman aşımı sınırını, gerçekleşmesini istediğiniz en uzun çalışmanın üstünde, ancak faturasını ödemeye razı olduğunuz en uzun çalışmanın altında tutun. Bu bir zaman planı değil, bir devre kesicidir (circuit breaker).

Yazılı koşullar ise ekiplerin genelde atladığı diğer yarıdır. Asla durmayan bir ajan çalışkan değil, sadece başıboştur.

Stop and wait for a human when:
- a change would touch a file outside the paths named in the Task;
- a check that passed at the start of the run still fails after two attempts;
- the Task description and the code disagree about intended behavior;
- you are about to run a command that writes outside the working directory.

When you stop, leave one comment: what you did, what you need, and the single
question that unblocks you. One question per stop.

Task net sınırları çizilmiş bir değişiklik içeriyorsa ve işin bittiğini ajana bildirebilecek testlere sahipse uzun bir zaman aşımı süresi kullanın. Görev keşif odaklıysa, kabul kriterleri hâlâ tartışmaya açık tek bir cümleden ibaretse ya da çalışma incelenmeden değiştirilmesini istemeyeceğiniz yerlere dokunabilecekse süreyi bir veya iki saatle sınırlı tutun. Onay kapıları (approval gates), bir ajanın kendinden emin olduğu durumlarda bile nerede durması gerektiğini belirler.

2. "Çalışıyor" durumundan farklı bir bekleme durumu

Sharkly'de Task yaşam döngüsü durumu ile Agent'ın çalışma durumu ayrı kayıtlardır. Agent; Working (Çalışıyor), Waiting for human reply (İnsan yanıtı bekliyor), Waiting for human review (İnsan incelemesi bekliyor) veya Error (Hata) durumundayken, bir Task arka planda In Progress (Devam Ediyor) olarak kalabilir. Alttaki çalıştırmanın da kendine ait durumları vardır: Queued, Dispatched, Waiting for local directory, Running, Completed, Failed, Canceled.

Bütün gece çalışan sekiz farklı göreviniz olana kadar bu ayrım kulağa önemsiz bir bürokrasi gibi gelebilir. Ancak bu ayrım olmazsa, sabah saat 09:00'da panoda hem tam kod düzenleme aşamasındaki bir ajan hem de tek bir yanıt beklediği için on bir saat önce durmuş bir ajan "In Progress" olarak görünür. Hangisinin ne durumda olduğunu anlamak için sekizini de tek tek açmak zorunda kalırsınız.

Çalıştırma günlüğü (execution log), ertesi sabah bir durma anını anlaşılır kılar: çalışmanın neden sıraya alındığı, ne zaman başlayıp bittiği, araç çağrıları ve Runtime olayları, tetikleyici kaynak ile hata veya iptal ayrıntıları. Ne istediğinizi hiç hatırlamıyorken sıfırdan açıp okuyacağınız şey tam olarak budur. Bu yapıyı kendiniz inşa edecekseniz neleri kaydetmeniz gerektiğini öğrenmek için durumlar, günlükler ve hata sinyalleri içeriğimize göz atabilirsiniz.

3. Belirli bir kişinin açtığı bir gelen kutusu

Sahipsiz bir bekleme durumu sonsuza kadar bekler. Gece yürütülen çalışmalar, gündüz yapılanların aksine sessizce başarısız olur; çünkü o sessizliği fark edecek kimse yoktur.

Sharkly'deki Inbox, görev aktivitelerinin kişisel bir kuyruğudur ve Primary (Birincil) sekmesi insan müdahalesi gerektiren bildirimleri tutar: yanıtınızı bekleyenler, incelemenizi bekleyenler, başarısız olan veya engellenen işler, doğrudan bahsetmeler ve size atanan görevler. Çalıştırma hataları ve engellenme sinyalleri tüm takipçilere değil, doğrudan görevin atandığı kişiye iletilir. Böylece gece saat 03:00'te başarısız olan bir çalışma, "herkese" gitmek (ki bu pratikte hiç kimseye gitmemek demektir) yerine doğrudan ilgili kişinin önüne düşer.

Sabahı kurtaran iki kayıtlı görünüm (View) vardır: inceleme bekleyen görevler ve Agent'lara atanmış olup şu anda engellenmiş görevler. Bunları kimin açıp kontrol edeceğini açıkça belirleyin. Çünkü "ekip" denen soyut kavram gelen kutusu kontrol etmez.

Sabah Kontrolü

İşlem sırası önemlidir ve bu sıra panonun sunduğu sıralama ile aynı değildir.

1. İlk olarak: İnsan yanıtı bekleyenler (Waiting for human reply). Bir soruyu yanıtlamak durmuş bir ajanı yeniden harekete geçirir; inceleme yapmak ise hiçbir şeyi başlatmaz. SH-312 akşam 21:40'tan beri bekliyorsa, tüm gün yapabileceğiniz en hızlı ve etkili hamle bir yorumla yanıt vermektir; bu da aynı Task üzerinde bir devam çalışmasını sıraya alır.
2. İkinci olarak: Başarısız ve engellenmiş olanlar (Failed and blocked). Yeniden denemeden önce çalıştırma günlüğünün başlığını ve teknik ayrıntılarını okuyun. Tek bir HTTP durumu yalnızca bir ipucudur, kesin bir teşhis değildir.
3. Üçüncü olarak: İnceleme bekleyenler (Waiting for review). Asıl kuyruk burasıdır ve çalışmalar ucuzladıkça büyüyen kuyruk da tam olarak budur.
4. Son olarak: Hâlâ çalışanlar (Still running). Devam etmesine izin verin veya iptal edin. İptal edilen bir çalıştırma kaldığı yerden devam etmez; ancak Task ve geçmişi korunur, bu yüzden gidişat yanlışsa tereddüt etmeden iptal edin. Tabii önce günlüğü okuyun.

Bu Yaklaşımın Çözmediği Şeyler

Daha uzun süreli çalışmalar inceleme yükünü azaltmaz; aksine yoğunlaştırır. 18 saatlik bir çalışma, koca bir gecenin kararlarını taşıyan tek bir sonuç döndürür ve bir insanın yine de bunu okuması, değerlendirmesi ve onaylaması gerekir. OpenAI'ın kendi araştırmacıları bu durumun nereye varacağını açıkça gösteriyor: Ortalama bir araştırmacı API fiyatlarıyla günde 600 dolardan fazla çıkarım (inference) maliyeti üretirken, 90. yüzdelik dilim günde 7.000 doları aşıyor; ancak üretilen çıktıları inceleyecek insan sayısı sabit kalıyor. OpenAI bu verileri yayımladığında matematiksel hesabını yapmıştık ve bu yeni duyuruların hiçbiri paydadaki bu gerçeği değiştirmiyor.

Daha ucuz ve daha uzun çalışmalar, daha az karar anlamına gelmez; yalnızca daha fazla paralel deneme yapabilmenizi sağlar. Darboğaz insan incelemesidir ve fiyatların düşmesi işleri düzeltmeden önce bu darboğazı daha da derinleştirir. Otomasyon, ekip kararının zorunlu olduğu noktada durur ve durduğunda eksiksiz bir bağlam ve incelenebilir kanıtlarla birlikte bir teslimat sunar.

Sıkça Sorulan Sorular

18 saatlik bir model için Task başına zaman aşımı süresi ne kadar olmalıdır? Hedeflediğiniz çalışma süresinden daha uzun, ancak pişman olacağınız süreden daha kısa olmalıdır. Sıradan işler için birkaç saatle başlayın ve gerçekten bütün bir geceye ihtiyaç duyan Task'lar için Agent bazında bu süreyi artırın. Zaman aşımı, sonsuz döngüye giren bir çalışmayı sonlandırmaya yarar; kaliteli bir işin ne kadar süreceğini belirlemez.

Ajanın gece 02:00'de sorduğu bir soruya ne olur? Bu soru, terminalin kaydırma geçmişinde kaybolup giden bir satır olmak yerine, bir "insan yanıtı bekliyor" durumuna ve atanan kişinin gelen kutusunda (Inbox) bir öğeye dönüşmelidir. Mevcut altyapınız bunu gözden kaçırıyorsa, zaman aşımı sürelerini uzatmadan önce bu açığı kapatın.

Gelinen Nokta

Hiçbir sağlayıcı işin bu kritik kısmını hazır olarak sunmuyor; çünkü asıl önemli olan, durma noktasının nereye düşeceği ve sabah süreci kimin devralacağıdır. Bu sorun Claude Code, Codex ve diğer tüm araçlar için tamamen aynıdır. Tam da bu nedenle sahiplik tek bir sağlayıcının oturumunda değil, görev (task) düzeyinde olmalıdır.

Halihazırda geceleri ajan çalıştırıyorsanız, testi oldukça basittir: Sabah saat 09:00'da panonuzu açın ve düşünen bir ajan ile dünden beri yanıt bekleyen bir ajanı birbirinden ayırt edip edemediğinize bakın. Ayırt edemiyorsa düzeltmeniz gereken ilk şey budur ve Sharkly'nin konumlandığı katman da tam burasıdır: Task; talepten yayına kadar hedefi, çalışma durumunu, engeli, sonucu ve insanın verdiği nihai kararı bünyesinde barındırır.