Yapay zekâ ajanlarının görev yönetimi: istem değil, sözleşme olarak sahiplenme döngüsü

Yapay zekâ ajanlarının görev yönetimi, döngünün sahibi istem değil pano olduğunda işe yarar: ajan ne yapacağını sorar, sessizleşirse süresi dolan bir kiralamayla tek bir görevi sahiplenir, kişiye yalnızca onun vermesi gereken kararları sorar ve birinin kontrol edebileceği bir makbuzla bitirir. Weft’te bu adımların her biri sunucunun denetlediği bir MCP aracıdır; böylece bir adımı atlayan ajan sessizce senkronizasyondan kopmak yerine reddedilir ya da görevi kaybeder.

Weft’i biz geliştiriyoruz. Diğer ürünlerle ilgili bilgiler, 27 Ekim 2026’da kontrol edilen resmî sayfalarından alındı.

Sohbete yapıştırılan görev listesi neden işe yaramamaya başlar?

Görevleri bir sohbete yapıştırmak herkesin ilk denediği şeydir ve bir öğleden sonra boyunca işe yarar. Sonra sohbet biter ve durum da onunla biter. Ajan hangi maddeyi bitirdiğini, hangisinden vazgeçtiğini ve neden emin olmadığını biliyordu. Artık kimse bilmiyor.

Listeyi yapıştıran kişi aracıya dönüşür: sonuçları gerçek panoya geri kopyalar ve hiçbir şey alındığını söylemediği için ikinci bir oturumun üstlendiği işi yeniden yapar.

Pano erişimi anlık görüntü sorununu çözer, gerisini değil. Tek araçlar “kartı taşı” ve “yorum ekle” ise döngü hâlâ ajanın talimatlarına yazılmış bir geleneğe uymasına bağlıdır. Gelenekler tam da işler ters gittiğinde bozulur: ajan çalışmanın ortasında çöker ya da iki ajan aynı anda başlar.

Sözleşme olarak sahiplenme döngüsü neye benzer?

Weft’te döngünün beş adımı var ve her biri tek bir MCP uç noktasında, https://letsweft.com/api/mcp adresinde ayrı bir araç. Aradaki durumu sunucu tutar; böylece döngü herhangi bir sohbetin bitişinden sağ çıkar.

1. get_my_work: seçmeden önce sor. Yanıt, bu istemcinin zaten elinde tuttuklarını, kişiyi bekleyenleri, süresi geçmiş ya da yaklaşanları ve bir şeye başlamak için yer olup olmadığını kapsar.
2. start_task: kiralamayla sahiplen. Sahiplenme 20 dakika sürer ve görevi Doing’e taşır. Yanıt bir runId, bir leaseToken ve renewEverySeconds: 300 taşır. Aynı görevi deneyen ikinci bir istemci already_claimed ve işi tekrarlamaması yönünde bir ipucu alır.
3. report_progress: nabız sinyali. Çalışma id’si ve kiralama belirteciyle yapılan her çağrı kiralamayı yeniler. Ajan ölürse nabız sinyalleri durur ve 20 dakika sonra çalışma bayat olarak işaretlenir, görev de herkesin alabileceği şekilde atanmamış duruma döner. Kaybedilen bir kiralama lease_lost yanıtını verir; böylece ajan işin artık kendisinde olmadığını bilir.
4. request_input: yalnızca kişiye ait kararlar için. En fazla 500 karakterlik bir soru, en fazla 10 seçenekle. Ajan beklerken sahiplenme korunur.
5. complete_task: makbuzla bitir. outcome, artifacts (URL, commit ya da dosya hash’i gibi kanıtlar), notDone, unknowns ve nextStep.

Neden durum değil de kiralama? Çünkü çökmüş bir ajanın gönderebileceği tek işaret sessizliktir. Doing’deki bir kart, bir zamanlar biri üzerinde çalışıyordu der. Kiralama ise biri şu anda üzerinde çalışıyor der ve bu artık doğru olmadığında bunu kendiliğinden söylemeyi bırakır.

Sahiplenmenin kendisi, benzersiz bir indeksle korunan tek bir veritabanı eklemesidir. İki ajan yarıştığında kimin kazandığına veritabanı karar verir, böylece ikisi birden görevi alamaz. Buna karşılık bir saniye arayla gönderilen iki “Sahiplenildi” yorumu, ikisi de geçerli yorumlardır.

Ajan request_input’u ne zaman çağırmalı?

Yalnızca kişinin karar verebileceği bir şeye geldiğinde: para, yayımlama, üretim ya da hukuk gibi geri dönüşü olmayan her şey veya makul bir varsayılanı olmayan gerçek bir yol ayrımı. Devam etmek için izin istemek için değil.

Bu ölçülülük önemli, çünkü bir soru kişiye bitmiş bir görevle aynı dikkate mal olur ve Weft’te aynı sınıra sayılır. Soru Gelen kutusuna düşer; bir mobil bildirimle ve 20 dakika ya da daha uzun süredir bekleyen öğeler için bir e-posta hatırlatmasıyla. Weft ajanı asla geri aramaz: yanıt, ajanın bir sonraki start_task ya da get_my_work çağrısında ona ulaşır. Soru açıkken ajan görevi 60 dakika tutar; sonrasında kiralama düşer ama soru kalır.

