Harness, Loop, Graph: Herkesin Birbirine Karıştırdığı Üç Katman

Bu üçü birbirinin alternatifi değil

Agent kelimesi çok geniş kullanılıyor. Demoda tek model çağrısı yetiyor, ekranda güzel duruyor. Aynı şeyi gerçek dosyalara, API'lara, müşteri verisine, production koduna bağladığın anda iş değişiyor. Artık prompt yazmıyorsun. Sistem kuruyorsun.

O sistemin içinde sürekli birbirine karışan üç şey var:

• agent harness engineering
• loop engineering
• graph engineering

Üçü de modelin etrafında duruyor. Üçünde de döngü olabiliyor. Üçü de güvenilirliği etkiliyor. Ama farklı problemleri çözüyorlar. Karıştırdığın anda yanlış katmanı debug etmeye başlıyorsun. Ben en çok zamanı tam olarak burada kaybettim: prompt'u on kere değiştirip duruyorsun, halbuki sorun tool'un yanlış veri döndürmesinde.

30 saniyelik cevap

• Harness, modelin çalışacağı ortamı kurar.
• Loop, işin tekrar edip düzeldiği döngüyü tasarlar.
• Graph, hangi adımdan sonra neye izin verildiğini açık hale getirir.

Aklında tutması kolay hali: ortam, geri bildirim, akış.

1. Harness

Ham model tek başına iş yapamaz. Session'lar arasında state tutamaz, tool'u güvenli çağıramaz, izin sınırı uygulayamaz, başarısız işi tekrar denemez, çıktısının doğru olduğunu kanıtlayamaz, doğru anda duramaz. Bunların hepsi etrafındaki sistemden gelir.

Ciddi bir harness'ta genelde şunlar oluyor:

Context injection. Model davranmadan önce ne görüyor: talimatlar, retrieval sonucu, konuşma state'i, memory, politika, göreve özel kurallar.

Action surface. Ne yapabiliyor: API çağrısı, browser, shell, kod çalıştırma, MCP tool'ları, veritabanı.

Persistence. Ne kalıcı: dosyalar, checkpoint'ler, ilerleme logu, git geçmişi, uzun vadeli memory.

Execution control. Koşu nasıl yönetiliyor: retry, timeout, budget, model seçimi, subagent açma, onay kapıları.

Güvenlik. Least privilege, isolation, allowlist, secret yönetimi, insan onayı.

Observability. Trace, tool input/output, state geçişleri, latency, maliyet, eval sonucu.

Aynı modeli kullanan iki ekip tamamen farklı sonuç alabiliyor. Fark modelde değil. Birinde temiz tool'lar, stabil state, net izinler ve görünür bir execution var. Diğerinde belirsiz bir prompt, dağınık tool'lar, gürültülü context ve hiçbir doğrulama yok. Model aynı, çalışma koşulları farklı.

Ne zaman gerek yok: Ayda bir çalıştırdığın bir script'e permission modeli, checkpoint sistemi ve trace altyapısı kurmak çoğu zaman israf. Harness kurmanın bir bakım maliyeti var ve o maliyet sana geri döner. İş küçükse, tek seferlikse ve hata durumunda kaybedeceğin şey birkaç dakikaysa, düz bir script yeterli.

Bir de şu var: tool sayısı arttıkça agent iyileşmiyor. Tam tersi oluyor. Fazla tool seçim hatası, gürültülü context ve daha geniş bir risk yüzeyi demek. İyi bir harness kalabalık değil, dar ve net.

2. Loop

Tool kullanan her agent'ın zaten küçük bir döngüsü var: modeli çağır, sonucu gör, tool çalıştır, gözlemi geri ver, bitene kadar tekrarla.

Loop engineering, bunun üstüne bilinçli olarak kurduğun döngülerle başlıyor. Tekrar sormak değil. Retry atmak da değil. Gerçek bir iş ve geri bildirim sistemi.

İyi bir loop'un parçaları:

