AI Ajan Yönetimi: Rol, Politika, Delegasyon ve Versiyon Kontrolü Sentezi

Bu serinin ilk gününde bir IT yöneticisiyle konuştuk. “Şirketinizde kaç AI ajanı çalışıyor?” diye sorduk. Cevap: “Herkes biliyor ama sayı yok.” Yazılımcılar ChatGPT’de kod yazıyor, pazarlama ekibi içerik üretiyor, veri ekibi Python script’inde bir model çalıştırıyor. Hiçbirinin resmi kaydı yok, hiçbirinin sorumlusu yok.

O günden bu yana altı gün boyunca bu sorunun çözümünü adım adım inşa ettik. Bugün, bu adımları birleştiriyoruz ve neden Slack veya ChatGPT gibi mevcut araçların bu iş için yeterli olmadığını, neden organizasyonunuzu Git repository’sinde tutmanız gerektiğini anlatıyoruz.

Serinin Özeti: Altı Gün, Dört Temel Taş

Bu seride dört temel taşı tanımladık:

Gölge AI’yı görünür kılmak. İlk gün, kurumsallaşan shadow AI’dan bahsettik. Herkesin kendi bilgisayarında kullandığı, hiçbir kaydı olmayan AI araçları. Bunları görünür kılmak, sorumluluğun ilk adımıdır.

Ajan ile araç arasındaki fark. İkinci gün, araç ile ajan farkını açıkladık. ChatGPT kullanmak araç kullanmaktır; kararın sorumluluğu insana aittir. Ama organizasyonda tanımlanmış bir “Deployment Ajanı” bir varlıktır; sahibi, politikası ve sorumluluğu olmalıdır.

Organizasyon şemasına ajan düğümleri. Üçüncü gün, organizasyon şemasının ajanları da kapsaması gerektiğini gördük. Bir ajanın sahibi yoksa, onun yaptığı işin sorumlusu da yoktur. Responsible_id, hesap verebilirliğin temelidir.

policy.md ve operasyonel durumlar. Dördüncü gün, her ajanın bir politika dosyasına ihtiyacı olduğunu öğrendik. Taslak, Aktif ve Pasif durumları, beceri tipleri (builtin, mcp, http, function) ve onay mekanizmaları.

A2A delegasyon ve onay akışı. Beşinci gün, ajanların birbirine iş devredebileceğini ama sorumluluğun kaybolmayacağını gördük. Veto noktaları, sonuç doğrulama ve risk tabanlı onay hiyerarşisi.

Karma insan + ajan ekipleri. Altıncı gün, gerçek dünyada ajanların yalnız çalışmadığını, insanlarla aynı ekipte üretim yaptığını gördük. İş bölümü, onay sorumluluğu, config-as-code ve Git ile versiyonlanma.

Bugün, bu altı taşı birleştiriyoruz.

Neden Slack ve ChatGPT Yetersiz?

Bu dört temel taşı (organizasyon şeması, politika, delegasyon, karma ekip) Slack veya ChatGPT üzerinde yönetmeye çalışırsanız, beş yapısal sorunla karşılaşırsınız.

Birinci sorun: Tarihçe kaybolur. Slack’te 30 gün öncesi silinen bir mesajda “Deployment Ajanı hangi politika ile hareket etti?” diye sorarsanız, yanıt yoktur. Git ise sonsuz tarihçedir. Her değişiklik, her karar, her onay commit mesajında kalır.

İkinci sorun: Sorumluluk tanımlanmaz. ChatGPT’ye bir soru sordunuz, cevap aldınız. Sonra bir soruşturma başladı: hata ne zaman çıktı, kim yaptı? ChatGPT’nin hiçbir responsible_id’si yok. Bu kişisel bir araç, yönetilen bir varlık değil.

Üçüncü sorun: Politika yazılı değil. Slack’te “Deployment Ajanı iki onay almalı” diye yazarsanız, Deployment Ajanı bunu nasıl okur? Git’teki policy.md dosyasında yazılıysa, hem insan hem kod bunu kontrol edebilir.

Dördüncü sorun: Onay zinciri kontrolü yok. Slack’teki bir konuşmada “Onay verdim” diye bir mesaj var. Ama kim onaylı? Gerçekten o kişi mi? Git’teki commit signature’ı kriptografik olarak garantilir.

Beşinci sorun: Versiyon yok. Slack’te bir politika değiştiğinde, eski politika kaybolur. Git’te ise her değişiklik commit mesajıyla kayıt altındır. “Kurallar ne zamandır böyleydi?” sorusu git log ile cevaplanır.

Self-Hosted, Git Tabanlı Alternatif

Çözüm bu beş sorunu aynı anda gidermektir. İşte nasıl:

1. Organizasyon Dosyası (organization.md)

# Organization Structure

## Engineering Department
- Manager: Ali (ali@company.com)
  - Developer 1: Ayşe
  - Developer 2: Mehmet
  - DevOps Manager: Can
    - responsible_id: deployment-agent-v2
    - responsible_id: infrastructure-agent-v1

