Kişisel Agent İşletim Sistemi

Neden Bu Yazı?

Nicolas'ın bu tweetini çok beğendiğimi ve bunu daha iyi anlamak için ve ne gibi kapılar açtığını görmek istediğim için bu blog'u yazdığımı en başta söylemek istiyorum. Tweet ilk bakışta bir model karşılaştırması gibi duruyor: Nicolas, her cuma Claude Code ile WhatsApp, SMS ve e-posta triage/cevaplama yaptığını; sonra Codex uygulamasını deneyince ciddi biçimde daha hızlı ve daha kaliteli sonuç aldığını anlatıyor. Ama makalesini okuyunca asıl konunun "hangi model daha iyi?"den çok daha büyük olduğunu görüyorsun.

Benim okuduğum ana fikir şu: kişisel agent dediğimiz şey, tek bir büyülü uygulama değil. Bir modelin, zaten kullandığın araçlara, dosyalara, iletişim kanallarına, tarayıcı oturumlarına ve kişisel kurallarına bağlanması. Model tek başına zeki olabilir; ama hayatına dokunabilmesi için elinin altında doğru araç yüzeyleri, düzenli veri, tekrarlanabilir beceriler ve doğru anda duran onay kapıları olması gerekiyor.

Tweetin Kıvılcımı: Model Mi, Düzenek Mi?

Tweetin ateşlediği soru basit: Nicolas neden Codex'i bu kadar etkileyici buldu? Onun tweetinde öne çıkan kısa ifade, Codex'in "aklını başından aldığı" duygusu. Fakat hemen ardından daha önemli bir ayrım geliyor: Nicolas, bunun yalnızca uygulama arayüzünden kaynaklanmadığını; model kalitesinin ve bağlayıcıların beraber işlediğini düşünüyor.

Burada iki katmanı ayırmak gerekiyor. Birinci katman model: uzun bağlamı tutabiliyor mu, karışık talimatlarda dağılmıyor mu, iletişim tonunu yakalayabiliyor mu, hangi e-postanın önemli olduğunu anlayabiliyor mu? İkinci katman harness veya işletim düzeneği: Gmail'e, WhatsApp'a, Google Drive'a, tarayıcıya, yerel dosyalara, kişisel beceri dosyalarına erişebiliyor mu? Günlük işte kazanç, bu iki katmanın çarpımından geliyor.

Yani "Codex daha iyi cevap verdi" cümlesi, aslında "Codex mevcut hayat verime bağlanıp işi baştan sona daha az sürtünmeyle taşıdı" anlamına geliyor. Kişisel agent'lar için benchmark değil, iş akışı uyumu belirleyici hale geliyor.

Ana Tez: Agent, Uygulamalar Arasında Hareket Edebildiğinde Değerli

Makalede en sevdiğim ayrım şu: kişisel hayat tek bir uygulamada yaşamıyor. WhatsApp başka yerde, Gmail başka yerde, takvim başka yerde, Drive belgeleri başka yerde, tarayıcı oturumları başka yerde, kişilerin telefon/e-posta kayıtları ayrı bir tabloda. İnsan olarak yorulduğumuz şey, çoğu zaman "zor düşünmek" değil; bu parçaları birbirine bağlamak.

MesajlarWhatsApp/Telegram gibi ilk sinyal kaynakları.

E-postaKişi, thread ve intro taslağı burada birleşir.

TakvimMesajdan aksiyona dönen tarih ve zaman bağlamı.

DriveMarkdown, CSV ve belgeler kaynak hakikati tutar.

KişilerTelefon, e-posta, LinkedIn gibi join noktaları.

Web formuAPI yoksa tarayıcı, kontrollü son çare olur.

AgentParçaları bağlar; insanın yerine nihai karar vermez.

Nicolas'ın kurduğu düzen bu nedenle bir sohbet aracı değil, küçük bir kişisel işletim sistemi gibi çalışıyor. Model, sonucu anlıyor; sonra gerekli kanallara bakıyor; eksik bilgiyi buluyor; taslak çıkarıyor; kritik noktada onay istiyor; sonra aksiyonu tamamlıyor. Makaledeki kısa formül bunu iyi özetliyor: Tools, data connectors, skills, and taste. Bence bu cümledeki en kritik kelime "taste": çünkü kişisel agent, yalnızca araç kullanmayı değil, senin nasıl çalışmak istediğini de öğrenmeli.

