Agent Teams - Claude Code oturum ekip orkestrasyonu

• Birden fazla Claude Code instance’ını tek bir ekipte birleştirip işleri paralel şekilde dağıtan ve koordine eden deneysel bir özellik; lider oturum ekip üyelerini oluşturur, görevleri atar ve sonuçları birleştirir
• Mevcut subagent’lardan farklı olarak ekip üyeleri birbirleriyle doğrudan mesajlaşabilir; kullanıcı da lider üzerinden geçmeden tek tek ekip üyeleriyle doğrudan iletişim kurabilir
• Kod inceleme, hata ayıklama hipotezlerini paralel araştırma ve frontend·backend·test gibi katmanlar arası çalışmalar için etkilidir; sıralı işler veya aynı dosyada düzenleme için tek oturum daha uygundur
• Her ekip üyesinin bağımsız bir context window’u olduğundan token kullanımı önemli ölçüde artar ve maliyet ekip üyesi sayısıyla orantılı olarak büyüyebilir
• tmux veya iTerm2 üzerinden bölünmüş ekran modunu destekler; paralel keşif ve işbirliği otomasyonu sayesinde karmaşık geliştirme işlerinde üretkenlik ve kalite artışı sağlar

---

Agent Teams’e genel bakış

• Birden fazla Claude Code oturumunu tek bir ekip birimi olarak koordine ederek işleri paralel yürütür
  • Ekip lideri işleri dağıtır ve sonuçları birleştirir
  • Her ekip üyesi bağımsız bir context window içinde ayrı ayrı çalışır
• Subagent’tan farklı olarak ekip üyeleri arasında doğrudan mesajlaşma mümkündür
• Deneysel bir özelliktir ve varsayılan olarak kapalıdır; CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS ortam değişkeni ayarlanarak etkinleştirilir

Agent Teams ne zaman kullanılmalı

• Araştırma ve inceleme: Birden çok ekip üyesi bir sorunun farklı yönlerini aynı anda inceler, ardından sonuçları paylaşır ve karşılıklı doğrular
• Yeni modül veya özellik geliştirme: Ekip üyelerinin her biri ayrı dosya/modül üstlenerek çakışma olmadan paralel çalışır
• Rekabet eden hipotezlerle hata ayıklama: Farklı hipotezleri aynı anda test ederek kök nedeni daha hızlı bulur
• Katmanlar arası koordinasyon: Frontend, backend, test gibi katmanlara ekip üyeleri yerleştirilerek eşzamanlı değişiklik yapılır
• Sıralı işler, aynı dosyada düzenleme ve bağımlılığı yüksek görevler için tek oturum veya subagent daha verimlidir

Subagent vs. Agent Team

• Subagent: Kendi context window’una sahiptir ama sonuçları yalnızca çağırana döner; tüm işi ana agent yönetir ve token maliyeti görece düşüktür
• Agent team: Tamamen bağımsız context window’lara sahiptir; ekip üyeleri arasında doğrudan mesaj alışverişi mümkündür, paylaşılan görev listesiyle kendi kendini koordine eder; her ekip üyesi ayrı bir Claude instance’ı olduğundan token maliyeti yüksektir
• Yalnızca sonuç gereken odaklı işler için subagent, ekip üyeleri arasında tartışma ve işbirliği gerektiren karmaşık işler için agent team uygundur

İlk agent team’i başlatma

• Varsayılan olarak devre dışıdır; etkinleştirmek için CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS ortam değişkenini 1 yapın veya settings.json içine ilgili ortam değişkenini ekleyin
• Etkinleştirdikten sonra doğal dille ekip yapısını ve işi açıklarsanız, Claude ekibi oluşturur, ekip üyelerini spawn eder ve işi koordine eder

  • I'm designing a CLI tool that helps developers track TODO comments across their codebase. Create an agent team to explore this from different angles: one teammate on UX, one on technical architecture, one playing devil's advocate.

  • TODO takibi için bir CLI aracı tasarlarken, UX, teknik mimari ve karşıt görüş rolündeki üç ekip üyesinin konuyu bağımsız biçimde inceleyip sonuçları birleştirmesi
  • Bu şekilde Claude, paylaşılan görev listesini ekip üyelerini tek tek oluşturup her sorunu araştırmak, sonuçları birleştirmek ve iş tamamlandığında ekibi temizlemek için kullanmaya çalışır