Bir complete_task çağrısına ne girer?

Kısa bir sonuç, kanıt ve sınırların dürüst bir dökümü. Bir hata düzeltmesi için gerçekçi bir içerik:

{
  "id": "9b2f6c1e-4d7a-4c3b-8e21-5a0f3d9c7b14",
  "runId": "d41e8a90-2f6b-4e17-9c3a-71b5e0a4c8f2",
  "leaseToken": "lt_3f9a…",
  "outcome": "Fixed the 500 on /api/invoices when the customer has no billing address. Fix is in PR #418; the route now returns 422 with a field error.",
  "artifacts": [
    { "kind": "url", "uri": "https://github.com/acme/app/pull/418" },
    { "kind": "commit", "uri": "a1c9e07" },
    { "kind": "url", "uri": "https://preview-418.acme.dev/api/invoices/health", "httpStatus": 200 }
  ],
  "claims": [
    "Added a test for an empty billing address; the invoices test file passes locally"
  ],
  "notDone": [
    "Did not merge the PR",
    "Did not backfill the 14 invoices that failed last week"
  ],
  "unknowns": [
    "Whether the mobile app shows the 422 message or a generic error"
  ],
  "nextStep": "Merge PR #418 to main"
}

Artefaktlar, kişinin ajanın sözüne güvenmeden kontrol edebileceği şeylerdir. notDone ve unknowns itiraf değildir; güvenebileceğin bir sonucu, diff’ten yeniden kurman gereken bir sonuçtan ayırır. Çağrı kanıt eksik diye asla başarısız olmaz, çünkü bitmiş işi kaybetmek onu doğrulanmamış olarak kaydetmekten daha kötüdür. Bu makbuzları okumak hakkında daha fazlası yapay zekâ ajanım ne yaptı yazısında.

Bunun bir kartı taşıyıp yorum yazmaktan farkı ne?

Hypertask’ın aynı döngü hakkındaki rehberi (sahiplen, güncelle, raporla, kapat) bu alışkanlığın iyi bir tarifi. Orada MCP ile sahiplenme; görevi yüklemek, onu çalışma bölümüne taşımak ve ekibin ajanın talimatlarına yazdığı bir isteme göre bir sahiplenme yorumu göndermekten ibaret. Aynı döngü adım adım şöyle:

Hypertask’a karşı adil olmak gerekirse: onda gerçek kiralamalar var. Belgeleri kiralama sahiplenme, nabız sinyali ve bırakma uç noktalarını listeliyor; Known limitations tablosu da görev kiralamalarının, kanıtın ve yükseltmenin tasarım gereği yalnızca REST uç noktaları olduğunu söylüyor (Hypertask MCP genel bakış). Araç başvurusundaki 21 MCP aracı arasında kiralama aracı yok (araç başvurusu). CLI’ı da isteğe bağlı bir komut olarak sahiplenebiliyor (değişiklik günlüğü, CLI başvurusu). Yani Hypertask’ta betikle çalışan bir ajan kiralama tutabilir; Claude Code ya da Cursor’da MCP üzerinden çalışan bir ajan ise biri REST çağrılarını bağlamadıkça kart-ve-yorum sürümünü alır.

Ajanların betikler ve CI işleri olarak çalışıyorsa Hypertask’ın CLI’ı ve REST API’si gerçek bir avantaj; Weft’te ikisi de yok: CLI yok, herkese açık REST API yok, webhook yok. Weft, bir MCP istemcisinin içinde yaşayan ve döngünün orada tutunması gereken ajanlar için.

Kişi ne görür?

Çoğu zaman Done’da bir kart: varsayılan olarak tamamlanan görev, sonucu ve kanıtı ekli hâlde doğrudan oraya gider.

Bir görev, inceleme gerektirdiği işaretlendiğinde ya da bir doğrulama kontrolü başarısız olduğunda kişinin Gelen kutusunda durur. Orada kişi dört yanıttan birini seçer:

• Kabul et: iş geçerli. Ajan bir nextStep verdiyse kişi onu düğmenin üstünde görür (“Kabul edersen ajan şunu yapacak …”) ve kabul etmek tam olarak o adımı onaylar, daha genişini değil. Onay 72 saat geçerlidir ve ajana get_my_work ya da start_task üzerinden geri döner.
• Yeniden yap: neyin yanlış olduğunu söyleyen bir notla geri gönder.
• Sonra: şimdi değil. Bırak: üzerinde çalışmayı durdur.

Gelen kutusu web’de; içine bir şey girdiğinde kişi Weft mobil uygulamasında bir bildirim de alır. nextStep el sıkışması, bir ajanın “iyi görünüyor”u birleştirme, dağıtma ve gönderme izni olarak görmesini engeller: onaylanan tek adımı yapabilir, sonra görevi yeniden tamamlar.

