Karma İnsan + Ajan Ekipleri: İş Bölümü ve Sorumluluk

Karma İnsan + Ajan Ekipleri: İş Bölümü ve Sorumluluk

Şimdiye kadar ajanı tanıdık, organizasyon şemasında yeri gördük, policy.md’sini okudu, başka ajana iş devredişini anladık. Ama gerçek dünyada hiçbir ekip yalnızca ajanlardan veya yalnızca insanlardan oluşmaz. Bir insan müdürün altında bazı insanlar, bazı ajanlar vardır. Onlar bir arada nasıl çalışır?

Geleneksel İnsan Ekibinde İş Bölümü

Bir pazarlama ekibi düşün:

Her biri sorumlu bir alan vardır. Müdür, danışmanlarının işlerini kontrol eder ve onay verir. Danışmanlar kendi alanlarında özerklik vardır.

Aynı ekibe bir ajan eklediğimizde ne değişir?

İnsan + Ajan Ekip Yapısı

Pakarlama ekibine “Sosyal Medya Ajani” eklediğimizi düşün:

Şimdi işler karışıyor:

  1. Kim hangi işi yapacak? Danışman B’nin atladığı postları Ajan ayı mı yapacak? Yoksa Danışman B tüm yönetimi mi üstlenecek?

Cevap: İş bölümü kararı insana (müdüre) düşer. Müdür şu şekilde kural yazmak zorundadır:

Sosyal Medya Ajani İş Tanımı:
- Pazarlama Danışmanı B tarafından onaylanan içeriği 
  her gün 14:00 saatinde yayınlar.
- Yayından 1 saat sonra analytics raporunu hazırlar 
  ve Danışman B'ye gönderir.
- Engagement altında kalırsa (50 kişi) Danışman B'ye 
  uyarı verir.
- Viral post fırsatında (500+ kişi) müdüre escalate eder.
  1. Kim onay verecek? Danışman B bir stratejik karar veriyorsa (örn. “Bu ay yalnızca video yayınlarız”), kimin onayı gerekir?

Cevap: Müdürün onayı. Ama detay şu: Danışman B’nin rutin kararları (hangi postu ne zaman yayınlasın) müdüre sormasına gerek yok. Ajanın kararları (Sosyal Medya Ajani bir post yaymamayı tercih etmesi gibi) ise daima müdürün politikasına uymalıdır.

  1. Ajan hata yaptığında? Sosyal Medya Ajani bir postun yayınlanmadan öncesini unutup yayın yaptıysa (Danışman B onaylamamış), kim sorumlu?

Cevap: Sonuçta müdür sorumludur. Danışman B de sorumludur (kontrol etmemiş), Ajan de sorumludur (kuralı çiğnemiş). Ama en üst sorumluluğu müdür taşır.

Config-as-Code: Kurallar Yazılı Olmalı

Tüm bu kurallar müdürün kafasında kalmamalı. Yazılı olmalı. İdeal olarak:

team:
  name: "Pazarlama"
  manager: "İnsan: Müdür Ali"
  members:
    - name: "Danışman Zeynep"
      type: human
      skills:
        - content_planning
        - strategy_approval
    - name: "Danışman Emre"
      type: human
      skills:
        - social_media_management
    - name: "Sosyal Medya Ajani"
      type: agent
      owner: "Müdür Ali"
      policy: "policy-social-media.md"
      skills:
        - post_scheduling
        - analytics_reporting
      delegation:
        can_receive_from: ["Danışman Emre", "Müdür Ali"]
        must_approve_to: ["Danışman Emre"]
      capacity:
        max_posts_per_day: 10
        max_parallel_tasks: 2

approval_rules:
  strategic_decision: "Müdür Ali"
  daily_scheduling: "Danışman Emre"
  policy_change: "Müdür Ali + CTO"
  budget_over_5k: "CEO"

