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 project, 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 kalısı almaz. 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.

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?