• Lider terminalinde tüm ekip üyeleri ve görev durumları gösterilir; Shift+Up/Down ile ekip üyesi seçip doğrudan mesaj gönderebilirsiniz

Agent team kontrolü

• Görüntüleme modu seçimi

  • In-process modu: Tüm ekip üyeleri ana terminal içinde çalışır; Shift+Up/Down ile ekip üyesi seçilir ve mesaj gönderilir; ek ayar gerekmez
  • Split panes modu: Her ekip üyesi ayrı bir panelde gösterilir; çıktılar aynı anda görülebilir; tmux veya iTerm2 gerekir
  • Varsayılan "auto", tmux oturumu içinde çalışıyorsa split pane, değilse in-process olarak davranır
  • "tmux" ayarı split-pane modunu etkinleştirir ve tmux ile iTerm2’yi otomatik algılar
  • settings.json içindeki teammateMode ile geçersiz kılınabilir veya tek oturum ayarı için claude --teammate-mode in-process bayrağı kullanılabilir

• Ekip üyesi ve model belirtme

  • Claude göreve göre ekip üyesi sayısını otomatik belirler; ancak "Create a team with 4 teammates" gibi bir komutla tam sayı ve modeli (ör. Sonnet) doğrudan belirtebilirsiniz

• Plan onayı isteme

  • Karmaşık veya riskli işlerde ekip üyelerine salt okunur plan modu uygulanarak, lider onay verene kadar implementasyon engellenebilir
  • Ekip üyesi planı tamamladığında lidere onay isteği gönderir; lider onaylarsa implementasyon başlar, reddederse geri bildirim yansıtılarak yeniden gönderilir
  • Liderin karar ölçütleri prompt içinde koşul verilerek etkilenebilir (ör. "Yalnızca test kapsamını içeren planları onayla")

• Delege (Delegate) modu

  • Liderin işi bizzat uygulamak yerine yalnızca koordinasyon araçlarını (ekip üyesi spawn etme, mesajlaşma, sonlandırma, görev yönetimi) kullanması için sınırlandırılır
  • Ekibi başlattıktan sonra Shift+Tab ile delege moduna geçin

• Ekip üyeleriyle doğrudan konuşma

  • Her ekip üyesi tamamen bağımsız bir Claude Code oturumu olduğundan, ek talimatlar, takip soruları veya yaklaşım değişiklikleri doğrudan iletilebilir
  • In-process modunda Shift+Up/Down ile seçip mesaj gönderin, Enter ile oturumu görüntüleyin, Escape ile mevcut turu durdurun, Ctrl+T ile görev listesini açıp kapatın
  • Split-pane modunda ilgili panele tıklayarak doğrudan etkileşim kurun

• Görev atama ve üstlenme

  • Paylaşılan görev listesi üzerinden ekip genelindeki işler koordine edilir; görev durumları pending, in progress ve completed olmak üzere üç aşamadır
  • Görevler arasında bağımlılık tanımlanabilir; çözülmemiş bağımlılığı olan görevler üstlenilemez
  • Lider görevi açıkça atayabilir veya ekip üyesi bir işi bitirdikten sonra sıradaki atanmamış ve engellenmemiş görevi otomatik olarak üstlenebilir
  • Aynı görevin birden fazla ekip üyesi tarafından aynı anda üstlenilmesini önlemek için file lock kullanılır

• Ekip üyesini sonlandırma ve ekibi temizleme

  • Lider belirli bir ekip üyesinin sonlandırılmasını isteyebilir; ekip üyesi bunu onaylayabilir veya reddedebilir ve gerekçesini açıklar
  • Ekip temizlenirken lider paylaşılan ekip kaynaklarını kaldırır; aktif ekip üyeleri kaldıysa temizleme başarısız olur, bu yüzden önce onların sonlandırılması gerekir

Agent team’in içeride nasıl çalıştığı

