Aynı Sabah Brifingi, İki Ayrı Sistem: Cowork Schedule mı, Hermes Cron mu?

Her sabah 08.30’da önünüze tek sayfalık bir brifing gelsin: bugünkü toplantılar, yanıt bekleyen önemli mesajlar ve işinizi etkileyebilecek birkaç haber. İlk bakışta bu, yapay zekâya verilebilecek en kolay görevlerden biri gibi görünür. Kaynakları oku, özetle ve gönder.

Fakat düzenli bir brifingin değeri, ilk başarılı denemede değil; sizin bilgisayarınız kapalıyken, takvim bağlantısı koptuğunda, okunmamış mesaj bulunmadığında veya talimatı değiştirmek istediğinizde ortaya çıkar. Bir sistem güzel bir özet üretebilir ama saatinde çalışmayabilir. Diğeri düzenli çalışabilir ama boş kaynağı gerçek bir sessizlik sanabilir. Üçüncü bir sorun daha vardır: Brifingi üretmek için kurduğunuz otomasyonu ayakta tutmaya, brifingi okumaktan daha fazla zaman harcayabilirsiniz.

Bu yazıda Claude Cowork’un zamanlanmış görevleri ile Hermes Agent’ın cron yaklaşımını aynı gündelik iş üzerinden karşılaştıracağız. Amacımız özellik saymak değil. İki sisteme de aynı başarı sözleşmesini verecek; çalışma yeri, kaynak erişimi, teslimat, hata görünürlüğü, bakım ve risk açısından neyi üstlendiğimizi göreceğiz. Böylece “Hangisi daha güçlü?” yerine daha kullanışlı bir soruya ulaşacağız: Hangisi benim koşullarımda daha az insan emeğiyle kabul edilebilir brifing üretiyor?

Önce brifingi değil, başarı sözleşmesini tasarlayın

“Her sabah bana gündemi özetle” bir niyettir; çalıştırılabilir bir görev tanımı değildir. Sistem hangi takvimi okuyacak? “Önemli mesaj” nasıl ayırt edilecek? Haber bulunamazsa ne yazacak? Kaynaklardan biri açılamazsa sessizce devam mı edecek, görevi başarısız mı sayacak? Brifing saat 08.37’de gelirse kabul edilecek mi?

Bu soruları araç seçmeden önce yanıtlamazsak iki sistemi adil biçimde karşılaştıramayız. Üstelik akıcı bir metni, doğru bir brifing sanma riskimiz artar. Doldurulmuş bir örnek üzerinden ilerleyelim.

Deniz’in sabah brifingi sözleşmesi

Buradaki en önemli ayrım, boş kaynak ile okunamayan kaynak arasındadır. Takvimde toplantı bulunmaması iyi haber olabilir. Takvim bağlantısının kopması ise bilinmeyen bir durumdur. İkisini de boş liste olarak gösteren bir otomasyon sakin görünür ama güvenilir değildir.

Brifing talimatının özünü şu şekilde yazabiliriz:

Hafta içi her sabah 08.30'da bugünün brifingini hazırla.

1. İş takviminde bugün 00.00–23.59 arasındaki iptal edilmemiş etkinlikleri sırala.
2. Son 24 saatteki okunmamış iş mesajlarından yanıt veya karar gerektiren en fazla beşini seç.
3. Sektörümle doğrudan ilgili en fazla üç güncel haberi, kaynak bağlantılarıyla özetle.
4. Çıktıyı “Bugün”, “Yanıt bekleyenler” ve “İzlemeye değer” bölümlerine ayır.
5. Bir kaynakta sonuç yoksa “sonuç bulunamadı” yaz. Kaynağa erişemiyorsan bunu hata olarak belirt; içerik tahmin etme.
6. Brifingi tek ekranlık Türkçe metin olarak teslim et.

Bu talimat tek başına yeterli değildir; fakat sistemler arasında taşınabilecek ortak bir başlangıç noktası sağlar.

Cowork Schedule: altyapıyı devretmenin karşılığı

28 Temmuz 2026 tarihli resmî bilgilere göre Cowork, ücretli Claude planlarında web, masaüstü ve mobil yüzeylerden kullanılabilen yönetilen bir çalışma ortamıdır. Zamanlanmış görevler uzak oturumlarda çalışabildiği için uygun kaynaklarla kurulan bir sabah brifingi, kullanıcının kişisel cihazı kapalıyken de üretilebilir. Cowork’un temel vaadi burada belirginleşir: Zamanlayıcıyı, çalışma ortamını ve oturumun yürütülmesini tek tek sizin işletmeniz gerekmez.

