Policy.md Olmadan Ajan Yönetimi Neden Başarısız Olur

Geçen günler konuştuk: organizasyon şemasında her ajanın yeri olmalı, sahibi belli olmalı. Ama bu, sadece kimin sorumlu olduğunu söylüyor. Ajanın ne yapacağını, hangi kurallar içinde hareket edeceğini tanımlamıyor.

Bir insan müdür yeni bir satış temsilcisini işe alır. Onunla ilk gün ne konuşur? “Sana müşteri kazanma görevi veriyorum.” Bu yeterli mi? Hayır. Bunlar da gereklidir:

• Hangi fiyat rangede teklif verebilir?
• Hangi müşteri türüne ne kadar indirim yapabilir?
• Müşteri ödeme tarikesi istersein ne diyecek?
• Riski yüksek bir anlaşmayı kendi başına kapatabilir mi, yoksa bana sorması mı gerek?
• Her hafta bana ne raporlayacak?

İşte bunu da yazılı kural olarak belirtmek gerekir. Ajanlar için bu dosya policy.md olur.

Policy.md: Yazılı İşletme Kuralı

Özellikle otonom bir ajan (insan olmayan) için policy.md kritik önem taşır. Çünkü ajan muhabbet edemez, karşı tarafı gözlemleyerek uyum sağlayamaz. Talimat aldığında koduna yazılı kurala bakacak.

Örnek bir policy.md dosyası:

# Ajan: Destek Biletleri Tasnif Ajan (support_triager_001)

## Sorumluluğu
- Gelen destek biletlerini öncelik seviyesine göre tasnif et
- Ürün hatası veya kullanıcı hatası ayırımı yap
- Acil hatalar için anında teknik takıma kaydet

## Erişim (Becerileri)
- Tool: Destek bileti sistemi API (okuma/yazma)
- Tool: Slack (takım bilgilendirme)
- Limit: Haftada 1000'den fazla bilet işleme
- Bloklu: Müşteri verilerine yazma erişimi, fatura işlemleri

## Hata Durumu
- Belirsiz bilet: Insan takımından soru sor (Slack)
- Aynı sorunu 3'ten fazla bilet görürse: "Tekrar eden sorun" etiketini koy
- Veri eksik ise: Müşteriye otomatik yanıt gönder, tamamlanmasını iste

## Rapor
- Günlük: Slack #support-ops kanalına özet (bilet sayısı, tasnif, ortalama tepki zamanı)
- Haftalık: Spreadsheet'e tren verisi (eğilim, yeni problem türleri)

Bu kural sayesinde:

• Ajan hangi araçlara erişebileceğini bilir
• Hangi durumda insan müdahalesini isteyeceğini bilir
• Ne raporlayacağını bilir
• Risk altında neler yok olacağını bilir

Ajanın Yaşam Döngüsü: Taslak, Aktif, Emekli

Bir ajan hemen üretim ortamında çalışmaya başlamaz.

Taslak (Draft) Yeni yazılmış, geliştirici test etmiş, ama organizasyon onaylamadı. Policy.md yarım olabilir, beceriler tam test edilmemiş olabilir. Git’te bir branch’te. Kimse üretimde bu ajanı çalıştırmıyor.

Aktif (Active) Policy.md tamamlanmış, test geçmiş, sahibi “evet, ben bu sorumluluğu alıyorum” demiş. Config dosyasında status: active yazıyor. Git main’de. Gerçek işler yapıyor. Hata olursa sahibi cevap verir.

Emekli (Inactive) Artık bu işi yapmaya ihtiyaç yok. Ya başka bir ajan daha iyi yaptı, ya şu anda o görev yapılmıyor. Ajan silinmiyor, Git history’de kalıyor. Ama status: inactive işaretleniyor. Belki sonra gerekir.

agents:
  support_triager_001:
    name: "Destek Biletleri Tasnif Ajan"
    owner: "person_Ali_Support"
    status: active
    created: 2026-08-20
    policy: "policy/support_triager_001.md"
    
  old_report_bot:
    name: "Eski Rapor Üreteç"
    owner: "person_Zeynep_Analytics"
    status: inactive
    created: 2025-06-10
    retired: 2026-08-15
    policy: "policy/old_report_bot.md"

Bu tasarım ne sağlıyor? Hesap verilebilirlik. Her ajanın sahibi var. Her ajanın kuralı Git’te. Kural değişirse PR ile insan onayından geçiyor. Kimin ne yaptığı, neden yaptığı, kimin sorumlu olduğu görülebiliyor.

Ajan Beceri Türleri: Hepsi Farklı Risk Taşır

Bir ajan hangi araçları kullanırsa kullanın, her bir araç farklı şekilde kontrol edilmek gerekir.

builtin — Ajanın kodunun içinde yazılı

• Metin işleme, basit matematik, data yapısı dönüşümü
• Güvenli: Git’te görülebilir, code review yapılır
• Hızlı: dış çağrı yok

mcp (Model Context Protocol) — Standart arabirime bağlı harici sistem

• Slack, GitHub, Jira gibi ünlü sistemlerin API’leri
• Yönetilir: kimlik doğrulama yapılı, rate limit var
• Değişen API versiyonları sorun olabilir

http — Serbest HTTP çağrısı

• Harici REST API’ye çağrı
• Riskli: URL validation olmalı, timeout zorunlu, rate limit kontrol edilmeli
• Policy’de hangi URL’ler izin verilen, hangisi yasak olduğu yazılı olmalı

function — Harici kod (Python/Node.js)

• Veritabanı sorgusu, ML modeli, özel iş mantığı
• En riskli: harici kod çalıştırma, hata handling gerekli
• Policy’de bu fonksiyonun ne yapacağı, ne kadar kaynak kullanacağı, timeout değeri belirtilmeli

skills:
  - type: builtin
    name: "ticket_categorize"
    
  - type: mcp
    name: "slack_notify"
    config:
      channel: "#support-ops"
      
  - type: http
    name: "fetch_customer_data"
    config:
      base_url: "https://api.internal.our-company/customers"
      timeout: 10
      rate_limit: 100_per_hour
      
  - type: function
    name: "calculate_priority_score"
    config:
      runtime: python
      path: "functions/priority_scorer.py"
      timeout: 5

Her becerinin policy.md’de açıkça yazılması lazım. “Bu skill için maksimum kaç kez çağrılabilir?”, “Hata olursa ne yapacak?”, “Sonuçları kime gidecek?” Hepsi belirtilmeli.

Policy.md ve Git Neden Birbirini Tamamlıyor

Policy.md dosyası config repo’sunda, Git’te saklanır. Değişiklik gelirse, PR açılır. İnsan bakar, değişiklik onaylanır veya reddedilir.

Bu, “ben bu ajanı test ettim, sorun yok” demenin tek ısmarlı yoludur. Çünkü Git history’de, kim ne zaman neyi değiştirdi, neden değiştirdi, insan onayları hep kayıtlı.

Karşılaştırma: birisi ChatGPT’ye özel bir system prompt yazıyor. Kimse bilmiyor ne yaptığını. Eğer yanlış kararını verirse? Politika yok, sorumluluk dağılmış.

Ama policy.md ve Git ile, ajanın kural kütlesi dünyaya açık. İnsan sormak isterse, Git history’yi açar, neden bu kural olduğunu görür, sahibini bulur.

Yarın: Bir ajan başka bir ajana iş nasıl devreder? A2A delegasyon, onay akışı, sonuç kontrolü.