Bu harita makaledeki fikri tek bakışta gösteriyor: zeka yukarıda, ama işin gerçekleşmesi aşağıdaki katmanların birlikte çalışmasına bağlı. Model, yalnızca "iyi metin" üretmekle kalırsa hayatı değiştirmez. Model, mesaj okuyup kişi bulup belge güncelleyip tarayıcıda işlem yapıp doğru noktada senden onay alabiliyorsa gerçek operasyon başlar.

İki Gerçek İş Akışı: Değer Sıkıcı Yerde Başlıyor

Nicolas'ın makaledeki ilk örneği bir tanıştırma e-postası. Bir arkadaşı WhatsApp'tan yazıyor; Fransa'da işe alım yapan bir AI startup'ı için tanıdığı bir recruiter ile bağlantı kurmak istiyor. Normalde bunun içinde WhatsApp geçmişini okumak, Gmail'den recruiter e-postasını bulmak, startup'ın son haberlerini araştırmak, iki iş ilanı linkini eklemek, intro e-postasını yazmak, onaylamak, göndermek ve WhatsApp'tan "tamamlandı" diye dönmek var. Tek tek bakınca hiçbiri zor değil. Ama hepsi birlikte olduğunda dikkat yakıyor.

Makalenin altını çizdiği şey tam da bu: agent soru cevaplamıyor, küçük bir işi baştan sona yapıyor. İkinci örnek daha da sıradan: arabasının plakasını değiştiriyor. Fotoğrafları ve bağlamı Codex'e veriyor; agent Google Drive'daki araba bilgisi Markdown dosyasını güncelliyor, yeni plakayı ve kayıt notlarını ekliyor, VIN/sigorta/sahip/adres gibi mevcut bilgileri koruyor ve dosyayı geri yüklüyor. Sonra aynı bilginin FasTrak, park uygulaması, sigorta portalları veya başka web formlarında güncellenebileceğini söylüyor.

Bu iki örnek bana şunu düşündürdü: kişisel agent'ların ilk büyük kullanım alanı "dramatik otonomi" değil. Nicolas'ın kısa ifadesiyle Administrative continuity. Yani hayatındaki küçük idari sürekliliğin korunması. Bilgi bir yerde değişince diğer ilgili yerlerde de güncellenmesi. Bir mesaj geldiğinde ilgili e-postanın, kişinin, belgenin, takvimin birbirine bağlanması. İnsan zihnini yoran aradaki yapıştırıcının ortadan kalkması.

Burada dikkat edilmesi gereken pratik nokta şu: iş akışını agent'e vermek, "sen hallet" demek değildir. İyi tarif edilmiş bir sonuç, iyi sınırlar ve doğru araçlar gerekir. Tanıştırma e-postasında kaynak araştırması ve taslak üretimi agent'e verilir; sosyal nüans ve gönderme kararı insanda kalır. Plaka örneğinde dosya güncellemesi düşük riskli olabilir; resmi portal, ödeme veya hesap ayarı değişikliği daha yüksek onay ister.

Kaynak Düzeni: Agent İçin Okunabilir Hayat

Makalede bence en derin mimari karar Google Drive'ı kaynak hakikat noktası yapmak. Nicolas, Notion'ı insan çalışma alanı olarak sevdiğini ama agent'in ana veri kaynağı olarak fazla akışkan bulduğunu söylüyor: iç içe sayfalar, veritabanları, izinler, formatlama, backlink'ler, UI'a gömülü yapılar. Bunlar insan için güzel, model için sürtünmeli.

Bu yüzden değerli bilgiyi Drive'a, mümkün olduğunca Markdown ve CSV gibi düz metin formatlarına taşıyor. Neden? Çünkü agent bu formatları arayabilir, indirebilir, farkını görebilir, düzenleyebilir, tekrar yükleyebilir ve nereden aldığını gösterebilir. Bu bana çok kritik geliyor: kişisel bilgi yönetimi artık yalnızca "ben nereden bulurum?" sorusuyla değil, "agent'im bunu güvenle nasıl bulur ve değiştirir?" sorusuyla da tasarlanmalı.

