Ajanlarınıza Kimlik Belgesi: policy.md ve Operasyonel Durumlar

Eğer organizasyonunuzda bir insan ekip üyesine hangi projede çalışabileceğini söylemezseniz, o kişi ne yapacağını bilmez. Aynı şekilde, bir AI ajanına da “sen bu sistem üzerinde neler yapabilirsin, ne zaman yapabilirsin, neye erişebilirsin” diyerek sınırlarını belirtmemek, organizasyonel kaostur.

Bu noktaya policy.md devreye giriyor. Bir ajanın sorumluluklarını, erişim hakları ile yeteneklerini tanımlayan dosyadır; tıpkı bir insan çalışanın iş tanımı veya rol kartı gibi. Ama policy.md yalnızca kağıt değil: sistematik olarak uygulanması, takibi ve versiyonlandırılması gerekir.

Politika Neyi Tanımlar?

Bir ajanın policy.md’si şunları belirler:

• İşin sınırları: Hangi proje, deadline, kaynak bütçesi veya veri kategorisine dokunabilir?
• Becerileri: Hangi API’lere, CLI araçlarına, fonksiyonlara erişebilir? (builtin vs. mcp vs. http vs. function)
• Onay mekanizması: Belirli işler veya risk seviyeleri için insan onayı gerekli midir?
• Hata ve raporlama: İşleri nasıl loglar, başarısızlık durumunda kime haber verir?

Örneğin, bir “İş Belgesi Yazarı” ajanı şöyle tanımlanabilir:

Policy: Technical Writer Agent
- Projects: [docs, blog]
- Skills: [file_write, web_search, git_commit]
- Budget: max 5000 tokens per task
- Approval required for: commits to main branch
- Error escalation: ops-team@company.com

Basit gibi görülebilir, ama bu tanım şunları yapabilir:

• Yanlışlıkla üretim verilerine erişmesi önler.
• Çok pahalı bir AI çağrısından korunur.
• İşi başarısız olsa, bilmeniz gereken kimseler otomatik olarak bilgilendirilir.

Ajan Durumları: Draft, Active, Passive

Bir ajanın yaşam döngüsü üç durumda takip edilir:

Draft (Taslak)

Ajan henüz canlı değildir. Test ediliyor, politikası yazılıyor, bu arada kimse ona iş vermez. Bir draftın başarısız olması veya ortadan kaldırılması hiçbir şeyi kırmaz.

Active (Aktif)

Ajan üretim görevlerinde çalışıyor. Politikası kesin, becerileri sınırlı ve izleniyor, sorumluluğu tanımlıdır. Burada hata, veri kaybı veya gecikme önemlidir.

Passive (Pasif)

Ajan, artık yeni iş almıyor ama devam eden görevlerini bitirmeye devam ediyor. Eski policy’i ve becerileriyle çalışıyor; yeni politika güncelleme ya da yetki değişikliğine maruz kalmaz. Bu, kontrolsüz şekilde kapatma olmadan, görev akışını sağlıklı sonlandırır.

Böyle bir yapı olmadan, ajanlar eski politika ile çalışmayı sürdürür ve çatışmalar yaşanır.

Becerileri Türleri

Bir policy’de “Hangi araçlara erişebilir?” sorusu önemlidir:

• builtin: Hermes veya tarafınızın sunduğu yerleşik fonksiyonlar. Hızlı, güvenilir, sınırlı.
• mcp: Yerel olarak yüklü MCP sunucuları. Daha esnek, özel iş mantığı için.
• http: Harici API’ler. İnternet bağlantısı, gecikme, kimlik doğrulama riski.
• function: Özel Python/Node fonksiyonları. En esnek, ama en riskli (arbitrary code execution).

Her beceri seviyesi, farklı risk ve güven gerektiriyor. Bir ajanın politikası, tam olarak hangi tür araçlara erişebileceğini açıkça listelemeli.

Neden Bu Önemli?

Şirketinize sorun: “Dün ChatGPT’yi git push yapmaya izin veren prompty kullanan kaç kişi vardı?” Çoğu zaman cevap bilinmiyor, çünkü herkesin kendi seçimi vardır, hiçbir merkezi politika yoktur.

Ama policy.md ile:

• Her ajanın yetkileri, version kontrol (Git) içinde görünür.
• Değişiklik yapmak istersen, PR açarsın ve insan onayı alırsın.
• Audit trail (kim ne zaman değiştirdi) otomatik olur.
• Eski policy’ler (tarihçe), Git history’de kalır.

Pratik Uygulama: policy.md Nasıl Yönetilir?

Bir policy.md dosyası yazmak kolay; asıl zorluk onu yaşatmaktır. İşte uygulanabilir bir yaklaşım:

Depo yapısı: Her ajan için ayrı bir policy.md dosyası tut. Örneğin agents/writer/policy.md, agents/analyst/policy.md. Bu dosyalar, ajanın kodla aynı depoda versiyonlanır.

PR ile değişiklik: Bir ajanın yetkisini değiştirmek istediğinde, policy.md dosyasını düzenle ve bir PR aç. Review sürecinde şu sorulara cevap ver:

• Bu değişiklik neden gerekli?
• Hangi risk seviyesi artıyor?
• Geri alınması gerekiyorsa nasıl yapılır?

Otomatik kontrol: CI/CD pipeline’ında policy.md dosyalarını doğrula. Örneğin, bir ajanın function becerisini kullanmasına izin verilmiyorsa, bu beceri listesinde görünüyorsa build başarısız olsun.

Periyodik gözden geçirme: Her çeyrek, tüm aktif ajanların policy.md’lerini gözden geçir. Passive durumdaki ajanların politikaları arşivlensin.

Gerçek Dünya Senaryosu

Bir yazılım şirketinde üç ajan çalıştığını düşünelim: bir kod inceleme ajanı, bir test yazım ajanı ve bir dokümantasyon ajanı. Üçünün de farklı beceri setleri ve farklı risk seviyeleri var.

Kod inceleme ajanı http becerisiyle harici API’lere erişebilir, ama function becerisi yoktur. Test yazım ajanı builtin ve mcp kullanır, üretim veritabanına yalnızca salt okunur erişimi vardır. Dokümantasyon ajanı yalnızca file_write ve web_search kullanır; hiçbir koda dokunmaz.

Bir gün kod inceleme ajanı, bir güvenlik açığı bulduğunda otomatik PR açmak ister. Ama policy.md’sinde function becerisi yok. Bu istek reddedilir ve bir insan müdahale eder. policy.md olmasa bu istek sessizce geçebilirdi veya kötü niyetli bir prompt enjeksiyonu ile ajanın yetkileri aşılabilirdi.

policy.md, ajanların ne yapabileceğini açıkça tanımladığı için bu tür senaryolarda sorumluluk netleşir. Kimse “bunu ajan mı yoksa bir prompt mu yaptı?” diye sormaz; çünkü ajanın yetkileri önceden belirlenmiştir.

Sonraki Adım

Policy.md ancak şirketin tarafından kontrol edilen bir ortamda güç verir. Slack bot’un veya herkese açık ChatGPT’nin politikasını değiştiremezsin; ama kendi self-hosted ajanlarının politikasını, Git’te, PR’lar ile yönetebilirsin.

Eğer organizasyonda ajanları belirgin kimlikle, policy.md ile tanımlayan başka şirketi görmüyorsanız, siz ilklerdensiniz. Bu, hem sorumluluk hem de rekabet avantajıdır.

Yazı serisinden sonra, kendi ajanlarınıza ne kadar derinden policy.md yazabilirsiniz? Operasyonunuz ne gibi becerileri kısıtlamayı gerektirir?