Deniz’in kurulumu üç parçadan oluşur:

1. Brifingin kullanacağı takvim ve mesaj kaynaklarını mevcut bağlayıcılar üzerinden yetkilendirir.
2. Yukarıdaki görev talimatını Cowork’ta oluşturur ve hafta içi 08.30 için tekrar eden çalışma tanımlar.
3. İlk birkaç çalışmada sonuçları kabul sözleşmesine göre kontrol eder; ardından yalnız istisnaları izler.

Bu yaklaşımın gücü, “cron süreci çalışıyor mu?” sorusunu gündelik kullanıcının önünden büyük ölçüde kaldırmasıdır. Fakat yönetilen hizmet, her kaynağın otomatik olarak uzaktan erişilebilir olduğu anlamına gelmez. Brifing masaüstünüzdeki yerel bir dosyaya, yalnız bilgisayarınızda açık olan bir uygulamaya veya masaüstü aracılığıyla sağlanan tarayıcı oturumuna bağımlıysa cihaz kapalıyken aynı erişim garanti edilemez. Uzak çalışacak görevlerin kaynaklarını da uzaktan erişilebilir tasarlamak gerekir.

Karar kuralı: “Cihazım kapalıyken çalışsın” diyorsanız yalnız zamanlayıcının değil, görevin bütün kaynak zincirinin uzaktan erişilebilir olup olmadığını kontrol edin.

Cowork’ta riskin önemli bölümü bağlantı yetkilerinde toplanır. Bir sabah özeti için yalnızca takvimi ve belirli mesaj alanlarını okumak yeterliyse, daha geniş erişim vermek kolaylık değil gereksiz saldırı yüzeyidir. İlk denemede otomatik gönderim veya başka sistemlerde değişiklik yapma yetkisi de gerekmez. Brifing salt okunur başlayabilir.

Talimat değişikliği ise görece merkezîdir. Deniz haber bölümünü kaldırıp yerine “bugün hazırlanılması gereken toplantılar” bölümü eklemek isterse zamanlanmış görevin talimatını günceller. Yine de değişiklikten sonraki ilk sonucu yeni sürüm gibi değerlendirmelidir. Küçük bir cümle değişikliği, bölüm sırasını veya seçme ölçütünü beklenmedik biçimde etkileyebilir.

Hermes Cron: kontrolü almanın karşılığı

Hermes Agent farklı bir anlaşma sunar. Masaüstü kurucusu ve kolaylaştırılmış OAuth akışları başlangıç yükünü azaltabilse de model sağlayıcısı, çalışacak makine, mesajlaşma geçidi ve güvenlik sınırları konusunda daha fazla karar kullanıcıya kalır. Zamanlanmış görevler doğal dille tanımlanabilir; sonuçlar yapılandırmaya bağlı olarak Telegram, WhatsApp, e-posta veya yerel dosya gibi kanallara yönlendirilebilir.

Deniz’in Hermes kurulumu şu zincire dönüşür:

1. Hermes’i sürekli çalışabilecek bir makineye kurar. Bu kişisel bilgisayarsa bilgisayarın 08.30’da açık ve internete bağlı olması gerekir; sürekli açık başka bir makine kullanılıyorsa onun bakımı da sistemin parçasıdır.
2. Model sağlayıcısını ve gerekli kimlik doğrulama yöntemini yapılandırır.
3. Takvim, mesaj ve haber kaynaklarına erişimin hangi araçlarla sağlanacağını belirler.
4. Tercih ettiği teslimat kanalı için messaging gateway bağlantısını kurar.
5. Görevi cron ile hafta içi 08.30’a zamanlar; saat dilimini açıkça doğrular.
6. Çalışma günlüklerini ve hata bildirimini izleyebileceği bir yol oluşturur.

Bu daha uzun liste yalnızca kurulum zorluğu değildir; aynı zamanda esneklik haritasıdır. Brifingi zaten her sabah açılan bir Telegram konuşmasına göndermek, bir kopyasını yerel arşive yazmak veya farklı bir model sağlayıcısını denemek isteyebilirsiniz. Hermes bu parçaları sizin seçmenize izin verir. Ancak her seçim, çalışması ve korunması gereken yeni bir birleşim noktasıdır.

Hermes’te “bilgisayar uyurken ne olur?” sorusunun cevabı çalışma yerine bağlıdır. Ajan kişisel bilgisayarda çalışıyorsa uyuyan veya kapalı makine cron görevini yürütemez. Her zaman açık bir sunucu ya da başka bir cihaz bu sorunu çözebilir; fakat güncelleme, ağ erişimi, günlükler, sırların saklanması ve maliyet artık sizin işletme sorumluluğunuzdadır. Burada özgürlük ile bakım aynı pakette gelir.

