Ajan Yönetimi Döngüsü: Rol, Politika, Delegasyon ve Git

Ajan Yönetimi Döngüsü: Rol, Politika, Delegasyon ve Git

Altı gün boyunca ajanların organizasyondaki yerini, rollerini, iş akışlarını ve sorumluluklarını adım adım inceledik. Şimdi bütün taşlar yerine oturdu: rol tanımı, politika, delegasyon ve versiyon kontrolü bir döngü içinde nasıl çalışıyor?

Bulduğumuz Parçalar

Gün 1’de shadow AI’ı gördük: kimse çalışan AI’ları sayamıyor, kaç tane olduğunu biliyor, karar veriliyor. Herkes kendi sekme, kendi sistem, kimsenin haberi yok.

Gün 2’de araç ile ajan arasındaki fark netleşti: ChatGPT bir araç, ajan ise düzenli bir varlık. Modeli, rolü, sorumlusu, politikası olan bir şey.

Gün 3’te organizasyon şeması ajanları da dahil edince ne kadar değiştiğini gördük. İnsan ile ajan düğümleri, her birinin sorumlusu (responsible_id), ve bu sorumlular zinciri.

Gün 4’te policy.md sistemiyle bu sorumlular sınırlarını tanımladık. Hangi ajan hangi işi yapabilir? Ne zaman? Hangi koşullar altında? Taslak, Aktif, Pasif, Archive durumları; builtin, mcp, http, function becerileri.

Gün 5’te ajan-ajan delegasyonunu konuştuk. A ajan B’ye iş veriyor, B sonucu A’ya geri gönderiyor. Araya onay sorgusu, kapasite kontrolü, veto hakkı koyulabilir. İş akışı sadece insan→ajan değil, ajan→ajan→insan olabilir.

Gün 6’da karma insan+ajan ekiplerinin nasıl çalıştığını anlatmaya çalıştık. Pazarlama müdürü ile sosyal medya ajanı aynı sorumlu altında, iş bölümü net, onay sırası açık.

Ama tüm bunlar neden? Bir sebepten: denetlenebilir, sorumlu, şeffaf, sürümlenmiş organizasyon. Ve bunun için neden Slack değil, Markdown + Git?

Denetlenebilirlik: Slack vs. Git

Bir pazarlama ekibi. Slack’te bir kanalda:

#agents
- social-media-ajan: her gün 14:00'de paylaş  [updated 2 days ago]
- content-writer-ajan: pazartesi 09:00 blog  [updated 1 week ago]
- seo-report-ajan: ayın ilk günü 08:00  [updated yesterday]

Kaç ajanınız var? Slack’e bakın, kanal metasındaki liste. Değişti mi? Slack history’yi kaydırın. Kimin yönetiyor? “Kanal sahibi” var, ama kim ekledi, kim değiştirdi, neden değişti?

Slack’te bir tarih. “Bu ajan neden 2 gün önce güncelendi? Kim yaptı?” Slack API’yi çekin, dışarı aktarın, analiz edin. Kimse rutin olarak bunu yapmaz.

Şimdi Git:

organization/
  policy.md
  agents/
    social-media-ajan.md
    content-writer-ajan.md
    seo-report-ajan.md

Her dosya Git’te. git log -- agents/social-media-ajan.md yazarsınız, bütün değişiklikler çıkar: tarih, kim, hangi satırlar değişti, commit mesajı. “2 gün önce müdür X değiştirdi, policy gücü seviyesi 2’den 3’e yükseltildi” yazıyor commit’te.

Kod inceleme (PR) sistemi kuralınız. Policy değişiklikleri pull request üzerinden. Başka bir yönetici onaylıyor. Zincir net, denetlenebilir, geri döndürülebilir.

Sorumluluk: Kim İstersen Gidilir?

Gün 3’te bahsettiğimiz responsible_id. Her ajan, her rol, her politika değişikliğinin sahibi vardır. Git ile bu sahibi commit history’de yazılı.

Pazarlama ajanında hata oldu. Yanlış tarihte yayın gitti. Kim sorumlu? policy.md’de pazarlama ajanının sahibi pazarlama müdürü. Müdür, kendi ajanında hata oluştu ve onayından geçti. Müdürün müdürü ise pazarlama başkanı. Sorumluluk zinciri açık.

Slack’te? Kanal metasındaki “sahibi” yazıyor, ama 6 ay önce kimin eklediği, neden eklediği, ne hali olduğu belli değil.