• Ekibi başlatma yolları

  • Kullanıcı ekibi ister: Paralel çalışmaya uygun bir görevi açıklayıp açıkça agent team oluşturulmasını ister
  • Claude ekip önerir: Claude, işin doğası gereği paralel işlemenin avantajlı olduğunu düşünürse ekip oluşturmayı önerir; kullanıcı onaylarsa devam eder
  • Her iki durumda da kullanıcı onayı olmadan ekip oluşturulmaz

• Mimari bileşenler

  • Team lead: Ana Claude Code oturumu; ekip oluşturma, ekip üyesi spawn etme ve işi koordine etmeden sorumludur
  • Teammates: Ayrı Claude Code instance’ları; her biri kendisine atanan görevi yürütür
  • Task list: Ekip üyelerinin üstlenip tamamladığı paylaşılan iş öğeleri listesi
  • Mailbox: Agent’lar arası iletişim için mesajlaşma sistemi
  • Görev bağımlılıkları otomatik yönetilir; bir ekip üyesi görevi tamamladığında engelli görevler manuel müdahale olmadan açılır
  • Ekip ayarları ~/.claude/teams/{team-name}/config.json, görev listesi ise ~/.claude/tasks/{team-name}/ altında yerel olarak saklanır
  • config içindeki members dizisi her ekip üyesinin adı, agent ID’si ve agent türünü kaydeder

• Yetkiler

  • Ekip üyeleri liderin izin ayarlarını devralarak başlar; lider --dangerously-skip-permissions ile çalışıyorsa tüm ekip üyelerine de aynı durum uygulanır
  • Spawn sonrasında tek tek ekip üyelerinin modu değiştirilebilir, ancak spawn anında ekip üyesi bazlı izin ayarı yapılamaz

• Context ve iletişim

  • Her ekip üyesinin bağımsız bir context window’u vardır; spawn sırasında CLAUDE.md, MCP sunucuları, yetenekler gibi normal oturumla aynı proje context’i yüklenir
  • Liderin konuşma geçmişi ekip üyelerine aktarılmaz; yalnızca spawn prompt’u iletilir
  • Otomatik mesaj iletimi: Ekip üyelerinin gönderdiği mesajlar alıcıya otomatik iletilir; liderin polling yapması gerekmez
  • Boşta kalma bildirimi: Ekip üyesi işi bitirip durduğunda lidere otomatik bildirim gider
  • Paylaşılan görev listesi: Tüm agent’lar görev durumunu görebilir ve müsait işleri üstlenebilir
  • Mesajlaşma türleri olarak message (tek bir ekip üyesine) ve broadcast (tüm ekip üyelerine; maliyet ekip boyutuyla orantılı olduğundan dikkatli kullanılmalı) bulunur

• Token kullanımı

  • Agent team’lerde token kullanımı, tek oturuma kıyasla belirgin biçimde artar ve aktif ekip üyesi sayısıyla orantılı büyür
  • Araştırma, inceleme ve yeni özellik geliştirmede ek token maliyeti genellikle karşılığını verir; ancak rutin işlerde tek oturum daha maliyet etkindir

Kullanım örnekleri

• Paralel kod inceleme

  • Tek bir reviewer aynı anda yalnızca belirli bir sorun türüne odaklanma eğiliminde olduğundan, inceleme kriterleri güvenlik, performans, test kapsamı gibi bağımsız alanlara bölünebilir
  • Her reviewer aynı PR üzerinde farklı bir filtre uygular; lider de bitince tüm sonuçları birleştirir

• Rekabet eden hipotezlerle araştırma

  • Tek agent bir açıklama bulunca araştırmayı bırakma eğiliminde olabilir; bu yüzden ekip üyeleri açıkça çatışmalı bir yapı içinde düzenlenir
  • Her ekip üyesi kendi hipotezini araştırırken aynı anda diğer ekip üyelerinin teorilerini çürütmeye çalışır; bu bir bilimsel tartışma yaklaşımıdır
  • Sıralı araştırmada ortaya çıkan anchoring bias’ı önler ve ayakta kalan teorinin gerçek kök neden olma ihtimalini artırır

En iyi uygulamalar