• Trigger. Yeni döngüyü ne başlatıyor? Kullanıcı isteği, düşen test, yeni doküman, zamanlanmış koşu, webhook.
• Goal. Hangi somut duruma ulaşmaya çalışıyoruz? "Daha iyi olsun" hedef değil.
• State. Bir sonraki döngünün bilmesi gereken ne var? Son taslak, önceki deneme, tool sonuçları, hatalar.
• Action policy. Agent neye izinli? Düzenlemek, tool çağırmak, dosya yazmak, PR açmak, token harcamak.
• Evidence. Çalıştığını nereden biliyoruz? Test, schema doğrulama, citation, diff, metrik, reviewer onayı.
• Feedback. Tam olarak ne patladı? Geri bildirim kısa ve uygulanabilir olmalı.
• Stop rule. Ne zaman bitiyor? Başarı, timeout, budget bitişi, retry limiti, insana eskalasyon.

Bu işin en önemli kuralı

Güvene göre değil, kanıta göre döngü kur.

Modelin bitti demesi bir stop condition değil. Gerçek stop condition şuna benzer: testler geçiyor, schema valid, citation'lar çözülüyor, policy kontrolü temiz, reviewer onay verdi.

Prompt, model çağrı sırasında ne yapacağını söyler. Loop, çağrıdan sonra sistemin ne yapacağını belirler. Sonucu nasıl kontrol ettiği, hataya nasıl tepki verdiği, ilerlemeyi nasıl sakladığı, devam kararını nasıl aldığı, nerede durduğu. Prompt bir cevabı iyileştirir, loop bir süreci iyileştirir.

Ne zaman gerek yok: Ölçemediğin işte loop kurma. Elinde kanıt üretecek bir mekanizma yoksa döngü sadece token yakar. Metin kalitesi bunun klasik örneği. Bir yazıyı beş kere döndürüp "daha iyi yap" demek genelde ilk çıktıdan daha iyi bir yere gitmiyor, ortalamaya doğru düzleşiyor. Böyle durumlarda tek geçiş yapıp insana bırakmak hem daha ucuz hem daha iyi.

3. Graph

Graph engineering, iş akışının yapısını görünür kılıyor. Sorusu farklı: agent ne yapmalı değil, bundan sonra neye izin var.

Burada adımlar node, geçişler edge. Dallanma, paralellik, join, retry, insan müdahalesi hepsi açıkça yazılıyor. Graph sistemin kontrol haritası oluyor.

