Karma İnsan + Ajan Ekipleri Nasıl Yönetilir? Git ve Config-as-Code ile Sorumluluğun Versiyonlanması
Bir pazarlama müdürünün ekibini düşün. Müdür, iki pazarlama uzmanı, bir grafik tasarımcı, bir sosyal medya yöneticisi ve bir içerik yazısı ajanı vardır. Hepsi aynı hedefi yaşarlar: yeni ürün kampanyasını başlatmak.
Pazarlama Müdürü stratejik kararı verir. Uzmanlar kampanya çerçevesini belirlemeye katılır. Grafik tasarımcı görselleri tasarlar. Sosyal Medya Yöneticisi (insan) zamanlamayı ve halkla ilişki stratejisini uygular. İçerik Ajanı ise kampanya metinlerini yazıp, farklı sosyal ortamlara uyarlayan yazıları otomatik olarak hazırlar.
Basit görünüyor, ama gerçekte, bu iki dünya—insan kararları ve ajan uygulamaları—çok başarısız bir şekilde çarpışabilir.
Sorumluluğu Tanımlamak: İnsan ve Ajan Arasında Sınırlar
Bir yazı ajanı tarafından üretilen kampanya metni, bir müşteri sözleşmesiyle çelişse ne olur?
- Müdür: “Ben yazıyı onaylamadım; ajan kendi başına yazıp yayınladı.”
- Ajan: “Bana verilen talimatlara göre yazdım. Kurallar nerede belirtildiğini bulun.”
- Yazılımcı: “Ajan kodunda hiç sorun yok. Giren veri yanlışsa, çıkan sonuç da yanlış.”
Bu senaryo sorumluluğun bulanıklaştığı, hatta kaybolduğu bir durumdur.
Çözüm, ekip içindeki her rolün ve ajanın sorumluluğunu açıkça tanımlamaktır. Yalnızca sözselde değil, dosyalarda, Git versiyonunda, audit trail’inde de.
Config-as-Code: Kuralları Dosyaya Koymak
Geleneksel yönetimde kurallar sözelde veya karmaşık organizasyon tablolarında saklanır. Ajanlar ise kodlanmış, ölçülebilir ve sürümlendirilebilir kurallar gerektirir.
Örneğin, pazarlama ekibinin team-policy.md dosyası şöyle görünebilir:
# Marketing Team Policy (v2.3)
## İçerik Ajanı Sorumluluğu
- Talimatta verilen stil ve konu başlığına bağlı kalmalı
- Ürün sözleşmesi veya yasal metin içermemelidir
- Açık hata varsa, insan yöneticiyi etiketlemelidir
## Onay Mekanizması
- İçerik Ajanı tarafından yazılan metinler, sosyal medya yöneticisine iletilir
- Sosyal medya yöneticisi 2 saat içinde onay veya geri dönüş yapmalı
- Eğer onay yoksa, yayın 2 saat gecikir
- Yasal risk durumunda, müdür onayı zorunludur
## Veri Sınırları
- İçerik Ajanı müşteri iletişim listesine erişemez
- Fiyat verilerini yalnızca pazarlama DB'den çekebilir
- Üretilen tüm metinler Git history'de saklanırBu dosya, hem insanlar hem de yazılımcılar tarafından anlaşılabilir. Ajan kodunun çalışması bu kuralları temel alır.
Git Versiyonlaması: Kim Ne Zaman Yaptı?
Bir kampanya metni anlaşmaya uymuyor. Kimin hatası?
- Yazılan metni kontrol et:
git log src/campaigns/new-product-campaign.md - Commit mesajı: “2026-09-15 09:30 — İçerik Ajanı tarafından yazıldı, sosyal-medya-yöneticisi onayladı”
- Değişiklik:
git show <commit-hash>- Orjinal metin (ajan tarafından)
- Onaylayan kişinin notu (“Yasal kontrol OK — SM Müdürü”)
- Nihai yayın zamanı
Bu şekilde, her bir değişikliğin arkasında bir sorumluluk ve karar zinciri vardır.
Eğer metin sonradan değiştirilirse, bu da Git’te görülür:
commit 2 - 2026-09-15 14:00 - Müdür tarafından yasal düzeltme
commit 1 - 2026-09-15 09:30 - İçerik Ajanı tarafından yazıldıSorumluluğu takip etmek çok daha kolay hale gelir.
Onay Görevlendirmesi: Kimin Yetkisi Nedir?
Karma ekiplerde, onay zinciri de karma olur. Örneğin:
| Karar Türü | Karar Alan | Onay Yetkisi | Git’te Kim Kaydeder |
|---|---|---|---|
| Kampanya metni yazılacak | İçerik Ajanı | - (otomatik) | İçerik Ajanı |
| Metin onaylanır | Sosyal Medya Yöneticisi | Evet | SM Yöneticisi |
| Yasal inceleme gerekirse | Hukuk Müşaviri | Evet | Müşavir |
| Nihai yayın izni | Pazarlama Müdürü | Evet | Müdür |
Tüm bu adımlar işleminde, kim karar aldığı ve ne zaman kayıtlı olur. Eğer bir adım atlanırsa, Git log’u bunu gösterir.
Gerçek Zaman Sorgu: Durumu Kimin Kontrol Ettiği
Müdür, kampanya yayımlanmadan hemen önce şunu sorabilir:
git log --oneline -n 10 -- campaigns/new-product-campaign.mdSonuç:
5 - Pazarlama Müdürü - "Yayın onayı verildi"
4 - Hukuk Müşaviri - "Metinde yasal sorun yok"
3 - SM Yöneticisi - "Sosyal medya okuyucuları için uygun"
2 - İçerik Ajanı - "Metin yazıldı"Sorumluluğun ve onayın tüm zinciri görülür. Eksik bir adım varsa, bu da hemen belli olur.
Ölçeklenme: Birden Fazla Ajan, Birden Fazla Ekip
Eğer beş pazarlama ajanı, üç mühendislik ajanı ve dört yazılımcı varsa?
Organizasyon şeması, her ajanın ve her insanın responsible_id’sini tanımlar. Policy dosyaları her ekibe özel veya genel kuralları belirler. Git history’si her kararın arkasındaki kişi veya ajanı kaydeder.
Denetim ve sorumluluk, bu dört unsurla yönetilebilir:
- Organizasyon Şeması: Kim kimin sorumlusu?
- Policy Dosyaları: Kurallar ve onay mekanizmaları nedir?
- Git History: Değişiklikler kim tarafından ve ne zaman yapıldı?
- Config-as-Code: Ajan yetkisi, veri erişimi, hata yönetimi kod olarak tanımlanmış.
Bu yaklaşım, Slack mesajında “Kimse sorumlu mu?” diye soruşturmanın yerine, tüm sorumluluğu kayıtlı ve denetlenebilir hale getirir.
Bir organizasyon bu dört unsuru birleştirdiğinde, AI ajanları bir risk değil, değer taşıyan, denetlenebilir ve ölçeklendirilebilir bir sistem parçası haline gelir.