• Ekip üyelerine yeterli context sağlayın: Proje context’i otomatik yüklenir ama liderin konuşma geçmişi aktarılmaz; bu nedenle spawn prompt’una işle ilgili ayrıntılar eklenmelidir
• Görev boyutunu doğru ayarlayın: Çok küçükse koordinasyon ek yükü faydayı aşar; çok büyükse uzun süre ara kontrol olmadan çalışılıp israf riski artar; fonksiyon, test dosyası, inceleme gibi net çıktı üreten, kendi içinde tamamlanan birimler uygundur
• Lider ekip üyeleri yerine doğrudan implementasyona başlarsa "Wait for your teammates to complete their tasks before proceeding" şeklinde yönlendirin
• İlk kullanımda, kod yazımı gerektirmeyen ve sınırları net olan araştırma ve inceleme işleriyle başlayın (PR incelemesi, kütüphane araştırması, hata incelemesi gibi)
• Dosya çakışmalarını önleyin: İki ekip üyesi aynı dosyayı düzenlerse üzerine yazma olabilir; bu yüzden işleri her ekip üyesine farklı dosya kümeleri düşecek şekilde bölün
• Ekip üyelerinin ilerlemesini düzenli olarak kontrol edin, etkisiz yaklaşımlarda yön değiştirin ve sonuçları geldikçe birleştirin

Sorun giderme

• Ekip üyeleri görünmüyorsa: In-process modunda Shift+Down ile aktif ekip üyeleri arasında dolaşın; işin ekip kurmayı gerektirecek kadar karmaşık olup olmadığını kontrol edin; split pane istendiğinde tmux’ın PATH içinde kurulu olduğunu doğrulayın; iTerm2 için it2 CLI’ın kurulu ve Python API’nin etkin olduğunu kontrol edin
• Aşırı izin prompt’ları: Ekip üyelerinin izin istekleri lidere bubble up olur; bu nedenle ekip üyesi spawn etmeden önce izin ayarlarında ortak işleri önceden onaylayın
• Ekip üyesi hata sonrası durursa: O ekip üyesinin çıktısını inceleyin, doğrudan ek talimat verin veya işi sürdürmesi için yedek bir ekip üyesi spawn edin
• Lider iş bitmeden çıkarsa: Lidere devam etmesi talimatını verin veya delege moduna geçmeden önce ekip üyelerinin bitmesini bekleyecek şekilde ayarlayın
• Yetim tmux oturumları: Ekip kapandıktan sonra tmux oturumu kalırsa tmux ls ile kontrol edin ve tmux kill-session -t <session-name> ile kaldırın

Kısıtlar

• In-process ekip üyelerinde oturum geri yükleme yok: /resume ve /rewind, in-process ekip üyelerini geri yüklemez; geri yükleme sonrası lider artık var olmayan ekip üyelerine mesaj göndermeye çalışabilir, bu durumda yeni ekip üyeleri spawn edilmelidir
• Görev durumu gecikmesi: Ekip üyesi görevi tamamlandı olarak işaretlemezse bağımlı görevler engellenmiş kalabilir; durumu manuel güncelleyin veya liderden ekip üyesini uyarmasını isteyin
• Sonlandırma gecikmesi: Ekip üyesi ancak mevcut isteğini veya tool çağrısını tamamladıktan sonra sonlanır
• Oturum başına yalnızca bir ekip: Yeni bir ekip başlatmak için önce mevcut ekip temizlenmelidir
• İç içe ekip yok: Ekip üyeleri kendi ekiplerini veya ekip üyelerini spawn edemez; ekip yönetimi yalnızca lidere aittir
• Lider sabittir: Ekibi oluşturan oturum, o ekibin kalıcı lideridir; bir ekip üyesi liderliğe yükseltilemez veya liderlik devredilemez
• Spawn sırasında toplu izin ayarı: Tüm ekip üyeleri liderin izin moduyla başlar; spawn anında ekip üyesi bazında izin ayarı yapılamaz
• Split pane için tmux veya iTerm2 gerekir: VS Code entegre terminali, Windows Terminal ve Ghostty’de split-pane modu desteklenmez

[kuthia]

Çoklu ajan orkestrasyonu için, bağlam sıkıştırma sürecinde anlamsal sonuçların nasıl korunacağı önemli hale gelecek gibi görünüyor. Biraz bilişsel bilim gibi.

[GN⁺]

Hacker News yorumları