Tasarlanan şeyler şunlar: node sınırları (bu adım deterministik fonksiyon mu, LLM çağrısı mı, uzman agent mı, insan review'u mu), state schema (hangi node neyi okuyup yazabiliyor), routing koşulları (hangi kanıt işi ileri, geri ya da eskalasyona taşıyor), concurrency, cycle ve çıkışlar, durability (checkpoint nerede, kesinti sonrası nereden devam ediyor).

Ne zaman değerli: Anlamlı dallanma, onay adımları, uzmanlar arası devir, paralel iş, recovery path ve kontrol noktası gereken çok adımlı süreçler.

Ne zaman zararlı: İşin nasıl davrandığını görmeden graph çizmek. Bu en sık yapılan hata. Henüz tanımadığın bir süreci şemaya dönüştürüyorsun, iki hafta sonra o şema yanlış çıkıyor ama artık kod ona göre yazıldığı için değiştirmek pahalı. Basit işlerde graph, YAML'a gömülmüş bir if bloğuna dönüşüyor ve düz koddan daha zor okunuyor.

Doğru sıra genelde şu: önce sade bir harness, sonra gerçek trace'ler, sonra tekrar eden kalıpları görmek, en son sadece kontrol edilmeyi hak eden kısmı formalize etmek.

Üçü birlikte nasıl çalışıyor

Araştırma yapıp rapor yayınlayan bir agent düşün. Konuyu kapsamlandıracak, kaynak toplayacak, citation'ları eleyecek, taslak yazacak, hukuk kontrolünden geçecek, onay aldıktan sonra yayınlanacak.

• Harness verir: browser, arama tool'ları, dosya alanı, memory, izinler, trace, model yönlendirme.
• Loop halleder: kanıt zayıfsa kaynak toplamayı tekrarlamak, patlayan citation'ları düzeltmek, kalite eşiğine kadar taslağı puanlamak, veri eskiyince tazelemek.
• Graph kontrol eder: kapsam, araştırma, eleme, sentez, taslak, review, yayın. Yayından önce insan kapısı.

Önce teşhis, sonra tamir

Agent hiç çalışamıyorsa harness'a bak. Tool erişimi yok, state bayat, memory zayıf, izinler yanlış, hiçbir şey görünmüyor.

Neredeyse çalışıyor ama tutarsızsa loop'a bak. İlk taslak yakın ama zayıf, başarı bazen geliyor bazen gelmiyor, retry'lar kontrolsüz, bittiğinin kanıtı yok.

Sürecin kendisi karmaşıksa graph'a bak. Çok sayıda uzman, onaylar, dallanma, paralel yollar, yapılandırılmış devirler.

Modeli suçlamak en kolayı ama model bozuk API'yi, bayat state'i, eksik çıkış koşulunu ve belirsiz tool şemasını telafi edemiyor.

Bunların hiçbirinin gerekmediği durumlar

Bu kısmı atlayan çok fazla içerik var, o yüzden ayrı yazıyorum.

İş deterministikse agent kurma. Girdi belliyse ve çıktı kuralla üretilebiliyorsa fonksiyon yaz. Model koymak sadece maliyet, gecikme ve belirsizlik ekliyor.

Tek adımlık işe orkestrasyon kurma. Bir sınıflandırma, bir özet, bir dönüşüm. Bunun için tek çağrı yeterli.

Doğrulama yoksa otomasyon kurma. Çıktının doğru olduğunu makineye kanıtlayamıyorsan, kurduğun şey otomasyon değil, sadece hızlandırılmış hata üretimi.

Hacim düşükse insan daha ucuz. Günde üç kere yapılan bir iş için iki hafta harness yazmanın geri dönüşü yok.

Framework'ten başlama. Önce hangi katmanın problemi olduğunu bulmak, sonra araç seçmek. Tersi yapıldığında elinde çözülmemiş bir problem ve bir de bakımı gereken bir bağımlılık kalıyor.

Tek cümlelik test: bu işin sonucunun doğru olduğunu kısa sürede ve otomatik olarak kanıtlayabiliyor musun? Kanıtlayamıyorsan agent kurmadan önce kanıt mekanizmasını kur.

Kısa production kontrol listesi

Harness: Tool'lar dar ve dokümante mi? State kalıcı mı? İzinler least privilege mi? Duraklatıp inceleyip devam edebiliyor musun? Trace görünür mü?

Loop: Başarının kanıtı ne? Hata durumunda hangi geri bildirim dönüyor? Kaç retry var? Stop rule ne? Budget bitince ne oluyor?

Graph: Hangi yollar deterministik olmak zorunda? Ne paralel çalışabilir? İnsan kapıları nerede? Hangi state paylaşılıyor? Recovery nereden başlıyor?

Değerlendirme: Gerçek trace'leri tekrar oynatabiliyor musun? Versiyonları karşılaştırabiliyor musun? İyileşmeyi somut bir değişikliğe bağlayabiliyor musun?

Operasyon: Maliyet, latency, hata oranı, müdahale oranı ve production'daki gerçek başarı oranı takip ediliyor mu?

Kapanış

Agent konuşmalarının çoğu modelin etrafında dönüyor. Production'da farkı yaratan şey nadiren model oluyor. Modelin çalışmasını sağlayan harness, işi ölçülebilir şekilde iyileştiren loop ve akışı kontrol altında tutan graph fark yaratıyor.

Ama her işe bu üçünü kurmak gerekmiyor. Asıl beceri bu katmanları kurabilmek değil, hangisinin gerçekten gerektiğine karar verebilmek.