Yani güzel bir UI'dan önce, kararlı dosya kimlikleri, arama yapılabilir metin, küçük tablolar, Markdown notları, CSV kişi listeleri ve komut satırından JSON dönen araçlar geliyor. Agent'ların sevdiği bilgi düzeni gösterişli değil, denetlenebilir ve fark alınabilir olandır.

Araç Hiyerarşisi: API, Dosya, Tarayıcı, Ekran

Nicolas'ın araç katmanı bilinçli biçimde sıkıcı: Google Workspace için CLI, WhatsApp için CLI, iMessage/SMS için yerel araç, web uygulamaları için tarayıcı otomasyonu, gerekirse AppleScript veya macOS UI otomasyonu. Buradaki sır, "her şeyi ekrandan tıklatmak" değil; en güvenilir yüzeyi seçmek.

Ben bunu dört basamaklı bir hiyerarşi olarak okuyorum:

Bu hiyerarşi kişisel agent tasarımında altın değerinde. Çünkü güvenilirlik, modelin zekasından çok aracın okunabilirliğine bağlı olabilir. Bir komutun çıktısını incelemek, aynı işi bir web sayfasında "şuraya tıkla, bekle, yeni butonu bul" diye yaptırmaktan daha sağlamdır. Agent'in güçlü olması için dünyaya açılan kapılarının makine tarafından okunabilir olması gerekir.

Beceriler: Her Seferinde Prompt Olmaktan Kurtulmak

Makalede "tools give the agent hands" fikri var: araçlar agent'e el verir. Ama tek başına el yetmez; elin neyi nasıl yapacağını bilmesi gerekir. Bu noktada skill dosyaları devreye giriyor. Bir skill, tekrar eden bir işi senin tarzına göre yapma kılavuzu. Inbox-zero örneğinde Nicolas; Gmail'den mesajları listeleme, otomatik arşivlenecekleri ayırma, önemli e-postaları alıntılayarak gösterme, cevap taslağı hazırlama, açık onay bekleme, orijinal thread'de gönderme, CC alıcılarını koruma, kısa yazma ve kendi adıyla imzalama gibi tercihleri prosedüre çeviriyor.

Bunun önemi çok büyük: skill yoksa sen her seferinde prompt oluyorsun. "Bunu gönderme", "CC'leri unutma", "gereksiz toplantı önerme", "cevabı kısa tut", "imzam şöyle olsun" gibi bütün kişisel tercihler hafızanda kalıyor ve her işte yeniden yükleniyor. Skill varsa, tercihlerin agent'in çalışma biçimine gömülüyor. Kişiselleşme, sevimli bir avatarla değil, tekrar eden hataların talimata dönüşmesiyle oluşuyor.

Seçenekleri işaretleyip reçeteyi oluştur.

Bu reçete basit görünebilir, ama ürünün kendisi burada. Çünkü kişisel agent kalitesi tek bir büyük prompt'la değil, küçük operasyon kurallarının zaman içinde birikmesiyle artıyor. Agent yanlış yaptığında, sadece o işi düzeltmiyorsun; prosedürü de güncelliyorsun. Böylece hata, bir sonraki çalışmada sistemin parçası haline gelmiş bir önleme dönüşüyor.

Onay Kapıları: Korkutucu Otonomi Yerine Kontrollü Yetki

Nicolas'ın makaledeki en sağlıklı çizgisi burada: tamamen arka planda, her şeyi kendi başına yapan bir agent istemiyor. İşin hazırlığını yapan, taslak çıkaran, doğru anda duran ve onay isteyen bir agent istiyor. Bu ayrım, kişisel agent'ları "faydalı" ile "korkutucu" arasında tutan şey.

Ben bu bölümü bir güven merdiveni gibi okuyorum. Okuma başka bir yetki seviyesi. Taslak hazırlama başka. Gönderme daha yüksek. Silme, ödeme, imza atma, hesap ayarı değiştirme bambaşka. Her aksiyonun aynı güven seviyesine konması kötü tasarım. Düşük riskli "Hugo'ya haftaya Seattle'da olduğumu söyle" mesajı doğrudan gidebilir; ama yatırımcı e-postası, müşteri cevabı veya sosyal nüansı olan bir tanıştırma önce taslak olarak gelmeli.

1OkuDüşük risk: tarama, özet, kaynak gösterme.