• Son 1 yıldaki yeniliklerin büyük ölçüde mühendislik odaklı ilerlemiş olması ilginç
  MCP, agent, skill gibi yeni kavramlar ortaya döküldü ama halüsinasyon, hatalılık ve bağlamın çökmesi gibi temel sorunlar hâlâ çözülmedi
  Bu tür sorunlar, basit mühendislikten ziyade ancak temel araştırma ile çözülebilecek gibi görünüyor
  Şu anki iyileştirmeler ve duyurular, yatırımcı beklentilerini canlı tutmaya yönelik hype cycleın bir parçası gibi hissettiriyor
  Açıkçası yapay zeka anlatısından yoruldum; bu teknolojinin gerçekte nerede faydalı olduğunun netleştiği aşamaya bir an önce geçmek istiyorum

• Bu tür özellikler havalı ama bütün gün agent çalıştırabilecek kaç kişi var, emin değilim
  Cursor kullanırken token tüketimi çok yüksek olduğu için Ultra'ya yükselttim ama kullanımın buna orantılı olmadığını hissediyorum
  Neyse ki açık kaynak LLM tarafı hızla yetişiyor; bu da umut verici

  • Ben Claude Max'in aylık 200 kullanım sınırını bile dolduramıyorum. Her gün kod yazıyorum ve oldukça ağır işler yapıyorum ama yine de öyle
  • Bunlar fiilen hâlâ deney aşamasında; Gas Town gibi başarısız da olabilir
  • Birçok şirket yıllık 150 bin dolarlık junior mühendisi işe alabilir. AI abonelik ücreti bundan pahalıysa ortada bir sorun vardır
    Üstelik burada konuşulan şey Cursor değil, Claude Code. Ben olsam Claude Max'i denemenizi öneririm
  • Bunu bütün gün çalıştırabilecek olanlar muhtemelen ancak VC fonu almış 2 kişilik startuplardır
  • Claude Code Max, token birim fiyatına göre 30 kat değer sunuyor; bunu bitiremiyorsanız sorun sizdedir. Elektrik faturasından bile ucuz olabilir

• Steve Yegge zamanında Anthropic gibi şirketlere agent orchestrator fikrini önermişti
  (Welcome to Gas Town)
  Anthropic'in şimdi Agent Teams'i çıkarmış olmasına bakılırsa, ya o zamandan beri hazırlanıyorlardı ya da aynı sonuca vardılar
  Her hâlükârda Steve'in vizyonunun doğrulanmış olması ilginç. Yakında “polecat evcilleştirme” sezonu başlayabilir

  • Ben de GasTown ya da Beeds'i bilmiyordum ama benzer bir şey yaptım. Bu çok doğal bir sonraki adımdı
    claude-code-orchestrator
  • Ben de GasTown çılgınlığından önce basit bir agent takım yapısı kurmuştum. Birden fazla Claude instance'ını tmux oturumlarında çalıştırıp .claude.lock ile senkronize ettim
    Oldukça iyi çalıştı ama henüz verimli değil. Spec yazma hızı ve QA kalitesi darboğaz oluşturuyor
  • Aslında bu yapı actor frameworklerde zaten var olan bir kavram. Akka gibi sistemlerle karşılaştırınca burada yeni bir şey yok
    LLM sağlayıcılarının bunları ancak şimdi öğreniyor olması, gerçek zamanlı olarak büyüdüklerini düşündürüyor
    Agents için Kubernetes demek de abartı değil. Ben de bunu lokalde bu şekilde birbirine bağlıyorum
  • Anthropic mühendislerinin bu fikirlerden habersiz olduğuna inanmıyorum. ChatGPT'nin ilk günlerinden beri bunlar konuşuluyordu
  • Aslında bu tür multi-agent sistemler 2023'ten beri arXiv ve GitHub'da bolca vardı
    O zamanlar modeller daha az zekiydi ve context window küçüktü; şimdi ise bunlar yeterince mümkün hâle geldi

• Birden fazla Claude Code instance'ını tmux tabanlı CLI agent olarak çalıştırıp iş birliği yaptıran bir workflow kullanıyordum
  Bu yeni orchestration özelliği, ortak bir task list paylaşılması ve ana agent'ın koordinasyonu sayesinde çok daha kullanışlı
  tmux-cli aracı ile agent'lar arası iş birliği otomatikleştirilebiliyor