Teslimat kanalı da benzer bir değiş tokuş taşır. Mesajlaşma uygulamasında brifing görmek sürtünmeyi azaltır. Buna karşılık gateway kimlik bilgileri, yanlış sohbet hedefi ve hassas takvim içeriğinin üçüncü bir kanala taşınması yeni riskler yaratır. İlk pilotta brifingi gerçek müşteri veya ekip gruplarına değil, yalnız Deniz’in eriştiği özel bir test kanalına göndermek daha güvenlidir.

İlk başarıyı değil, bozulma biçimini sınayın

İki sistem de normal bir günde güzel bir brifing üretebilir. Ayırt edici test, kaynakları kasıtlı ve güvenli biçimde zorlamaktır. Gerçek bağlantıları bozmak yerine bir test hesabı veya geri alınabilir pilot kullanın.

Test 1: Takvim bağlantısı koparsa

Takvim yetkisini test hesabında geçici olarak kaldırın. Beklenen sonuç, toplantı bölümünün boş görünmesi değildir. Sistem “Takvim okunamadı” demeli; diğer erişilebilir bölümleri üretebilir ama brifingi eksiksizmiş gibi sunmamalıdır.

Cowork’ta bakılacak nokta, uzak oturum sonucunun bağlantı hatasını ne kadar görünür kıldığıdır. Hermes’te ise hem ajan çıktısını hem de gateway ve görev günlüklerini kontrol etmek gerekir. Kullanıcıya temiz bir hata mesajı gelmesi, altyapı günlüğünde hata bulunmasından daha değerlidir; çünkü Deniz sabahları sunucu günlüğü okumayacaktır.

Test 2: Gerçekten mesaj yoksa

Test gelen kutusunda son 24 saate ait okunmamış mesaj bırakmayın. Doğru çıktı, “Yanıt gerektiren okunmamış mesaj bulunamadı” cümlesidir. Sistem eski mesajları doldurmak için tarih aralığını genişletmemeli, okunmuş mesajları yeniden gündeme getirmemeli veya sessizce bölümü kaldırmamalıdır.

Bu test, modelin boşluğu doldurma eğilimini sınar. Ayrıca bağlantının çalıştığını gösterecek bir kanıt ister. Mümkünse brifing “Kaynak kontrol edildi: 08.28” gibi kısa bir zaman damgası taşımalıdır.

Test 3: Makine kapalıysa

Cowork tarafında görev yalnız uzaktan erişilebilir bağlayıcılara dayanıyorsa kişisel cihaz kapalıyken brifingin gelip gelmediğini sınayın. Yerel dosya veya masaüstü oturumu gerekiyorsa bunu ayrı bir bağımlılık olarak işaretleyin.

Hermes kişisel makinede çalışıyorsa aynı testin beklenen sonucu kaçırılmış çalışmadır. Sonra daha önemli soruyu sorun: Makine yeniden açılınca görev telafi ediliyor mu, atlanmış mı sayılıyor, yoksa çift brifing riski mi doğuyor? Bu davranışı varsaymayın; kullandığınız kurulumda gözlemleyip kabul sözleşmesine yazın. Brifing 10.15’te üretilecekse başlığında geciktiği açıkça görünmelidir.

Test 4: Teslimat kanalı çalışmıyorsa

Görev başarıyla tamamlanıp sonuç gönderilemeyebilir. Bu, üretim başarısı değil teslimat başarısızlığıdır. Hermes’te test kanalının bağlantısını kontrollü biçimde keserek yeniden deneme ve hata görünürlüğünü gözlemleyin. Cowork’ta ise kullanıcının sonucu hangi yüzeyden göreceğini ve kaçırılan görev için bildirim alıp almadığını kendi planı ve platformunda doğrulayın.

Her iki tarafta da ortak kabul kuralı şudur: Sonuç kullanıcının beklediği yerde görünmediyse görev tamamlanmış sayılmaz.

Karşılaştırma: özellik değil, sorumluluk dağılımı

Gerçek maliyet: kabul edilen brifing başına insan emeği

Yalnız abonelik ücretine veya model kullanım bedeline bakmak yanıltıcıdır. Bir sistem ucuz çalışıp her sabah kontrol gerektiriyorsa, insan zamanı toplam maliyeti büyütür. Karşılaştırma için şu basit ölçüyü kullanabiliriz:

Kabul edilen brifing başına insan emeği =
(kurulum dakikası + pilot dönemi boyunca bakım ve düzeltme dakikası)
/ kabul edilen brifing sayısı