Versiyon Kontrolü: Geri Dönüş

Pazarlama ajanı geçen ayı başından itibaren yanlış policy ile çalışıyor. Raporlar hatalı. Ne zaman başladı? git blame yazın, tam satırı, tarihi, kim getirdi.

O tarihe dönüş yapmak istiyor musunuz? git revert veya branch oluşturun, eski politikaya dönün, test edin, onaylayın, merge edin.

Slack’te? “Geçen ayı başında neler vardı?” Slack history 90 gün civarında. Eski mesajlar gitmiş. Eğer sakladıysa (export), 6 ay öncesini bulup karşılaştır. Geri dönüş nasıl? Belki export’tan kopyala, yeniden yazı. İnsan hatası yüksek.

Ölçek ve Ekip Koordinasyonu

Küçük şirket: bir pazarlama müdürü, bir sosyal medya ajanı, bir muhasebe müdürü, bir raporlama ajanı. Slack’te, belki de iki kanal. Yaşanabilir.

Büyük şirket: 20 departman, her biri 5-10 ajan, her ajanın bir polisy, her poliçyden 3-4 versiyon (taslak/aktif/archive). 200 ajan. 500+ politika dosyası.

Slack’te? Kanal sayısı yönetilmez. History arama zor. PR, onay, kod inceleme yoktur.

Git’te? git log --all src/policy/ tüm politika değişikliklerini tarihe göre. git grep "policy_level: 3" tüm yüksek seviye ajanları bul. git show branch:agents/ Pazartesi versiyonuna bak, Cuma versiyonu ile karşılaştır. PR dashboard’u açın, onay bekleyen 12 policy değişikliği listesi.

Onay ve Sınırlar

Gün 4’te policy.md’deki her satırın bir anlamı vardı. policy_level, accessible_skills, veto_rules. Bu sınırlar Slack’te yazısa da, sistemin (API, CLI, ajan çalıştırıcı) onları uygulaması gerekir. Yani ajan framework’ü, Slack’e bağlı olmadan, policy.md dosyasını okur ve uygulanır.

Peki policy.md’yi kim yazıyor? Yönetici. Slack’te “bu notları güncelledim” diye yazıyor. Framework’ün bunu görmesi mi gerekli? Taslağı test mi yapıyor? Versiyon kontrol ediliyor mu?

Git’te: yönetici policy.md’de değişiklik yapıyor, kendi local’ında test ediyor (framework kendi dosyadan okuyor), PR açıyor, başka yönetici onaylıyor, merge ediyor, framework’ün CI/CD hook’u policy dosyalarını production’a çekerek test ediyor, kurulumu başarılı ise yayınlanıyor. İnsan hatası azalıyor.

Sentez: Neden Self-Hosted Git?

  1. Denetlenebilirlik: Her değişiklik, kim, ne zaman, neden. Git log sorusuz cevaplayıcı.
  2. Sorumluluğun Zinciri: responsible_id ile commit author. Sorumluluk takip edilebilir.
  3. Versiyon Kontrolü: Geri dönüş, branching, merge stratejileri. Politika deneme-yanılma yapılabilir.
  4. Ölçek: PR workflow’u, code review, CI/CD automation. 200 ajan, 10 yönetici yönetilebilir.
  5. Entegrasyon: Policy.md dosyasını ajan framework’ü doğrudan okur. Slack’e bağımlı değil. Slack’in şu an var olmaması, hizmet kesilmesi organizasyonu etkilemez.
  6. Audit ve Compliance: Müdür, müfettiş, IT güvenliği; altı ay öncesine kadar her adımı, kimin onayladığını, ne değiştiğini izleyebilir.

Sonra Ne?

Yedi günde anlattığımız: bir ajanlı organizasyon, en az insan, en az yazışma, maksimum denetlenebilirlik ve sorumluluk ile nasıl tasarlanır? Git ve Markdown dosyaları ile.

Slack, İnternet, bulut servisleri güzel. Ama organizasyonun yapısı, ajanlara dair kararlar, politikalar, sorumluluğun zinciri: bunlar self-hosted, kontrol edilebilir, sürümlendirilebilir bir sistem içinde olmalı. Yoksa “kimin sorumlusu olduğundan kim emin?” diye sormanıza bile yanıt verilmez.

AI’nız çalışıyor. Ama organizasyon kenti kontrol ediyor mu? Oraya kadar gitme zamanı.