loopx-project/loopx
Turn long-horizon goals into verifiable results. A local-first semantic control plane and research workbench for long-running agent teams, across sessions and runtimes.
Hızlı değerlendirme
Özet
LoopX, agent çalışmalarının hedeflerini, kararlarını ve kanıtlarını oturumlar arasında koruyup devam eden işleri yönetmeye yarayan yerel öncelikli bir control plane sunuyor.
Profiline uyum
Kalıcı research ve discovery iş akışları fikir araştırmalarına yardımcı olabilir, ancak profilindeki uygulama geliştirme ve içerik üretimi ihtiyaçlarına doğrudan çözüm değildir.
Neden yükseliyor
119 günde 6007 yıldıza ulaşması ve README'de öne çıkarılan LHTB sonuçları görünürlüğünü artırmış olabilir. Son 28 gündeki 2976 commit yüksek aktiviteye işaret ediyor; ancak yalnızca 4 farklı yazar bulunması, bu hareketliliğin geniş katılımlı bir topluluğa karşılık geldiğini göstermiyor. Yıldızların veya benchmark iddialarının benimseme ve güvenilirlik kanıtı olarak tek başına yeterli olmadığı da not edilmeli.
Problem
Uzun süren agent işlerinde oturumlar arasında bağlam ve ilerleme kaybı, görev devrinin belirsizliği ve faydasız biçimde devam eden otomasyon, insan gözetimi ve iş sürekliliğini zorlaştırıyor.
Çözüm
Hedef, görev, kapsam, karar, kanıt ve kota durumunu kalıcı tutuyor; işi sınırlandırılmış agent adımlarına bölerek uygun runtime'lara devrediyor, çıktıları ve sonraki adımları kaydediyor. Ayrıca durumları yönetmek ve incelemek için bir dashboard sağlıyor.
Yenilik
Kalıcı iş durumu, kontrollü devam etme ve agent'lar arası devir süreçlerini birden fazla runtime'ı destekleyen tek bir control plane'de birleştirmesi kayda değer. Ancak bu yaklaşımın kategoriyi başlatan veya bütünüyle yeni bir teknik yöntem olduğu gösterilmiş değil.
Teknolojiler
- Python
- Codex
- Claude Code
- DeepSeek Harness
- Lark
- PWA
Riskler
- Proje 119 günlük; uzun vadeli kararlılık ve bakım geçmişi henüz sınırlı.
- Son 28 gündeki yüksek commit sayısına rağmen yazar çeşitliliği düşük; bakım yükü az sayıda kişide yoğunlaşabilir.
- README'deki LHTB sonuçları proje tarafından sunuluyor; bağımsız doğrulama veya değerlendirme ayrıntıları verilen bilgilerden anlaşılamıyor.
- Değerinin önemli bölümü desteklenen harici agent runtime'larıyla entegrasyona bağlı; entegrasyonların kapsamı ve sürekliliği ayrıca değerlendirilmelidir.
- Kontrol, kanıt ve görev yönetimi katmanları uzun vadeli işlerde faydalı olsa da kurulum ve operasyonel karmaşıklık yaratabilir.
Detaylı değerlendirme
Uyum profiline göre: bu işime yarar mı?
Ne yapar
LoopX, Codex, Claude Code, Cursor, dsh veya custom runner gibi agent harness'lerin üzerine konumlanan, long-horizon agent işleri için provider-neutral bir control plane ve state kernel sunar. Goal, objective, todo, gate, evidence, quota, ownership, lease, handoff ve recovery durumlarını agent session'larından bağımsız ve kalıcı tutmayı amaçlar. Böylece bounded turn'lerle çalışan agent'lar günler süren engineering, research veya operations işlerinde kaldıkları yerden devam edebilir; hangi kararın insana ait olduğu ve bir sonraki adımın ne olduğu görünür kalır. LoopX bir LLM provider veya agent framework değil; mevcut harness'leri yöneten bir governance ve workflow katmanıdır.
Nasıl çalışır
Ana state local-first olarak LoopX tarafından tutulur; README'de `.loopx/registry.json`, goal state, todo, gate ve runtime state gibi dosya tabanlı yüzeyler gösteriliyor. Agent bir bounded turn çalıştırmadan önce `loopx quota should-run` ile devam edip etmeyeceğini kontrol eder, bir todo claim eder, değişikliği ve evidence'ı yazar, state'i refresh eder ve doğrulanmış slice için quota harcar. Kernel objective, scope, authority, ownership, lease, evidence, stop condition ve human gate bilgilerini saklar; Codex, Claude Code veya başka bir runner yalnızca işi yürütür. Dashboard ve status yüzeyleri state'i projekte eder, fakat browser state authority değildir. Provider, capability ve extension ayrımıyla dış sistem entegrasyonları çekirdekten ayrılmıştır. README'nin verdiği bilgilere göre runtime bağımlılığı Python standard library ile sınırlı; ancak farklı harness'lere adapter, skill veya plugin kurulumu gerekiyor.
Kullanım alanları
- Multi-day engineering işlerinde issue, PR, test ve review state'ini bounded turn'ler arasında korumak
- Claude Code, Codex veya custom runner kullanan agent'lar arasında handoff ve ownership yönetmek
- İnsan onayı, safety gate, publication gate veya production write gibi adımları otomatik akıştan ayırmak
- Recurring heartbeat, monitor ve scheduled agent işleri için quota ve stop condition uygulamak
- RAG/agent tabanlı araştırma veya benchmark süreçlerinde hypothesis, evidence, invalid lineage ve promote/stop kararlarını izlemek
- Birden fazla peer agent'ın aynı goal üzerinde claim, lease ve todo sınırlarıyla çalışmasını sağlamak
Alternatifler
- LangGraph
- Temporal
Kimler için
Uzun süren ve tek bir chat session'ına sığmayan agent işlerini işleten ekipler için. Özellikle Codex, Claude Code, Cursor, dsh veya custom Python runner kullanan; agent'ların ne yaptığını, hangi evidence'a dayandığını ve ne zaman insan beklemesi gerektiğini denetlenebilir hale getirmek isteyen ekipler hedefleniyor. Kısa süreli tek-shot LLM çağrıları veya yalnızca Next.js request/response akışları için hedef ürün değil.
Olgunluk
Beta ile üretim öncesi arasında değerlendirilmeli. Apache-2.0 lisans, 46 release, 5.570 yıldız ve son 28 günde 1.304 commit / 14 farklı yazar aktif geliştirmeye işaret ediyor. PyPI kurulumu, `doctor`, upgrade/rollback akışları, dokümantasyon ve birden fazla harness adapter'ı olumlu. Buna karşın proje yalnızca 96 günlük; ana iddiaların önemli bir bölümü README'deki showcase ve kullanıcı raporlarına dayanıyor, 200+ saatlik örneklerin bağımsız ve tam reproducible production kanıtı olmadığı README'de açıkça belirtilmiş. Bu nedenle kritik production control plane olarak doğrudan benimsemek yerine izole bir pilotta denenmeli.
Kurulum
İlk deneme zahmeti düşük: Python 3.11+, aktif environment ve POSIX shell veya PowerShell 7 yeterli görünüyor. `python3 -m pip install --upgrade loopx`, ardından `loopx workflow-skills --install` ve `loopx doctor` çalıştırılıyor; proje kökünde `loopx connect` ve `loopx status` ile başlanıyor. Basit bir custom runner için README'de verilen core tick komutlarıyla küçük bir deneme yapılabilir. Ancak Kaliwa'ya gerçek entegrasyon, Python process çalıştırma, `.loopx` state lifecycle'ı, agent session'ları ile LoopX todo/evidence protokolünün bağlanması ve Supabase/Vercel çalışma modelinden local-first state'e geçiş sınırlarının tasarlanmasını gerektirir. Next.js dashboard yerine mevcut LoopX dashboard'unu kullanmak istemezsek kendi React arayüzümüze projection API veya CLI çıktısı bağlamamız gerekir; README'den bunun hazır bir HTTP/TypeScript SDK olarak sunulduğu anlaşılmıyor.
Bizim için
Somut kullanım
Kaliwa'daki uzun süren agent akışları için LoopX'yi ürünün ana state katmanı yerine deneysel bir agent control plane sidecar'ı olarak kullanabiliriz. Örneğin bir agent goal'ı PostgreSQL'deki Kaliwa kaydına bağlanır; LoopX `quota should-run`, todo claim, gate ve evidence akışını yürütür; Anthropic tabanlı mevcut agent'ımız bounded turn'ü çalıştırır; sonuçta doğrulanmış event'ler Supabase'e writeback edilir. İlk pilot, bir GitHub issue/PR veya RAG evaluation sürecinde 1-2 gün süren bir akış olmalı. Başarı kriterleri: restart sonrası state kaybı olmaması, insan gate'inin atlanamaması, duplicate turn'lerin engellenmesi, evidence ve handoff'un Supabase'e doğru aktarılması. Buna karşılık LoopX'yi doğrudan Next.js uygulamasının request path'ine veya Supabase Edge Functions içine gömmek için README'de yeterli kanıt yok.
Uyum gerekçesi
Agent ve long-horizon workflow açısından kavramsal uyum yüksek; mevcut Anthropic, RAG ve agent mimarilerinin önüne provider-neutral governance katmanı koyabilir. Ancak ekibin ağırlıklı üretim yığını Next.js, React, TypeScript, Supabase/PostgreSQL, Deno ve Vercel iken LoopX Python 3.11+ tabanlı, local-first ve CLI/adapter merkezli bir ürün. PostgreSQL/Supabase persistence, Deno Edge Functions veya TypeScript entegrasyonu README'de kanıtlanmıyor. Bu nedenle agent operasyonu ihtiyacı için anlamlı, fakat Kaliwa ürün mimarisine doğrudan oturan bir kütüphane değil; ayrı bir sidecar/worker olarak ancak kontrollü biçimde denenebilir.
Engeller
- Python 3.11+ yeni bir runtime ve Kaliwa'nın TypeScript/Deno ağırlıklı yığınına ek operasyonel yüzey getiriyor.
- State modeli local-first; Vercel'in ephemeral/serverless çalışma modeliyle doğrudan doğal bir eşleşme görünmüyor.
- Supabase/PostgreSQL persistence, TypeScript API/SDK ve Deno Edge Functions entegrasyonu README'de gösterilmiyor.
- Agent harness adapter'ları ve workflow skills kurulumu gerekli; her yeni harness için entegrasyon ve bakım maliyeti oluşur.
- 96 günlük proje yaşı, yüksek commit/release aktivitesine rağmen production API ve state migration sözleşmelerinin zaman içinde ne kadar stabil olduğunu belirsiz bırakıyor.
- README'deki uzun süreli showcase'ler faydalı kanıtlar sunuyor ancak bazıları owner-run, redacted veya kullanıcı raporu; bağımsız reproducibility sınırlı.
- Kaliwa'nın merkezi multi-tenant ürün state'i ile LoopX'nin local/private runtime state'i arasında authority ve synchronization tasarımı yapılmalı.
- İki ayrı dashboard/control surface kullanmak operasyon ve kullanıcı deneyimi karmaşıklığı yaratabilir.
Ne zaman kullanılır
Kaliwa'da bir agent görevi birkaç bounded turn'den uzun sürüyor, günler boyunca pause/resume veya handoff gerektiriyor, human approval ve evidence zorunlu hale geliyor ya da birden fazla agent aynı goal üzerinde çalışıyorsa kullanılabilir. En mantıklı ilk kullanım, düşük riskli bir internal engineering/research pilotudur: örneğin issue analizi → kod değişikliği → test → review hazırlığı akışında LoopX'nin goal/todo/gate/evidence state'ini yönetmesini ve Anthropic kullanan mevcut agent'larımızın yalnızca bounded turn yürütmesini test etmek. Ayrıca Supabase üzerinde tuttuğumuz ürün state'inden ayrı olarak, local/private agent çalışma state'i gerektiğinde de yararlı olabilir.
Ne zaman kullanılmaz
Kısa ve stateless LLM çağrıları, tek request içinde tamamlanan RAG sorguları, basit background job'lar veya Next.js route/Edge Function akışları için gereksiz bir kontrol katmanı ekler. Kaliwa'nın agent orchestration ihtiyacı zaten birkaç Supabase Edge Function ve PostgreSQL tablosuyla karşılanıyorsa LoopX'nin Python/local-first modeli operasyonel karmaşıklık yaratır. Production'da Vercel ve Supabase üzerinden yatay çalışan, merkezi ve gözlemlenebilir bir scheduler bekleniyorsa LoopX'nin local-first tasarımı doğrudan uymaz. README'de Supabase, PostgreSQL, TypeScript SDK, Vercel deployment veya Deno runtime desteği gösterilmiyor.
Dikkat edilecekler
- Pilot sırasında LoopX state'ini Kaliwa business state'inden ayrı tutun; yalnızca idempotent event veya açıkça doğrulanmış writeback ile Supabase'e aktarın.
- `quota should-run` ve human gate kontrollerini yalnızca prompt talimatı olarak değil, mümkünse runner seviyesinde zorunlu protokol olarak uygulayın.
- Vercel üzerinde uzun süren process çalıştırmak yerine LoopX'yi ayrı bir persistent worker veya geliştirici/operatör ortamında konumlandırın.
- `.loopx/` içindeki goal, evidence, log veya credential içerebilecek dosyaların repository ve telemetry sınırlarını inceleyin.
- Restart, duplicate delivery, stale lease, concurrent claim, quota exhaustion ve partial write senaryolarını test edin.
- Apache-2.0 lisansını doğrulayın; ayrıca agent çıktılarının, üçüncü taraf provider verilerinin ve Kaliwa müşteri verilerinin saklama/mahremiyet sınırlarını belirleyin.
- Önce tek bir custom runner ile minimal entegrasyon yapın; birden fazla harness adapter'ını aynı anda devreye almayın.
- Kurulum sonrası `loopx doctor`, state recovery, rollback ve upgrade davranışlarını CI veya canary ortamında doğrulayın.
- Daha sonra PostgreSQL persistence veya TypeScript/Deno adapter'ı gibi ihtiyaçlar ortaya çıkarsa bunların LoopX upstream sözleşmesiyle mi yoksa ekip içi bir bridge ile mi çözüleceğini baştan kararlaştırın.