Nisan ayında GitHub trending listesinde sürekli karşımıza çıkan bir repo vardı: paperclipai/paperclip. 46 bin star, 7 bin fork, 1800'ün üzerinde commit, 1000'e yakın açık PR. Slogan ise ilk anda sinir eden türdendi: "Open-source orchestration for zero-human companies." Sıfır-insanlı şirketler. Piyasa bu tür cümleleri üç yıldır duyuyor ve çoğu zaman arkası boş çıkıyor.
Sonra repo'yu açıp dokümantasyonu dikkatle okuduk, birkaç saat yapısal olarak inceledik. Vardığımız yer şu: slogan iddialı, ürün iddialı değil. Ama Paperclip'i ilginç kılan da tam burası. Başka projeler "otonom AI şirketi" derken karmaşık graph'lar ve sonsuz loop'lar kurarken, Paperclip bunları reddediyor ve bambaşka bir kategoriye oynuyor. Oynadığı kategori de, dürüst olmak gerekirse, son bir yıldır agent ekosisteminin ihtiyacı olan şey.
Bu yazı Paperclip'i övmek için değil. Paperclip'in hangi problemi doğru teşhis ettiğini, bu teşhisi hangi mimari kararlarla inşa ettiğini, ve bu kararların neden sizin kendi agent mimariniz için de önemli olduğunu anlatmak için.
Problem: Yirmi terminal açık ve hiçbirinin ne yaptığını hatırlamıyorsunuz
Paperclip'in çözdüğünü iddia ettiği ilk problem README'de açıkça yazılı: "Yirmi tane Claude Code tab'ınız açık ve hangisinin ne yaptığını takip edemiyorsunuz. Reboot ettiğinizde her şey uçuyor."
Bu cümlenin ne kadar gerçek bir problem olduğunu ancak agent'larla haftada 30 saat çalışan biri bilir. NNF olarak biliyoruz çünkü günlük pratiğimiz bu. Bir agent bir repo'da feature yazıyor, öteki doküman okuyor, başka biri test koşuyor, bir dördüncüsü müşteri e-postalarına bakıyor. Her birinin kendine ait bir context'i var, her biri farklı bir prompt'la başlatıldı, ve hepsini tek tek zihinde tutmak zorunda kalıyorsunuz. Makine yeniden başladığında context'in yarısı gidiyor. Hangi tab hangi iş içindi, hangi prompt'u nasıl kurmuştunuz — üç gün sonra hiçbirini hatırlamıyorsunuz.
Bu problem Paperclip'in yaratıcılarının çıkış noktası. Ve önemli olan şu: problemi "agent'lar yeterince akıllı değil" diye teşhis etmiyorlar. Problemi orchestration layer'ın olmaması olarak teşhis ediyorlar. Bu küçük bir fark gibi görünüyor ama kritik. Çünkü ilk teşhis sizi modellerin daha iyi olmasını beklemeye iter. İkincisi ise sizi şunu inşa etmeye iter: agent'ların kim olduğunu, ne iş yaptığını, ne harcadığını, neye karşı hesap verdiğini hatırlayan kalıcı bir sistem.
Paperclip bu ikinci yolu seçiyor.
Çözüm: Agent'ı kod parçası değil, "çalışan" olarak modelle
Paperclip'in en belirleyici kararı, agent'ları teknik bir primitif olarak değil organizasyonel bir primitif olarak modellemesi. Bu fark neredeyse her şeyi açıklıyor.
LangGraph'ta bir agent bir node'dur, bir state machine'in parçasıdır. CrewAI'da bir agent bir Python class'ıdır, task aldığında execute eder. AutoGen'de bir agent bir conversation participant'ıdır. Paperclip'te ise bir agent bir rol, bir yönetici, bir iş tanımı, bir aylık bütçe, bir ticket queue ve kalıcı bir state ile tanımlanır. Yani bir çalışandır. Org chart'ta bir yeri vardır. Raporladığı biri vardır (varsayılan olarak siz, yani "yönetim kurulu"). Harcayabileceği bir limit vardır.
Bu metafor başlangıçta biraz lüzumsuz süs gibi görünüyor ama altı boş değil. Çünkü çalışan metaforunu ciddiye aldığınızda birden fazla şey aynı anda çözülmeye başlıyor. Accountability (kim ne yaptı?), observability (dün ne oldu?), cost control (kim ne harcadı?), delegation (bu işi kime atayayım?), continuity (bu agent üç ay önce ne düşünüyordu?) — hepsi aynı mental model altında anlamlı hale geliyor. Framework soyutlaması değil, organizasyon soyutlaması kullanıyorsunuz.
Yaratıcılarının cümlesi şöyle: "Agent'lar freelance çalışmaz. Bir patronları, bir unvanları ve bir iş tanımları vardır." Bu cümle dikkate değer çünkü bugünün agent framework'lerinin çoğunun tersine bir iddiada bulunuyor. Günümüzün çoğu framework'ü agent'ı olabildiğince özgür ve otonom bırakmaya çalışıyor. Paperclip agent'ı olabildiğince sınırlı ve hesap verebilir yapmaya çalışıyor.
Heartbeat: Sürekli çalışmayı reddetmek
Paperclip'in ikinci kritik kararı ve en alışılmadık olanı: agent'lar sürekli çalışmaz. Schedule'a göre uyanır, işini yapar, uyur.
Bu tasarıma "heartbeat" diyorlar. Bir Content Writer agent'ı her dört saatte bir uyanır, kendisine atanmış ticket'ları kontrol eder, yapılması gereken iş varsa yapar, sonucu kaydeder, uyur. SEO Analyst'i her sekiz saatte bir. Social Manager'ı her on iki saatte bir. Bir ticket atandığında veya başka bir agent delegation yaptığında da uyanır. Ama default state'i uykuda olmaktır.
Bu başlangıçta tuhaf gelir. Agent ekosisteminin son iki yılı "continuous agent" rüyasını satıyordu. Observe → think → act loop'u, hiç durmadan çalışan, kendi hedeflerini kendi üreten sistemler. Heartbeat modeli bunun tam tersi. Ve bize göre heartbeat modeli bugün itibarıyla daha olgun bir mühendislik kararı.
Sebebini anlatalım. Sürekli çalışan bir agent loop'u üç somut problemi beraberinde getirir. Birincisi maliyet: idle durumda bile token harcar çünkü "observe" adımı LLM çağırmayı gerektirir. İkincisi runaway loop riski: agent kendi kendini sonsuz bir döngüye sokar ve sabah kalktığınızda binlerce dolarlık bir faturayla karşılaşırsınız. Üçüncüsü mental model: sürekli çalışan bir şeyi insan denetlemek zor, çünkü siz bakana kadar beş adım önde olmuş olur.
Heartbeat bu üçünü birden siler. Idle maliyet yok çünkü uyuyan agent çağrı yapmıyor. Runaway loop yok çünkü bir sonraki çalışma zamanını agent değil Paperclip belirliyor. İnsan denetimi kolay çünkü her uyanma arasında geçen süre bir gözlem penceresi.
Ama bedava değil. Heartbeat'in maliyeti şudur: agent "gerçek zamanlı" değildir. Bir müşteri e-postası geldiğinde agent dört saat sonra cevap verir (veya event-based wake ile hemen, ama o zaman heartbeat avantajının bir kısmını kaybedersiniz). Her iş türü için uygun değil. Ama tekrarlayan, schedulable, batch-able işler için — ki bunlar agent'ların bugün gerçekten iyi yaptığı işler — ideal bir model.
Ve altında yatan mühendislik şaşırtıcı derecede olgun. Heartbeat temelde cron + message queue pattern'idir. Distributed systems dünyasının son otuz yılda olgunlaştırdığı bir pattern. Paperclip bunu agent dünyasına getiriyor, oysa çoğu rakip "yepyeni bir şey" icat etmeye çalışıyor.
Atomik checkout: Agent dünyasına veritabanı disiplini
Paperclip'in teknik dokümantasyonunda dikkatimizi çeken cümlelerden biri şuydu: "Task checkout ve budget enforcement atomiktir." İlk okuduğumuzda önemsiz gibi göründü. Sonra ne demek istediklerini düşündük.
Şunu söylüyorlar: İki agent aynı task'i aynı anda çekemez, ve bir agent budget'ını aşan bir işe başlayamaz — bu iki kontrol aynı transaction içinde yapılır. Bu şu demek: race condition yok. Agent A bir ticket'ı "in progress" yaparken Agent B aynı ticket'ı göremez. Budget kontrolü task atama anında yapılır, task bittikten sonra değil. Yani "bütçe aşılmadan önce" durdurursunuz, "aşıldıktan sonra şaşırmak" yerine.
Veritabanı tarafında bunun anlamı muhtemelen Postgres'in SELECT ... FOR UPDATE SKIP LOCKED kalıbıdır. Bu kalıp distributed worker pattern'inin standart çözümüdür ve finans yazılımlarından e-ticaret stok yönetimine kadar her yerde kullanılır. Paperclip bunu agent task queue'suna uyguluyor.
Neden önemli? Çünkü bugünün çoğu agent framework'ü bu tür garantileri vermez. CrewAI bir Python process'idir, iki worker aynı task'i işleyebilir. LangGraph state'i kendi yönetir ama çoklu-agent-aynı-task problemi için özel bir çözüm sunmaz. "Agent'lar birbirini selamlayarak hallederler" gibi bir varsayım üzerine inşa edilmiş pek çok framework var. Paperclip ise agent dünyasının henüz önemsemediği veritabanı disiplinlerini getiriyor.
Bu küçük bir detay gibi görünüyor. Ama on agent'ın aynı project üzerinde çalıştığı bir ortamda, bu detay sisteminizin çalışır veya çalışmaz olmasını belirleyen şey. Paperclip bu detayı önemseyen az sayıda projeden biri.
Goal ancestry: "Neden" sorusunu context'te taşımak
Paperclip'in mimarisindeki en zarif fikir bize göre goal ancestry. Kavram basit, uygulaması derin.
Şöyle çalışıyor: her task Paperclip'te bir hiyerarşinin yaprağıdır. Üstünde bir agent goal'ü vardır. Onun üstünde bir project goal'ü. Onun üstünde company mission'ı. Bir task çalıştığında, agent sadece task'in başlığını değil, bu bütün atalar zincirini görür. "WebSocket handler yaz" değil, "WebSocket handler yaz çünkü collaboration feature'ını ship ediyoruz çünkü 1M MRR'lık AI not uygulaması yapıyoruz."
Küçük bir fark gibi görünüyor. Değil. Bu farkın pratik sonucu şu: agent ne yaptığını değil, neden yaptığını bilir. Bu bilgi ona karar verirken rehberlik eder. WebSocket handler'da trade-off'lar var — simplicity vs scalability, ready-made library vs custom implementation, hızlı vs test-edilmiş. Agent bu trade-off'ları "1M MRR hedefi olan bir SaaS" bağlamında değerlendirir. Oysa tek başına "WebSocket handler yaz" talimatını alan bir agent bu bağlamı bilemez ve size çoğu zaman yanlış trade-off seçer.
Geleneksel framework'lerde bu bağlam elle kurulur. Her prompt'a siz tekrar tekrar "hatırlatırsınız" — ki bu hem lossy bir süreçtir hem de ölçeklenmez. Paperclip bağlamı veri modelinin içine yerleştirir. Task'i çekerken ancestry otomatik olarak gelir, system prompt'una otomatik olarak eklenir.
İş modeli tarafında bunun adı "goal alignment." Mühendislik tarafında ise recursive CTE veya basit bir ağaç traversal'ı. Teknik olarak zor değil. Ama yapılması gerektiğini fark etmek zor olan kısım. Paperclip fark etmiş.
Runtime skill injection: Fine-tuning'e hayır, markdown'a evet
Agent'a yeni bir yetenek öğretmek isterseniz geleneksel yol fine-tuning'dir. Modeli yeniden eğitirsiniz, yeni davranışı içselleştirir, deploy edersiniz. Paperclip bunun tam tersini yapıyor.
Paperclip'te "skill" bir markdown dosyasıdır. Başlık, açıklama, yönergeler, örnekler içerir. Agent bir task aldığında, Paperclip (veya agent'ın kendi içinde çalışan skill manager) mevcut skill'ler arasından task'e uygun olanları seçer ve agent'ın context'ine runtime'da enjekte eder.
Bu Anthropic'in Claude Skills pattern'inin aynısı ve ilginç bir şekilde Paperclip repo'sunda .claude/skills/ klasörünün olması, Paperclip'i inşa ederken Claude Code'a kendisinin nasıl kullanılacağını bu yolla öğrettiklerini gösteriyor. Dogfooding eyleminde bulunmuşlar yani.
Mühendislik olarak bu kararın iki sonucu var. Birincisi: yeni yetenek eklemek ucuz. Yeni bir ERP entegrasyonu mu gerekiyor, yeni bir müşteri segmentinin jargon'u mu öğretilmeli, yeni bir iş kuralı mı var — fine-tune etmeye gerek yok, bir markdown dosyası yazıyorsunuz. İkincisi: yetenekler modülerdir, versiyonlanabilir, export edilebilir, ve potansiyel olarak bir marketplace'te paylaşılabilir. Paperclip'in gelecek roadmap'inde "Clipmart" diye bir özellik var; hazır şirket şablonlarını (org chart + agent'lar + skill'ler) tek komutla indirip çalıştırma fikri. Marketplace altyapısının temeli bu skill modülerliği.
Fine-tuning'in yerini skill injection'ın alıp almayacağı ayrı bir tartışma. Ama Paperclip'in burada yaptığı şey dikkate değer çünkü bilgiyi modelden ayırıyor. Bilgi dosyalarda yaşar, model bu dosyaları ihtiyaç anında okur. Bu mimari, modeller değiştiğinde, upgrade olduğunda, rakipleri tarafından geçildiğinde sizi bağımsız tutar. Knowledge portability.
Governance: Otonomi bir varsayım değil, bir izin
Paperclip'in felsefi olarak en ilginç yanı governance modeli. Slogan "zero-human company" ama gerçek tasarım tam tersini söylüyor: insan her zaman döngüdedir, her kritik karar kapısında.
Varsayılan davranışlar şöyle: bir agent yeni bir agent işe almak isterse approval queue'ya düşer, siz onaylamazsanız hiring olmaz. Bir CEO agent strateji yazarsa siz review etmeden execute edilmez. Budget artırma talepleri onay gerektirir. Herhangi bir agent'ı dilediğiniz an pause, resume, terminate edebilirsiniz. Config değişiklikleri versiyonlanır, kötü bir değişiklik rollback edilebilir.
Dokümantasyondaki cümle akılda kalıcı: "Otonomi varsayılan değil, verdiğiniz bir ayrıcalıktır."
Bu cümle sessizce devrimci çünkü son iki yılın agent söylemi tam tersini savunuyordu. "Agent'lar özgür olmalı", "insan bottleneck", "otonomi maksimize edilmeli" — bunları hepimiz duyduk. Paperclip bunların hiçbirini söylemiyor. Paperclip diyor ki: agent'lar çalışandır, çalışanlara iş verilir, işler onaylanır, sonuçlar review edilir, performans ölçülür, ve patron siz kalırsınız.
Bu konservatif tutum sizi yavaşlatır. Kesinlikle. Ama aynı zamanda sizi agent'ların paranızı loop'larda yakmasından, yanlış hiring kararları vermesinden, production'a kırık kod push etmesinden korur. Paperclip'in mental modeli şu: bugün ki modellerin güvenilirlik seviyesinde insan onayı ortadan kaldırılmamalı, sadece daha iyi tool'larla desteklenmeli. Dashboard, ticket sistemi, audit log, budget görünürlüğü — hepsi insan onayını daha hızlı ve daha bilgili yapmak için.
Bu ayrımı anlamak önemli çünkü bu Paperclip'in asıl değer önermesi. "Agent'ları otomatikleştiriyoruz" demiyor. "Agent'ları denetlenebilir yapıyoruz" diyor. İkisi çok farklı ürün kategorileri.
Bring your own agent: Runtime-agnostic felsefesi
Teknik olarak Paperclip'in en akıllı kararlarından biri agent runtime konusunda opinion'suz olması. README'deki cümle şu: "Heartbeat sinyali alabiliyorsa, işe alındı."
Pratik olarak bu şu demek: Paperclip bir Claude Code session'ını, bir Cursor instance'ını, bir OpenAI Codex çağrısını, bir bash script'ini veya basit bir HTTP webhook'unu aynı şekilde "agent" olarak kabul eder. Her biri için bir adapter yazılmıştır. Adapter heartbeat'i alır, agent'ı tetikler, agent kendi runtime'ında LLM'ini çağırır, iş biter, sonuç Paperclip'e döner, ticket ve budget güncellenir.
Bu kararın stratejik önemi şu: agent ekosistemi inanılmaz hızlı değişiyor. Bir yıl önce Devin'di, şimdi Claude Code var, altı ay sonra kim bilir ne çıkar. Kendinizi tek bir runtime'a bağlarsanız o runtime'ın kaderine bağlanırsınız. Paperclip hiçbirine bağlanmıyor. Tüm runtime'ları eşit vatandaş sayıyor. Bu sayede kullanıcı en iyi aracı seçebilir, birden fazla aracı aynı org chart'ta karıştırabilir, araç değiştirdiğinde mimariyi yeniden kurmak zorunda kalmaz.
Mühendislik olarak bu bir "hexagonal architecture" kararıdır. Core domain (company, agent, task, budget, audit) runtime'dan izole tutulur. Runtime'lar port/adapter layer'ında yaşar. Core yeniden yazılmadan yeni runtime eklenebilir. Bu disiplin az sayıda agent projesinde var; çoğu projeler kendi runtime'larını core'a gömerler.
Paperclip'in bu konuda kendi kendine bir baltalama yapma potansiyeli de var. "Herkese hizmet" stratejisi çoğu zaman "kimseye tam hizmet edememe" ile sonuçlanır. Spesifik runtime'lar için özel optimizasyonlar yapamayabilir. Ama stratejik olarak, erken pazarda, bu riski almaya değer. Çünkü alternatifi — runtime'a kilitlenmek — çok daha ölümcül.
Gerçeklik: Slogan ile ürün arasındaki boşluk
Buraya kadar Paperclip'in doğru yaptığı şeyleri anlattık. Şimdi biraz gerçeklik.
"Zero-human company" slogan, gerçek değil. Paperclip şu anda otonom bir şirket çalıştırmıyor. "CEO Chat" bile henüz roadmap'te yeşil değil — yani CEO agent'ınızla doğrudan sohbet bile edemiyorsunuz, sadece ticket açabiliyorsunuz. "MAXIMIZER MODE" (tam otonom, onaysız mod) henüz yok. "Multiple Human Users" yok, yani takım halinde kullanamıyorsunuz. "Cloud deployments" yok, kendi sunucunuzu kurmak zorundasınız.
Testimonial'larına dikkatle bakarsanız hiç kimsenin "üç aydır insansız çalışıyorum" demediğini görürsünüz. En pozitif olanlar "mission control'ümü toparladı", "yirmi Claude Code tab'ımı organize etti", "AI workforce'umu izleyebiliyorum" diyor. Bunlar güzel şeyler ama "zero-human" değiller.
1000'den fazla açık PR var, 686 açık issue var, proje olgun değil. Breaking change beklemek mantıklı. Production bağımlılığı olarak kullanmadan önce iki kez düşünmek gerekir.
Ve en önemlisi: Paperclip'in inşa ettiği org chart'ın içindeki agent'ların akıllılığı tamamen altta çalışan LLM'in akıllılığına bağlıdır. Paperclip agent'ı akıllı yapmaz. Sahneyi hazırlar. Sahne güzel ama oyuncular hâlâ Claude ve GPT. CEO agent'ının delegation kararlarının kalitesi GPT-5 veya Claude Opus'un kalitesidir, Paperclip'in değil.
Bunları biliyorsak Paperclip'e hak ettiği değeri vermek daha kolay: vizyoner bir ürün değil, olgun bir altyapı deneyi. Bugün "ağır el ile yönetilen bir 20-agent workflow'u" için gerçekten yararlı bir araç. Yarın gerçek otonom şirketlerin altyapısı için sağlam bir temel. Ama aradaki yol hâlâ uzun.
Neden önemli: Agent ekosisteminin olgunlaşma momenti
Paperclip'i ilginç kılan tek başına Paperclip değil, Paperclip'in neyi temsil ettiği. Son iki yıl agent alanında "daha akıllı model", "daha büyük context", "daha karmaşık graph" söylemiyle geçti. Paperclip bu söylemi terk ediyor ve bambaşka bir şey söylüyor: "Agent ekosistemi akıllılıktan değil, disiplinden eksik."
Budget tracking, task checkout, governance, audit log, approval gates, rollback, ancestry, persistent state — bu liste agent mühendisliğinin listesi değil. Bu klasik enterprise software mühendisliğinin listesi. Paperclip bunları agent dünyasına getiriyor. Bu tavır bir önceki yılın "LLM'leri zincirleyelim" heyecanından çok farklı bir yerde duruyor.
Ve doğru yerde duruyor. Çünkü agent'ların pratikte başarısız olduğu yerler neredeyse hiç "model yeterince akıllı değildi" değil. Genelde şöyle hatalar: runaway loop, kaybolmuş context, duplicate work, aşılmış budget, bozulmuş state, hesap verilemez kararlar, rollback edilemez değişiklikler. Bunlar engineering problemleri, research problemleri değil. Çözümleri de engineering çözümleri.
Paperclip'i değerli kılan Paperclip'in kendisi değil, Paperclip'in açtığı kapı. Bir sonraki iki yılda agent ekosisteminin asıl ilerlemesi muhtemelen daha büyük modellerden değil, bu tür disiplinli altyapı katmanlarından gelecek. Paperclip bu dalganın erken bir örneği. Erken olduğu için pürüzleri var. Ama yön doğru.
Kapanış: Ne almak, neye dikkat etmek
Kendi agent mimarinizi kuruyorsanız, Paperclip'ten alınabilecek pattern'ler şunlar. Heartbeat paradigması maliyet ve güvenlik açısından düşündüğünüzden daha değerli. Goal ancestry küçük bir veri modeli değişikliği ama çıktı kalitesinde gözle görülür fark yaratır. Atomic task checkout her çoklu-agent sisteminin gizli düşmanı race condition'lara karşı standart çözümdür. Runtime-agnostic adapter pattern sizi model/runtime lock-in'den korur. Runtime skill injection bilgiyi modelden ayırarak upgrade path'inizi açık tutar.
Neye dikkat etmek lazım. "Zero-human" söylemine kapılmayın — ne Paperclip ne de başka bir ürün bunu henüz yapmıyor. Governance katmanını erken inşa edin, geri dönüp eklemek çok zordur. Budget görünürlüğünü dashboard'a koyun, arka planda tutmayın. Agent'ın "ne yaptığını" değil "neden yaptığını" veri modelinize yerleştirin.
Paperclip ile ilgili son sözümüz şu: 46 bin star'ı hak eden bir ürün mü emin değiliz, ama 46 bin star aldığı gerçeği agent ekosisteminin olgunlaşmaya hazır olduğunun bir işareti. Piyasa "daha akıllı agent" yerine "daha disiplinli agent" istiyor. Paperclip bu talebe cevap veren erken ürünlerden biri. Ve bu cevabın içinde, kendi ürününüz için de düşünmeye değer birkaç somut fikir var.