Rakamları ürünlere mal edilmiş gerçek performans verisi olarak değil, yöntemi göstermek için hazırlanmış örnek olarak düşünün. Deniz iki haftalık pilotta her sistemden 10 brifing bekliyor:

Bu örnekte Hermes bir brifing daha fazla kabul edilse bile Deniz için Cowork daha düşük insan emeğiyle sonuç üretir. Ancak Hermes kurulumu ilerleyen aylarda az bakım ister ve seçilen teslimat kanalı her gün zaman kazandırırsa tablo değişebilir. Bu nedenle ilk haftanın kurulum süresini sonsuza kadar genellemek yerine ölçümü dört hafta sonra yeniden yapmak gerekir.

Parasal karşılaştırmaya da aynı bütünlükle bakın: Cowork için gerekli planın maliyeti; Hermes için model kullanımı, sürekli açık makine veya sunucu, mesajlaşma altyapısı ve bakım zamanı birlikte değerlendirilmelidir. Kesin tutarlar planlara, sağlayıcıya ve kullanıma göre değişebileceğinden karar gününde güncel fiyatları ayrıca kontrol edin.

Hangi durumda hangisini seçmeli?

Cowork’u seçmeye daha yakınsınız eğer asıl isteğiniz bilgisayar kapalıyken de çalışan, yönetilen ve az bakım gerektiren bir rutinse; kaynaklarınız desteklenen uzaktan bağlantılarla erişilebiliyorsa; sonuçları Claude’un çalışma yüzeylerinde görmek sizin için yeterliyse ve altyapı bileşenleriyle uğraşmak istemiyorsanız.

Hermes’i seçmeye daha yakınsınız eğer brifingi belirli bir mesajlaşma kanalına veya yerel dosyaya teslim etmek kritikse; model sağlayıcısını ve çalışma makinesini seçmek istiyorsanız; özel araçlar eklemeniz gerekiyorsa ve güvenlik, günlük, güncelleme ile kesintisiz çalışma sorumluluğunu üstlenebiliyorsanız.

Kararsızsanız iki sistemi de bütün hesabınızla kurmayın. Beş iş günlük küçük bir pilot yapın:

1. Salt okunur bir test takvimi ve test mesaj kutusu oluşturun.
2. Aynı talimatı ve aynı saat dilimini iki sisteme verin.
3. Beş günde en az bir boş kaynak ve bir bağlantı hatası senaryosu uygulayın.
4. Her brifingi “kabul”, “küçük düzeltme” veya “ret” olarak işaretleyin.
5. Kurulum, kontrol ve düzeltme dakikalarını kaydedin.
6. En çok özellik sunanı değil, kabul edilen sonuç başına daha az insan emeği isteyen ve sürdürülebilir biçimde işletilebilen sistemi seçin.

Sonuç: otomasyonun görünmeyen kısmını seçiyorsunuz

Cowork Schedule ile Hermes Cron arasındaki fark, aynı metni hangi modelin daha güzel özetlediğinden büyük ölçüde daha derindir. Cowork’ta çalışma ortamının önemli bir bölümünü yönetilen hizmete devredersiniz; buna karşılık desteklenen bağlantılar ve ürünün sınırları içinde kalırsınız. Hermes’te çalışma yeri, model ve teslimat kanalı üzerinde daha fazla kontrol kazanırsınız; bunun bedeli, daha uzun bir sorumluluk zinciridir.

Sabah brifingi bu farkı görünür kılan küçük ama iyi bir deneydir. Çünkü her gün tekrar eder, gecikme hemen fark edilir ve boş veri ile erişim hatası kolayca karışır. İlk adımınız araç kurmak değil, bu yazıdaki gibi kaynak, zaman, biçim, teslimat ve başarısızlık koşullarını içeren tek sayfalık bir kabul sözleşmesi hazırlamak olsun. Sonra iki haftalık pilotta yalnız “çalıştı mı?” diye bakmayın. Kaç kez kabul edildi, hata ne kadar görünürdü ve sizin kaç dakikanızı aldı? Kararı bu üç cevap versin.

Kaynaklar

• Get started with Claude Cowork
• Use Claude Cowork on web, desktop, and mobile
• Schedule recurring tasks in Claude Cowork
• Let Claude use your computer in Cowork
• Claude Cowork architecture overview
• Use Claude Cowork safely
• Hermes Agent Documentation
• Hermes Agent Quickstart
• Hermes Agent Messaging Gateway
• Hermes Agent Scheduled Tasks (Cron)
• Hermes Agent Security