Organizasyon Şemasında Ajan Düğümleri Olmadan Kim Hesap Verebilir?

Geçen hafta bir yazılım şirketinde gözlem fırsatı buldum. Üç kişilik bir backend ekibi vardı. Herkes kendi bilgisayarında farklı AI araçları kullanıyor. Biri kod tamamlama, biri test yazma, biri hata ayıklama. Verimlilik arttı, teslim hızı iyileşti. Sorun yok gibi görünüyordu.

Sonra bir incident oldu.

Bir ajan, kendi kendine kodu repository’e push etti. Review olmadan, onaylanmadan. Sorumlu kim? Ekip lideri mi? Ajanı kuran kişi mi? Hiç kimse bilmiyordu. Çünkü organizasyon şemasında ajan yoktu. Sadece üç mühendis vardı. Ajan, şemanın dışında, görünmez bir düğüm olarak çalışıyordu.

Bu bir tekil hata değil. Yapısal bir eksiklik.

Organizasyon Şemasının Eski Varsayımı

Klasik organizasyon şeması şöyle çalışır: insanlar, roller, raporlama zinciri. CEO’dan CTO’ya, CTO’dan mühendislerin mühendisler. Her düğüm insandır. Her sorumluluk bir insanı gösterir.

Bu model, ajanların olmadığı bir dünya için tasarlandı.

Bugün bir fabrikada, bir yazılım şirketinde, bir lojistik operasyonunda ajanlar çalışıyor. Bazıları ChatGPT, bazıları Claude, bazıları kurumsal bir framework üzerinde özel geliştirilmiş ajanlar. Hepsi karar veriyor. Hepsi iş yapıyor. Hepsi iz bırakıyor.

Ama şemada yerleri yok.

Bu durumda sorular cevapsız kalır:

Bir ajan hata yaptı, kim sorumlu? Bir ajan yetkisini aştı, kim onayladı? Bir ajanın sahibi kim, kim yönetiyor? Bir ajan kaldırılıyor, kim karar verdi?

Cevaplar genelde şöyle olur: kimse. Çünkü şemada bu ajan yok.

Ajan Düğümleri Neden Şemaya Dahil Edilmeli

Organizasyon şeması, işlerin kim tarafından yapıldığını gösterir. Bugün işler sadece insanlar tarafından yapılmıyor. Ajanlar da iş yapıyor. O zaman şema da bunu yansıtmalıdır.

Bir ajanı şemaya eklemek şu soruları zorunlu kılar:

Bu ajanın sahibi kim? (responsible_id) Bu ajan hangi işleri yapabilir? Bu ajan hangi politikalarla çalışıyor? Bu ajanın işleri kim onaylıyor?

Bu sorular cevaplanmadan ajan kurulursa, ajan tanımsız bir iş gücüne benzer. İnsan işçide bu sorular cevapsız olmaz: işe alırken pozisyonu belirlenir, maaşı, sorumluluğu, yöneticisi netleştirilir. Ajanlarda ise bu detaylar göz ardı edilebiliyor.

Şemaya ajan eklemek sadece bir gösterim eylemi değil. Kurumsal hesap verebilirliğin temelidir.

Responsible_id Nedir ve Neden Kritik

Responsible_id, bir ajanın sorumlu sahibini gösteren bir alandır. Ajanın sahibi, ajanın yaptığı işlerin son sorumlusudur. Ajan bir hata yaptığında, ajanın sahibine hesap sorulur. Ajan yetkisini aştığında, ajanın sahibi neden denetim yapmadan sorumlu tutulur.

Bu, insan işçiler için normal olan bir yapıyı ajanlara taşır.

Bir ajanın sahibi yoksa, o ajanın yaptığı işlerin de sahibi yoktur. Hesap verebilirlik zinciri kırılır.

Pratik Senaryo: Ajan Şeması ile Olan ve Olmayan

Bir müşteri hizmetleri ekibi düşünün.

Şemasız durum: Müdür ve üç temsilci var. Her temsilci kendi bilgisayarında bir yanıt ajanı kullanıyor. Müdür ajanların varlığını bilmiyor. Bir ajan müşteriye yanlış bilgi veriyor. Müdür “bu ajanı kim kurdu?” diye soruyor. Cevap: “herkes kullandığı araçlardan bir tane.”

Sorumluluk yok. Denetim yok. İz yok.

Şemalı durum: Müdür ve üç tembilci var. Ama şemada şunlar da var:

• Ajan: Müşteri Yanıt Asistanı
  • Sahip: Temsilci A
  • Onay: Müdür
  • Politika: musteri-hizmetleri.md
• Ajan: Yanıt Kalite Kontrol
  • Sahip: Temsilci B
  • Onay: Müdür
  • Politika: kalite-kontrol.md

Bir ajan yanlış bilgi verdi. Şemaya bakılıyor. Sahibi Temsilci A. Müdür, Temsilci A’ya “ajanın politika dosyasını güncelle, bu hatanın kaynağını bul” diyor. İş çözülüyor.

Fark net: şemada ajan varsa, sorumluluk zinciri de vardır.

Şemayı Kod Olarak Tutmak: Git ve Versiyon Kontrolü

Organizasyon şeması kağıt üzerinde kalmalı değil. Dosya tabanlı olarak tutulmalıdır. Markdown veya YAML formatında. Bu şekilde Git ile versiyonlanır.

Neden Git?

Çünkü Git, kim tarafından, ne zaman, neden değişiklik yapıldığını kaydeder. Ajan eklenirse, PR açılır, tartışılır, onaylanır, merge edilir. Ajan kaldırılır, kaldırma nedeni commit mesajında açıklanır. Bir ajanın yetkileri değişirse, PR’de görüşülür.

Bu yaklaşım organizasyon şemasını şeffaf hale getirir.

Örnek bir yapı:

team:
  - name: Backend Ekibi
    responsible: ali@firma.com
    members:
      - name: Ali (insan)
        role: ekip_lideri
      - name: Ayşe (insan)
        role: kıdemli_mühendis
      - name: CodeReview (ajan)
        type: agent
        responsible: ayse@firma.com
        skills: [code_review, test_generation]
        policy: code-review.md

Bu yapı sayesinde, CodeReview ajanının sahibi Ayşe’dir. Ayşe, ajanın yaptığı işlerin sorumlusudur. Ajan bir hatayı atlarsa, Ayşe’ye hesap sorulur. Ayşe, ajanın sorumluluğunu üstlenir.

Git’in versiyon geçmişi sayesinde, ajanın ne zaman eklendiği, kim tarafından kurulduğu, hangi değişikliklerin yapıldığı kayıt altındır.

Şemayı Güncellemek Rutin Bir İş Olmalı

İnsan organizasyon şeması güncellenirken (yeni kişi, terfi, ayrılış), ajan şeması da güncellenmelidir.

Bir ajan artık kullanılmıyorsa, şemadan çıkarılmalıdır. Bir ajanın yetkileri değişiyorsa, şemaya yansıtılmalıdır. Bir ajanın sahibi değişiyorsa, responsible_id güncellenmelidir.

Bu güncellemeler, her departman kendi iş akışının parçası olmalıdır. Ajanlar, araçlar veya yazılımlar gibi değil, organizasyonun parçaları olarak görülmeli.

Neden Bu Önemli

Organizasyon şemasında ajanların yer almaması, sorumlulukların uçuruma düşmesine yol açar. Bu, yalnızca bir denetim problemi değil; kurumsal güven ve şeffaflık eksikliğidir.

Ajanlar gün geçtikçe daha fazla iş üstlenecek. Müşteri iletişimi, kod inceleme, faturalama, raporlama. Her birinde karar verecek. Her birinde iz bırakacak. Her birinin bir sahibi olmalı.

Şemada ajan yoksa, sahiplik yoktur. Sahiplik yoksa, hesap verebilirlik yoktur. Hesap verebilirlik yoksa, kurum da ajanların yaptığı işleri denetleyemez.

Bu durumda, ajanların verimliliği bir yana, riski de büyür.

Sonraki Adım

Şirketinizde ajanlar kullanılıyorsa, şu sorulara cevap arayın:

Mevcut ajanlar neler? Hangileri resmi olarak tanımlanmış? Bu ajanların sahipleri kimler? Responsible_id tanımlı mı? Ajanların politika dosyaları var mı? Ajanların işleri kim onaylıyor? Ajanların kayıtları nerede tutuluyor?

Bu soruların cevapları yoksa, ajanlarınız henüz şemaya oturtulmamış demektir. Bu, organizasyonel risktir.

Riski azaltmanın yolu şudur: ajanları şemaya dahil etmek. Her ajan için sahiplik, politika ve onay akışını tanımlamak. Şemayı Git ile versiyonlamak. Bu adımları atarak, görünmez ajanlar yerine, görünür, yönetilen ve denetlenebilir ajanlara sahip olursunuz.