2TaslakOrta risk: cevap hazırlar, dışarı göndermez.

3GönderYüksek risk: sosyal nüans varsa açık onay ister.

4Kritik değişiklikSilme, ödeme, imza ve hesap ayarı adım adım onay ister.

Kurulum Reçetesi: Bunu Kendi Hayatına Nasıl Uygularsın?

Makaleden pratik bir reçete çıkarırsam, sıra şöyle olurdu:

1. Tek kaynak alanı seç. Google Drive, yerel klasör veya başka bir düzen olabilir. Önemli olan agent'in okuyup yazabileceği, sabit ve denetlenebilir olması.
2. Hayat verini düzleştir. Sağlık, araç, ev, seyahat, sigorta, iş, kişiler gibi alanları Markdown ve CSV dosyalarına taşı. Güzel görünmesi şart değil; aranabilir olması şart.
3. Kişiler tablosu yap. Nicolas'ın özellikle vurguladığı nokta bu: telefon, e-posta, LinkedIn gibi alanları olan bir contacts CSV, küçük iş akışlarında büyük kaldıraç sağlar.
4. Araç yüzeylerini kur. Gmail/Drive/Calendar, WhatsApp, Telegram, iMessage, tarayıcı ve yerel dosyalar için mümkün olan en güvenilir CLI/API bağlantılarını hazırla.
5. Tekrar eden işler için skill yaz. Inbox triage, tanıştırma e-postası, belge güncelleme, "ne kaçırdım?" taraması, seyahat hazırlığı gibi işler ayrı prosedürlere dönüşsün.
6. Yetki katmanlarını belirle. Okuma, taslak, gönderme, silme, ödeme, hesap ayarı değiştirme için ayrı onay kuralları koy.
7. Her hatayı talimata çevir. Agent bir tercihine ters davrandığında, sadece sonucu düzeltme; skill'e yeni kural ekle.

Bu reçetenin güzelliği, tüketici ürünü beklememesi. Bugün terminal, dosyalar, bağlayıcılar ve beceri dosyalarıyla başlayabiliyorsun. Çirkin olabilir; ama bilgisayar tarihindeki pek çok güçlü şey gibi önce çirkin ve etkili başlıyor, sonra arayüzleşiyor.

Ne Kapı Açıyor?

Nicolas'ın makalesinden benim çıkardığım büyük kapı şu: kişisel bilgisayar, uygulama çalıştırdığımız bir yer olmaktan, niyet beyan edip denetimli iş yaptırdığımız bir yere evriliyor. Eski modelde sen uygulamaları açar, arar, kopyalar, yapıştırır, yazar, gönderirdin. Yeni modelde niyeti söylersin; agent bağlamı toplar, taslağı hazırlar, gerekirse senden onay alır, yürütür ve raporlar.

Bu, kişisel üretkenlikte çok büyük bir kırılma. Çünkü çoğu insanın gününü yiyen şey, tek bir büyük problem değil. Beş uygulamada dağılmış onlarca küçük bağlam parçası. "Kim cevap bekliyor?", "hangi mesaj takvim olmalı?", "bu belge nerede?", "bu kişiye en son ne yazmıştık?", "bu bilgi hangi portallarda değişmeli?" gibi sorular. Nicolas'ın "ne kaçırdım?" iş akışı bu yüzden çok güçlü: agent birkaç saatte bir iletişim kanallarını ve ilgili belgeleri tarayıp önemli üç şeyi yüzeye çıkarabilir.

Ben bu yazıyı, tweetin verdiği heyecanı daha temelli görmek için yazdım. Sonuçta gördüğüm şey şu: mesele sadece Codex'in veya bir modelin iyi olması değil. Mesele, modelin araçlarla çevrili bir işletim katmanına dönüşmesi. Kişisel agent'ların ilk hali parlak bir mobil uygulama gibi değil; muhtemelen terminalde çalışan, dosyalarına ve hesaplarına kontrollü erişen, becerileri Markdown'da yaşayan, her hafta hayatından bir parçayı daha işletebilen bir yardımcı gibi görünecek.

Ve bu bana çok gerçek geliyor. Çünkü devrim, çoğu zaman en sıkıcı cümlede başlar: "Şunu benim için hallet, ama göndermeden önce göster."