Orkestrasyon

Tek bir ajan tek bir işte iyidir. Bazı istekler bundan daha büyüktür: “X pazarını araştır ve bir konumlandırma belgesi yaz”, “bu özelliği uçtan uca yayımla”, “bu modülü denetle ve bulduklarını düzelt”. Bir orkestrasyon, Control Center’ın bu tür istekleri ele alma biçimidir: bir orkestratör (genellikle CEO ajanınız) ekip çapında bir plan önerir, siz onu bir kez onaylarsınız ve deterministik bir materyalize edici bunu işi yapan bir pipeline’a dönüştürür.

İşleri halletmenin mevcut iki yolunun arasında durur:

Şunu yapmak istediğinizde…	Şunu kullanın
Tek bir görevi tek bir ajana vermek	Alanda bir mesaj
Elle, zaten bildiğiniz bir süreci kodlamak	Bir pipeline şablonu
Hedefi söyleyip planı ekibin çözmesine izin vermek	Bir orkestrasyon

Bir önerinin biçimi

Orkestratöre bir hedef verdiğinizde, size yapılandırılmış bir OrchestrationProposal döndürür: serbest biçimli düzyazı yerine, uygulamanın doğrulayıp yürütebileceği tipli bir plan. Bir öneri şunları içerir:

Hedef: üst düzey isteğinizin yeniden ifade edilmiş hâli.
Roller: işi kimin yapacağı. Her rol ya sizin seçtiğiniz mevcut bir ajan ya da onay sırasında orkestrasyonun oluşturduğu yeni bir işe alımdır.
Alt biletler: biletlerden oluşan bir DAG’a bölünmüş iş.
Araştırma (isteğe bağlı): önce çalışan ve geri kalanı besleyen bir araştırma aşaması.
Tartışma (isteğe bağlı): iş başlamadan önce her rolün yapılandırılmış bir görüş paylaştığı sınırlı bir tur.
Sentez: teslimatı üreten son adım.
Bütçe: beyan edilen maliyet üst sınırı.

Nerede incelersiniz

Aynı orkestrasyonu iki yüzey gösterir.

Öneri kartı, planı üreten konuşmada bulunur. Tüm yaşam döngüsü boyunca — önerildi, yürütülüyor, tamamlandı — yeniden işlenen tek bir mesajdır ve üzerinde onaylama ile iptal eylemleri yer alır.

Plan Studio ise düzenleyicidir: bir DAG tuvali, bir düğüm denetçisi, bir revizyon ve fark çekmecesi ile tahmini taşıyan onay çubuğu. Doğrudan o karttan bir düzenleyici sekmesi olarak açılır. Kenar çubuğunda bilinçli olarak bir “Planlar” öğesi yoktur; /plans ve /plans/:kind/:id paylaşım için derin bağlantı olarak vardır.

Onaylama yalnızca operatöre açıktır. Bunun için bir MCP aracı yoktur: bir ajan öneride bulunabilir (propose_orchestration), bir plan gönderebilir (submit_plan) veya bir playbook örnekleyebilir (run_playbook), ancak yalnızca bir insan onaylar. Ajan tarafından başlatılan revizyonlar ayrıca iki dakikalık bir bekleme süresiyle sınırlandırılır; böylece yeniden planlama döngüsü akışınızı doldurmak yerine birleşir.

Onaylamadan önce değiştirebilecekleriniz, düğüm denetçisinin sunduklarıyla sınırlıdır: bir alt biletin başlığını veya metnini değiştirmek, ona hangi rolün sahip olduğunu değiştirmek, bağımlılıklarını yeniden bağlamak, çıktı şemasını düzenlemek veya düğümü tamamen silmek. Yapısal düğümler (araştırma, tartışma, sentez) ve hâlihazırda yürütülmüş düğümler salt okunurdur. Düzenleyiciden bir rolü belirli bir adlandırılmış ajana sabitleyemez ve bütçeyi düzenleyemezsiniz.

Tek bir plan üzerinde iki düzenleyicinin çalışması, birleştirmeyle değil iyimser eşzamanlılıkla çözülür. Her düzenleme, üzerinde yapıldığı base_revision değerini taşır; eski bir revizyona dayanan bir düzenleme, sessizce başkasınınkinin üzerine yazmak yerine “the plan moved on” mesajıyla reddedilir. Geri sarma da bir silme değildir — eski öneriyi yeni bir revizyon olarak ekler, böylece revizyon zaman çizelgesi yalnızca büyür.