Ajan neden daha fazla işe başlamak yerine reddediliyor?

Çünkü kıt kaynak iş değil, dikkat. Bir ajan, bir insanın tek bir şeyi incelediği sürede on şeye başlayabilir.

Weft insanları bekleyenleri sayar: incelemeyi bekleyen görevler artı açık sorular. Bu sayı tek kişilik çalışma alanında 5 öğeye, ekipte 10 öğeye ya da yaklaşık 45 dakikalık tahmini inceleme süresine ulaştığında, hangisi önce gelirse, start_task attention_queue_full ile reddeder. Sınır plana değil, çalışma alanındaki kişi sayısına bağlıdır.

Ret bir çıkmaz değil, bir talimattır. Kuyruk boyutunu, en eski öğenin yaşını ve hâlâ izin verilen çağrıları bildirir: report_progress, get_my_work, get_board_state ve search. Kişinin o kartta zaten onayladığı bir adım muaftır; yani kabul edilmiş bir “PR #418’i birleştir” kuyruk tarafından engellenmez.

Bunu nasıl kurarım?

İstemcini bağla ve tarayıcı üzerinden giriş yap; kopyalanacak bir anahtar yok. Weft yenileme belirteçleri verir, böylece istemci girişi kendisi yeniler. Claude Code’da bu tek komut: claude mcp add --transport http weft https://letsweft.com/api/mcp (kurulum sayfası). Cursor’da tek tıkla kurulum var (Cursor), Codex bir yapılandırma girdisi ve codex mcp login weft gerektirir (Codex), ChatGPT’de ise Free dahil her planda yayımlanmış bir Weft uygulaması var (ChatGPT). Sunucu döngüyü ajana kendisi anlatır, bu yüzden bir yaşam döngüsü istemine gerek yok.

Claude Code için adım adım anlatım için Claude Code için görev panosu yazısına bak. Kiralamaların ve already_claimed’in en çok önem taşıdığı, tek panoda birkaç ajan için birden fazla yapay zekâ ajanı, tek pano yazısına bak. Protokolün kendisi modelcontextprotocol.io adresinde belgeleniyor; diğer MCP panoları MCP görev yöneticileri sayfasında karşılaştırılıyor.

Weft burada neyi yapmıyor?

• CLI, herkese açık REST API ya da webhook yok; yani cron işleri ve CI pipeline’ları döngüyü bir MCP istemcisinin dışından yürütemez.
• GitHub ya da Slack entegrasyonu yok. Kanıt, ajanın artefaktlarda bağladığı şeydir.
• Yerleşik yapay zekâ yok. Düşünme işi kendi yapay zekâ istemcinde olur; Weft’in yapay zekâ kredisine ihtiyaç duymamasının nedeni de bu.

Free ayda 50 görev ve 200 yapay zekâ çağrısını kapsar. Pro koltuk başına ayda $7 ya da yılda $60 (fiyatlandırma).

Ajanların döngüye uyması için iyi bir istem yetmez mi?

İstem döngüyü tarif eder; onu uygulatamaz. İki ajanın aynı görevi sahiplenmesini durdurmaz ve çöken bir ajanın tuttuğu görevi serbest bırakamaz. Weft’te sahiplenme, sahibi sunucu olan bir kiralamadır; böylece bu durumlar ajan talimatlarını hatırlasa da hatırlamasa da ele alınır.

Ajanım yarı yolda çökerse ne olur?

Nabız sinyalleri durur. Son report_progress’ten yirmi dakika sonra çalışma bayat olarak işaretlenir, kiralama belirteci temizlenir ve görev yeniden atanmamış olur; böylece başka bir ajan ya da bir kişi onu alabilir. Kart bir hafta boyunca Doing’de beklemez.

Bitmiş her görev incelememi mi bekliyor?

Hayır. Varsayılan olarak tamamlanan görev, sonucu ve kanıtıyla doğrudan Done’a gider. Yalnızca görev inceleme gerektirdiğinde ya da bir doğrulama kontrolü başarısız olduğunda Kabul et, Yeniden yap, Sonra ya da Bırak için Gelen kutunda durur.

Ajanımın işten reddedilmesini neden isteyeyim?

Çünkü aksi takdirde kontrol etmeye vaktin olmayan şeyler üretmeyi sürdürür. İnsanları bekleyen 5 öğe (ekipte 10) ya da yaklaşık 45 dakikalık inceleme olduğunda start_task attention_queue_full döndürür ve ajanı hâlâ yapabileceklerine yönlendirir. Kuyruğu temizlemek engeli kaldırır.

Hypertask’ta da kiralama var. MCP neden önemli?

Hypertask’ın kiralamaları, kendi belgelerine göre REST uç noktaları (MCP genel bakış) ve CLI’ı da sahiplenebiliyor. Bu, betikle çalışan ajanlara uyar. Bir editörde ya da sohbette MCP araçlarıyla çalışan bir ajan bunlara orada erişemez; Weft’te ise erişir: start_task, report_progress ve complete_task birer MCP aracıdır.