Hibrit Ekiplerde İş Bölümü ve Onay Akışı Nasıl Kurulur?

Bir departmanda hem insan hem ajan çalışıyorsa, iş akışı otomatik olarak düzenlenmez. Ajanlar Birbirine Nasıl İş Devreder? yazısında A2A delegasyon kurallarını gördük. Politika ve Ajan Durumu yazısında ise her ajanın sınırlarını, durumunu ve becerilerini tanımladık. Bugün bu iki dünyanın aynı ortamda nasıl bir araya geldiği noktasındayız: hibrit ekipler.

Hibrit ekip demek sadece “insanların yanında ajanlar var” demek değil. Her iki tarafın da aynı hedefe hizalanmış, sorumlulukları net ve onay mekanizmaları çalışır durumda olması gerekir. Aksi takdirde ortaya “herkes kendi ChatGPT’yle kendi işini yapan” bir gölge AI ortamından farklı olmayan bir kaos çıkar. Rol belirsizliği, onay kaybı ve denetim eksikliği gibi sorunlar, yalnızca insan ekiplerde değil, ajanların da olduğu karmaşık yapılarda daha da belirgin hale gelir.

İnsan ve Ajan: Aynı Ekibin Farklı Üyeleri

Ajan Nedir: AI Aracından Ajanına? yazısında vurguladığımız gibi, aracın (tarayıcı sekmesindeki chatbot) ve ajanın (tanımlı sorumluluğu, modeli, becerileri ve politikası olan varlık) farkı burada kritik hale gelir. Ajan bir görevi “kafasına göre” yapmaz; önceden tanımlanmış bir rol ve politika çerçevesinde çalışır.

Hibrit bir ekip düşünün: bir mühendis bir ajanı yazılım tasarımı için kullanırken, başka bir ajan aynı tasarımı test eder. İnsan mühendis sonucu onaylar, ajan ise dokümantasyonu otomatik olarak günceller. İşin bölünmesi şöyledir:

• İnsan: Yaratıcı kararlar, stratejik öncelikler, son onay.
• Ajan: Tekrarlayan görevler, veri toplama, ön derece değerlendirme.

Ama bu bölümü yalnızca “insan yapar, ajan yardımcı olur” diye kurmamak gerekir. Bazen ajan ön değerlendirme yapar, insan stratejik yönü belirler, ajan uygular. Bazen insan başlar, ajan detaylandırır, insan son onayı verir. Önemli olan, bu akışın önceden tanımlı olması ve organizasyon şemasında görünür olmasıdır.

Eğer bu akış kayıpsa, ajanların kimin ne için çalıştığı anlaşılamaz. İnsan mühendis bir tasarım değişliği yaptığında, ajanın eski kurala göre mi yoksa yeni kurala göre mi hareket edeceği belirsiz kalır. Bu belirsizlik, hataya ve güven kaybına yol açar.

Onay Hattı: Kim Ne Karar Veriyor?

Organizasyon Şeması Neden Ajanları da Kapsamalı? yazısında belirttiğimiz gibi, her ajanın bir sorumlusu olmalı. Onay hattı da bu sorumluluk çerçevesinde kurulur.

Hibrit ekiplerde en sık yapılan hata, tüm görevlerin ajanlara bırakılması veya tüm ajan çıktılarının insan tarafından tek tek onaylanmasıdır. İkisi de ölçeklenmez.

Sağlıklı bir model şudur:

1. Ajan ön değerlendirme yapar: Veri toplar, ilk çıktıyı üretir, riskli olan noktaları işaretler.
2. İnsan onaylar veya düzelter: Yalnızca önemli karar noktalarında müdahale eder.
3. Ajan uygular ve izler: Onaylanan kararları uygular, süreci kayıt altına alır.

Bu üç adımda her şeyin kayıtlı olması gerekir. Aksi takdirde “kim ne zaman neyi onayladı?” sorusuna cevap verilemez. Denetim yapılamaz, hata geri izlenemez ve sorumluluk paylaşılamaz.

Örneğin bir kalite kontrol ajanı ürün test sonucunu “başarısız” olarak işaretlediğinde, bu sonucu insan kalite müdürü mü onaylayacak, yoksa otomatik olarak üretim ajanına geri dönecek mi? Bu kural, Politika ve Ajan Durumu yazısında gördüğümüz policy.md dosyasında tanımlanmalıdır. Politika dosyası olmadan, ajan ne yapacağını bilemez, insan da neyi onaylayacağını bilemez.

Config-as-Code: Organizasyon Yapısını Git ile Yönetmek

Yazılım dünyasında alan yapılandırmasını kod olarak yönetmek (config-as-code) bir standarttır. Aynı fikri organizasyon yapısına uygulamak mümkün. Departmanlar, roller, ajanlar, onay hattı ve politika kuralları bir Markdown veya YAML dosyasında tanımlanabilir.

Şirketinizde Kaç AI Ajanı Çalışıyor, Kimse Bilmiyor? yazısında gölge AI sorununu tanımladık. Gölge AI, kurumsal altyapı dışında, kayıt altında kalmadan çalışan AI kullanımıdır. Config-as-code bu sorunu tam olarak ortadan kaldırır: organizasyon değişikliği bir PR ile yapılır, geçmişe dönük bakış, denetim izi ve geri dönüş imkanı vardır.

Ne kazanılır?

• Versiyon kontrolü: Organizasyon değişikliği bir PR ile yapılır. “Bu onay hattı dün böyle miydi?” sorusuna dosya geçmişi cevap verir.
• İnceleme: Yeni bir ajan departmana eklendiğinde veya bir onay hattı değiştirildiğinde, değişiklik başka birinin gözüyle kontrol edilir.
• Tekrar edilebilirlik: Aynı yapı farklı ortamlara (geliştirme, test, üretim) hızlıca uygulanır.
• Güven: Dosya tabanlı yapı, yetkisiz değişiklikleri zorlaştırır ve tüm değişikliklerin kayıt altında kalmasını sağlar.

Şu anda birçok şirket, insan organizasyonunu hâlâ Excel ve yetkili kişilerin belleğiyle yönetiyor. Ajanlar bu denklemi daha da karmaşıklaştırıyor. Config-as-code yaklaşımı, hem insan hem ajan kaynaklarını aynı sisteme oturtarak öngörülebilirliği artırır.

Burada en çok tercih edilen yaklaşım, organizasyon yapısını doğrudan kod deposunda tutmaktır. Bir departman müdürü yeni bir ajan eklemek istediğinde, sadece bir YAML dosyasına ilgili rolü, becerileri ve onay hattını ekler ve bir PR açar. IT ve yönetici ekipler bu değişikliği gözden geçirir, onaylar ve merge eder. Artık organizasyon değişikliği, yazılım dağıtımı kadar şeffaf ve denetlenebilir hale gelir.

Sonuç

Hibrit ekipler, ajanların ve insanların aynı hedef için çalıştığı, ancak rollerin net olduğu yapılardır. Onay hattı organizasyon şemasında görünür, politika dosyasında yaşar ve tüm değişiklikler versiyonlanır.

Bu haftaki serinin yedinci ve son yazısında, tüm bu kavramları bir araya getireceğiz: gölge AI’den yapılandırılmış ajan organizasyonuna geçişin, Markdown ve Git altyapısının neden tek başına yeterli olmadığı, ancak güven ve denetim sağladığı noktasını ele alacağız.