## Agents
- deployment-agent-v2
  - owner: Can (DevOps Manager)
  - policy_file: policies/deployment-policy.md
  - status: Active
  
- infrastructure-agent-v1
  - owner: Can
  - policy_file: policies/infrastructure-policy.md
  - status: Active

Bu dosya, organizasyon şemasının kod halidir. Her ajanın sahibi, politika dosyası ve durumu yazılıdır. Bu dosya Git’te tutulduğu için, her değişiklik commit mesajıyla kayıt altındır.

2. Politika Dosyaları

# policies/deployment-policy.md

## Deployment Ajanı Politikası (v1.2)
- Staging test başarısız olursa deployment yapamaz
- Günde maksimum 3 deployment
- Her deployment öncesi 5 dakika veto hakkı
- Hata durumunda DevOps Manager'ı etiketler

Bu politika dosyası, hem insanlar hem ajanlar tarafından okunabilir. Ajan, deployment yapmadan önce bu dosyayı kontrol eder. İnsan, bir deployment’ı reddederken bu dosyaya bakarak gerekçelendirir.

3. Git Tabanlı Onay ve Tarihçe

# Her deployment kaydı Git commit olur:
$ git log policies/deployment-policy.md
commit abc123 - DevOps Manager - "Policy v1.2 güncellendi"
commit abc122 - CEO - "Policy v1.1 onaylandırıldı"

Git, kim tarafından, ne zaman, neden değişiklik yapıldığını kaydeder. Bu, denetim ve hesap verebilirliğin temelidir.

4. A2A Delegasyon Kaydı

# delegations.md

## Security Check Delegation
- From: code-agent-v1
- To: security-agent-v2
- Task: "Review encryption logic"
- Requested: 2026-09-24 10:00
- Completed: 2026-09-24 11:30
- Result: "Approved"
- Approver: security-agent-v2

A2A delegasyon, ajanlar arası iş bölümü demektir. Her delegasyon kayıt altındır. Bir sorun çıktığında, zincirdeki her adım izlenebilir.

Bu Yaklaşımın Günlük Hayattaki Karşılığı

Bu sistemi kurmak teknik bir değil, organizasyonel bir karar. İşte günlük hayatta nasıl çalışır:

Sabah: Müdür, Git’teki organizasyon dosyasını kontrol eder. Yeni bir ajan eklenmiş mi? Bir ajanın sahibi değişmiş mi? Bir politika güncellenmiş mi? Hepsi commit mesajında görünür.

Gün içi: Ajanlar iş yapar. Her karar, her onay, her delegasyon kayıt altındır. Bir ajan bir hatayı bulduğunda, raporunu PR yorumuna ekler. İnsan, raporu inceler, onaylar veya reddeder. Reddetme gerekçesi yorumda belirtilir.

Akşam: Müdür, günün özetini Git log’dan görür. “Bugün 3 deployment yapıldı, 2’si onaylandı, 1’i reddedildi. Reddetme gerekçesi: staging test başarısız.” Hepsi kayıt altındır.

Bir yıl sonra: “Bu projede neden bu karar verildi?” sorusu cevaplanabilir. Git log, organizasyonun öğrenme sürecinin kaydıdır.

Neden Bu Önemli

Bu yaklaşım, yalnızca bir denetim aracı değil, organizasyonel bir yatırım. İşte neden:

Hesap verebilirlik: Her kararın sahibi vardır. Bir hata çıktığında, kimin ne zaman ne karar verdiği görünür.

Öğrenme: Organizasyon, geçmiş kararlarından öğrenir. “Bu hatayı neden yaptık?” sorusu cevaplanır.

Şeffaflık: Kurallar, roller, sorumluluklar herkes tarafından görünür. Gizli politika yok, gizli karar yok.

Sürdürülebilirlik: Bir ajan kaldırıldığında, onun sahibi, politikası ve geçmişi kayıt altındır. Bilgi kaybolmaz.

Sonraki Adım

Bu serinin ilk gününde sorduğumuz soruyu tekrar soruyoruz: “Şirketinizde kaç AI ajanı çalışıyor?”

Eğer cevap hâlâ “herkes biliyor ama sayı yok” ise, bu seriyi başlangıç noktası olarak kullanın. İlk adım: ajanları görünür kılmak. İkinci adım: her ajan için sahiplik ve politika tanımlamak. Üçüncü adım: organizasyon şemasını Git’e taşımak. Dördüncü adım: onay ve delegasyon kayıtlarını tutmak.

Bu adımları atarak, görünmez ajanlar yerine, görünür, yönetilen ve denetlenebilir ajanlara sahip olursunuz. Bu, yalnızca bir teknik altyapı değil, kurumsal güven ve şeffaflığın temelidir.

Gölge AI ve kurumsallaşan shadow AI, Ajan ile araç farkı, Organizasyon şemasında ajan düğümleri, policy.md ve ajan durumu, A2A delegasyon ve onay akışı, Karma insan + ajan ekipleri.