Dürüst tahminler ya da hiç yok

Onay çubuğundaki tahmin, her rol için gerçek tamamlanmış çalıştırma geçmişinden çeyrekler arası (p25–p75) bir bant olarak oluşturulur. Maliyet toplamları, tahmin edilebilir düğümleri toplar; süre ise toplam değil, DAG üzerindeki kritik yoldur (paralel dallar çakışır).

Rolü için tamamlanmış çalıştırma geçmişi olmayan bir düğüm, sampleSize: 0 ve null aralıklar bildirir. Bu, tam olarak böyle — bilinmiyor — olarak görünür; asla uydurulmuş bir nokta değeri olarak değil, çünkü güvenemeyeceğiniz bir tahmin, hiç tahmin olmamasından kötüdür. Bazı düğümlerin geçmişi olup bazılarının olmadığında toplam kısmi olarak işaretlenir. Etki alanı yalnızca bir düğüm symbol veya file kaynak referansı bildirdiğinde görünür; bunlara sahip olmayan bir düğüm, düzyazıdan çıkarım yapmak yerine “bilinmiyor” olarak kalır.

Tek onay, ardından deterministik yürütme

İşte temel fikir: ajan planlar; deterministik bir işlev yürütür. Onayladığınızda, LLM’siz ve I/O’suz saf bir işlev olan OrchestrationMaterializer, öneriyi gerçek bir pipeline’a dönüştürür. Aynı öneri ve aynı çözümlenmiş roller verildiğinde her zaman aynı DAG’ı üretir. Bu önemlidir, çünkü üretilen pipeline, motorun hâlihazırda bedavaya sunduğu her şeyi devralır: yeniden başlatmalar arasında askıya alma ve sürdürme, çökme kurtarma, çalıştırma başına maliyet ve token toplamları ile çalıştırma ayrıntısı arayüzü.

Onay ayrıca işin ihtiyaç duyduğu iskeleti oluşturur:

yeni olarak işaretlenmiş rollerin işe alımını yapar (ve işe alınan ajan kimliklerini kaydeder, böylece onay sırasındaki bir çökme yinelenen işe alımlar olmadan sürdürülebilir)
rolleri gruplayan bir ekip
üst bileti kaydeden bir proje
tüm bunları yürüten pipeline şablonu + çalıştırma

Yaşam döngüsü

proposed → approved → executing → synthesizing → completed
                  ↘                 ↘              failed
                   ↘                 ↘            cancelled

Durum	Anlamı
`proposed`	Plan hazır ve tek seferlik ön onayınızı bekliyor
`approved`	Onayladınız; materyalizasyon sürüyor (işe alımlar, ekip, proje, pipeline)
`executing`	Üretilen pipeline çalışıyor: alt biletler, tartışma, iş
`synthesizing`	Alt biletler tamamlandı; sentez adımı teslimatı üretiyor
`completed`	Bitti: üst bilet tamamlandı olarak işaretlenir ve teslimat paylaşılan alanda yayımlanır
`failed`	Materyalizasyon başarısız oldu ya da üretilen pipeline çalıştırması başarısız oldu
`cancelled`	İptal ettiniz

Orkestratör öneriyi hâlâ proposed durumundayken revize ederken, monoton bir revizyon numarası öneriyi izler; uygulama hangi revizyonu onayladığınızı kaydeder. propose_orchestration, durum artık proposed olmadığında bir revizyonu reddeder.

Bir orkestrasyon her zaman bir üst bilete karşı açılır ve tek bir tartışma alanını paylaşır; böylece tüm çaba tek bir iş öğesine kadar izlenebilir ve ekip tek bir odada konuşur.

Bitince ne olur

Açık tutulan bir dinleyici, üretilen pipeline’ı izler ve nihai durumunu orkestrasyona ve üst bilete geri eşler; böylece tamamlanma ve başarısızlık, zaten takip ettiğiniz yerlerde görünür. Orkestrasyon özelliğinin kendi yürütme motoruna ihtiyacı yoktur.

Bir orkestrasyonu istediğiniz zaman iptal edebilirsiniz; iptal, yürütülmekte olan işi söker.

Ayrıca bakınız

Pipeline’lar ve otomasyon: materyalize edilmiş bir orkestrasyonun üzerinde çalıştığı motor
Biletler ve devretme: bir orkestrasyonun dayandığı üst bilet
Ajan modeli: bir orkestrasyonun doldurduğu veya işe aldığı roller
Bir orkestrasyon çalıştırma
Plan Studio’da çalışma