• Bunun bir gün varsayılan olarak yerleşik olacağı belliydi, o yüzden şimdiye kadar öğrenmedim ama artık deneme zamanı gelmiş gibi görünüyor

• Aylık 20 dolarlık aboneliğimin 10 dakika bile dayanmayacağından endişeliyim

  • Kişi ücreti cebinden ödüyorsa Kimi ya da GLM kullanmak daha mantıklı
  • Ben de aynı fikirdeyim. Böyle bir yapının gerçekten değer üretip üretemeyeceği konusunda şüpheliyim
  • Bazı işlerde Haiku oldukça iyi sonuç verdi

• Bu, Gas Town'a benziyor

  • Bir proje fazla acayip ya da şakacı bir yöne giderse, sonunda daha az çocukça bir klon çıkıp kazanabilir
  • Ama polecat nereye kayboldu, piyasanın mizah anlayışını merak ediyorum
  • Gas Town'ın ne olduğunu bilmiyorum ama ben zaten Claude Code Agent Teams'e benzer bir yapı kullanıyordum
    Ana konuşma içinden alt agent oluşturup işleri ayırınca, bağlam kaybı olmadan uzun süre çalışabiliyorlar
  • Tasarım daha basit görünüyor. Tek bir lider agent ve çok sayıda worker yapısı, Gas Town'ın karmaşık rol sisteminden daha temiz
  • Ama polecat'in olmaması üzücü

• Claude Code'u büyük işleri bağımsız biçimde üstlenmesi için kullanamıyorum
  Kod kalitesini korumak için tasarım sürecine bizzat müdahil olmam gerekiyor
  Agent takımları ise sanki yalnızca inceleme ve refactor yükünü artıracakmış gibi geliyor

  • Kod tabanının yapısını ve pattern kullanım kurallarını skill olarak kodlarsanız, alt agent'ların bunları denetlemesini sağlayabilirsiniz
    Planlama, tasarım, QA ve review agent'larını ayırıp birlikte çalıştırmak zaten bu özelliğin özü
  • Claude içinde adversarial model kurup kaliteyi yükseltmenin yolları da var. Bir agent değişiklik yapar, diğeri doğrular
  • İnsanlar da büyük işleri parçalara bölerek yapıyor; Claude'a plan ve test kriterleri koydurursanız daha verimli oluyor
  • Gerçekte 3-4 denemeden birinde ayar ya da durdurma gerekiyor. Bunu ancak deneyimli kişiler fark ediyor
  • LLM'lerin iş bölümü yapması ve sonuçları birleştirmesi üzerine araştırmalar da sürüyor
    ilgili makale

• Ana model olarak Opus, alt agent'lar için ise Gemini ya da Codex kullanan bir çoklu LLM orkestrasyonu arıyorum

  • Bu yapıyı destekleyen araçlar arasında Coder-Codex-Gemini, ccg-workflow, claude_code_bridge var
    Hepsi Çinli geliştiriciler tarafından yapılmış projeler ama denediğim kadarıyla oldukça başarılıydılar
  • AgentWorkforce/relay kullanırsanız istediğiniz LLM'i lider/orchestrator olarak atayabilirsiniz
    Buna dair deneyimimi Twitter gönderisinde özetledim
  • Ben Opus ile kod yazıp Codex ile review yapıyorum. Her görevde review skill çağrısı ile Codex'i çalıştırıyorum
    review skill kodu, Greptile PR analizörü ile birlikte kullanıyorum
  • İleride Cursor bu tür çoklu model iş birliği özelliklerini desteklerse gerçekten çok faydalı olur
  • Pied-Piper örneğinde olduğu gibi,
    GPT-5.2 Codex Max ile planlama, Opus 4.5 ile uygulama, Gemini ile review yapılan bir yapı da mümkün

• Beads'e alternatif olarak kendi çözümümü geliştiriyordum ve sonunda GitHub projesiyle senkronize olan bir agent sistemi tamamladım
  Yakında bunu açık kaynak yapacağım; uzun vadede bilet sistemiyle entegre olmasının daha faydalı olacağını düşünüyorum
  Agent'a bağımlı olmayan agnostic alternatiflerin artması daha sağlıklı olur