29 Eyl 2026

Agentic Harness Nedir: OpenRig ile Multi-Agent Takım Yönetimi

Dün Hermes’ten bahsettik. Hermes, bir ajanı çalıştırmak için ihtiyaç duyduğunuz araçları ve yönetimi bir çatı altında toplar. Ama Hermes’in hedefi daha geniş—ChatGPT ile konuşmadan tutun web hizmetlerine bağlanmaya kadar, her türlü ajanı yönetir.

Bugün başka bir açı bakıyoruz. Yazılım geliştirmede, üstünüz birden fazla kodlama ajanına ihtiyacı var. Claude Code bir şey yazıyor, Codex başka bir şey yapıyor, ikisi bir projede aynı depodan çalışıyor. Peki bunu nasıl düzenle? Kaç terminal açacaksın? Birinin çıktısı diğerine nasıl gidecek? Takım içinde kim ne yaparsa yanılır?

OpenRig, bu sorunun çözümü.

Multi-Agent Takımı vs. Terminallerin Çöplüğü

Yazılım geliştirmede şu sık görülen senaryo var:

Sabah, geliştirici makinesinde 5 terminal penceresi var.

Terminal 1: Claude Code yazıyor.
Terminal 2: Codex kontrol ediyor.
Terminal 3: İnsan bir betik çalıştırıyor.
Terminal 4: Git log’ları kıyaslıyor.
Terminal 5: Bir sorunun kaynağını araştırıyor.

Makiney yeniden başlat. Terminal pencereleri kapanır. Kontekst kaybolur. Kim ne yapmıştı? Hangi değişiklik hangi ajanın? Ajan çıkmazda (deadlock) mı kaldı?

OpenRig bunu düzenliyor. Açıyorsun, ekran görüntüsü alıyor. Kapatırsan, durumunu kaydediyor. Açarsın, kaldığı yerden başlıyor.

Harness olmadan, ajanlar terminal spreyidir. Harness ile, bir takım.

OpenRig Nedir?

OpenRig, açık kaynak multi-agent harness’idir. Bir rig (takım), YAML dosyasında tanımlanır.

# rig-spec.yaml
rig:
  name: "blog-development"
  pods:
    - name: "writer"
      harness: Claude Code
      model: Claude 3.5 Sonnet
      context_size: 200k
    
    - name: "editor"
      harness: Codex
      model: Claude 3.5 Sonnet
      context_size: 100k

  edges:
    - from: "writer"
      to: "editor"
      type: "review"

Sonra:

rig up blog-development --cwd .

OpenRig, tmux oturumlarını başlatır, her agana bir “seat” (koltuk) verir, ortam değişkenlerini ayarlar, onları projeye bağlar, ve hepsi aynı depodan çalışabilir.

OpenRig’in Temel Özellikleri

1. Takım Tanımı YAML’da. Takımı kod olarak tanımlar—version control’de tutar. “Takım şimdi kim var, hangi model, hangi bağlantılar?” sorusu git log’ta cevap bulur.

2. Bağlantılar ve Akış. Agent A’nın çıktısı Agent B’ye gider. Kimin çalıştığını, kimin sonucu beklediğini, kimin veto yapabileceğini tanımlar.

3. Durum Kalıcılığı (State Persistence). Bir agentın oturumunu kapatarsan, durumunu kaydeder. Saatler sonra açarsan, o kontekst hâlâ orada. Sohbet tarihi, yapılan işler, hataların kayıtları—hepsi kalıcı.

4. Terminal Yönetimi. Tmux ile terminal pencerelerini yönetir. Her agent kendi penceresi (pane). Ekrana bakarsın, kim aktif, kim bekliyor, kim hata verdi—görünür.

5. İzlenebilirlik (Observability). Her agent’ın yaptığı adım, çıktısı, hata mesajı kayıt altında. Bir ajan bir hata yaptıysa, tam geçmişi izlenebilir.