Bu YAML veya benzeri bir yapıda yazılı olmalı. Niye? Çünkü:

  1. Belirsizlik ortadan kalkar: Herkes kuralı bilir.
  2. Ajan bunu okuyabilir: Ajan bu config’i parse ederek hangi koşulda neyi yapacağını bulabilir.
  3. Versiyon kontrolü yapılır: Config değişti mi, kim değiştirdi, ne zaman kontrol edilebilir.
  4. Gözü olan görebilir: Yeni bir müdür atandığında veya takip denetçi geldiğinde, hepsi bu configde yazılıdır.

Git ve PR ile Organizasyonun Versiyonlanması

İşte burada dev dünyasının en güçlü öğesi gelir: Git.

Organizasyon konfigleri bir Git repository’si içinde tutulmalı. Örneğin:

org-config/
├── teams/
│   ├── pazarlama.yaml
│   ├── mühendislik.yaml
│   └── muhasebe.yaml
├── policies/
│   ├── policy-social-media.md
│   ├── policy-data-handling.md
│   └── policy-financial-approval.md
├── agents/
│   ├── agent-social-scheduler.yaml
│   ├── agent-data-processor.yaml
│   └── agent-report-generator.yaml
└── README.md

Müdür Ali’nin pazarlama ekibine yeni bir ajan ekleme kararı aldığını düşün. Şimdi:

  1. Ali bir branch oluşturur: feature/add-social-agent
  2. Configleri günceller: Teams YAML’ına ajan eklenir
  3. PR açar: “Pazarlama ekibine Sosyal Medya Ajani ekleniyor”
  4. Gözden geçirir: CTO veya policy sorumlusu review eder
  5. Tartışılır: “Bu ajan gerçekten şu kadar yetki alabilir mi?” diye sorular sorulur
  6. Onaylanır: Approve tıklanır
  7. Merge edilir: Main branch’e gitmiş, efektif olur
  8. Deployment: Sistem otomatik olarak bu config’i okur, ajani eğitir, kurallar ortaya konur

Tüm bunun tarihi kalır. 3 ay sonra denetçi sordu: “Bu ajana kim yetki verdi, ne zaman, niye?” Cevap: Git log’da burada.

$ git log --oneline | grep "social-agent"
a3f4e5c feature/add-social-agent (merged 2026-09-03, reviewed by CTO, approved)

$ git show a3f4e5c
# Tüm değişiklikler ve açıklamalar orada

Pratik Örnek: Müdür Ali’nin Kararı

Müdür Ali pazarlama ekibini genişletmeye karar verdi:

Adımlar:

  1. Ajan tanımı: Policy-content-planner.md yazılıyor

    Ajan: İçerik Planlayıcı
Owner: Müdür Ali
Beceriler: İçerik fikir üretme, takvim planlama
Sınırlar: Müşteri sözleşmesi değiştirme yapamaz
Onay: Danışman Zeynep her hafta planı kontrol eder

  2. Config güncellenmesi: Teams/pazarlama.yaml’a ajan ekleniyor

  3. PR açılıyor: Gözden geçirilir, Danışman Zeynep ve CTO onay verir

  4. Merge: Config main’e girdi

  5. Sistem güncelleniyor: İnsan olsun ajan olsun, herkes yeni config’i biliyor

  6. Denetim izi: Tüm bu süreç logu Git’te kalıyor

Özet

Karma ekiplerde:

  1. İş bölümü kuralı: Müdür kararı, config’de yazılı
  2. Onay sorumluluğu: Hiyerarşi Net, tanımlanmış
  3. Config-as-Code: Kurallar makine okunaklı
  4. Git + PR: Değişiklik tarihçesi, gözden geçirme, onay süreci
  5. Denetlenebilirlik: Her karar ve değişiklik kaydedildi

Slack’ten veya basit bir e-tablo’dan bu kuralları tutmaya çalışırsan, bir hafta sonra kaos olur. Config-as-Code + Git = adanmış, versiyonlı, denetlenebilir organizasyon.

Yarın: Tüm parçalar (rol, politika, delegasyon, versiyon kontrolü) bir arada olunca ne olur?