6. Çoklu Harness Desteği. Claude Code, Codex, başka yazılım ajanları—aynı takıma katılabilir. Hepsi OpenRig’in yönetiminde.

Senaryo: Yazılım Geliştirme Takımı

Bir blogumuz var, yazılar yazıyoruz. İki ajan kullanıyoruz:

Writer Agent (Claude Code): Makaleyi yazar.
Editor Agent (Codex): Yazıyı gözden geçirir, düzelting önerilerine yapar.

OpenRig’te şöyle tanımlanır:

rig:
  name: "blog-team"
  pods:
    - name: "writer"
      harness: Claude Code
      model: Claude 3.5 Sonnet
    
    - name: "editor"
      harness: Codex
      model: Claude 3.5 Sonnet

  edges:
    - from: "writer"
      to: "editor"
      type: "review"

Sabah:

rig up blog-team --cwd /path/to/blog
rig tui --shared  # Terminal UI açılır

Ekranda iki koltuğun durum tabelosu görünür:

Koltuk	Runtime	Model	Durum	Kontekst
writer	Claude Code	Claude 3.5	Çalışıyor	45k token
editor	Codex	Claude 3.5	Bekliyor	0

Writer’a bir görev verilir:

rig send writer@blog-team "Write an article about OpenRig"

Writer başlıyor, makale yazıyor. OpenRig, çıktıyı kaydediyor.

Makale tamamlandığında:

rig send editor@blog-team "Review the article from writer and provide feedback"

Editor, writer’ın çıktısını alıyor (OpenRig otomatik olarak bağlıyor), inceliyor, geridönüş yazıyor.

Makine yeniden başlarsa, bütün bu geçmiş kayıt altındadır. Sabahki oturuma dön:

rig up blog-team --cwd /path/to/blog

OpenRig, önceki durum veya son konteksti geri yükler. Takım kaldığı yerden başlar.

Organizasyonda Neden Kritik?

Bir şirket 10 yazılım ajanı çalıştırıyorsa, her biri terminal spreyidir. OpenRig bunu 10 koltuklu, tanımlanmış bir takıma dönüştürür.

Yöneticiye:

Kim ne yaptı?
Hangi agent hangi işin sahibi?
Bir agent yanılıp hata yaptıysa, geçmişi nedir?

OpenRig ile, takım durumunu bir tablo’da görürsün. Geçmiş kalıcıdır. Kararlar izlenebilir.

Açık kaynak olması kritik. Kodunu okuyabilir, kendi ajanlarını ekleyebilir, kendi sistemine uyarlamabisler.

Cloudflare, AWS Serverless vs. OpenRig

Cloudflare Durable Objects, bir agentı yönetir. AWS Lambda, stateless’tir. OpenRig, açık kaynak ve self-hosted—sizin altyapınızda çalışır.

Uzun vadede, ajanları kendi sistemde yönetmek daha ucuz ve kontrollüdür.

Sonuç

OpenRig, yazılım geliştirmede AI ajanlarını “takım” yapmanın harness’idir. Terminaller yerine, tanımlanmış, denetlenebilir, kalıcı bir sistem.

Bu dörtten birinin (Hermes, buzz, cloudflare os, openring) açık kaynak harness’i seçmek, ajanlarını düzenli tutmanın ilk adımı. Her harness farklı bir domain’e odaklanır—Hermes genel amaçlı, OpenRig yazılım geliştirmeye—ama hepsi bir ilkiye bağlı: ajanlar araçlar değil, varlıklardır; bir çatı ile yönetilmeleri gerekir.

Bu harness’lerin ötesinde, ajanları organizasyon şemanızda tanımlamak, politika dosyaları yazmak, delegasyon kayıtlarını tutmak gerekir. agentic-organization tamı bu: ajanları self-hosted, dosya-tabanlı bir sistem ile organizasyon şemasında tanımladığınız yer. OpenRig bir oturum takımını yönetirken, agentic-organization ajanları uzun vadede organizasyon varlığı olarak kurumsallaştırır.