Ajanlar Birbirine İş Devrederken Neler Oluyor? A2A Delegasyon, Onay Akışı ve Sorumluluk

Çoğu şirkette AI ajanları tek başına çalışır. Bir ajan bir işi alır, kendi başına tamamlar, sonucu rapor eder. Bu model, tek ajanlı görevler için yeterlidir. Ancak işin doğası gereği birden fazla ajanın koordineli çalışması gereken senaryolar ortaya çıktığında, bu yalıtımlı yaklaşım yetersiz kalır.

İşte bu noktada Agent-to-Agent (A2A) delegasyon devreye giriyor. Bir ajanın, işinin bir kısmını başka bir ajana devretmesi. Basit gibi görünüyor, ancak bu devretme süreci, sorumluluk, onay ve doğrulama gibi bir dizi operasyonel sorunu beraberinde getiriyor.

A2A Delegasyon Senaryosu: Bir Yazı Ajanı ve Araştırma Ajanı

Bir teknik yazı ajanının çalıştığını düşünelim. Müşteri için bir blog yazısı taslağı hazırlıyor. Taslağın üçüncü bölümü, sektörel verilerle desteklenmesi gereken bir konu. Yazı ajanı bu konuda yeterince derinleşemiyor veya kaynakları doğrulama kapasitesi sınırlı.

Bu durumda yazı ajanı bir karar veriyor: Bu bölümü araştırma ajanına devret. Delegasyon mesajı şöyle olabilir: “Aşağıdaki beş kaynaktan 2025 verilerini çek, sektör büyüme oranlarını özetle ve kaynakça olarak döndür. Tahmin veya yorum ekleme.”

Araştırma ajanı görevi alıyor, beş kaynağı tarıyor, özeti oluşturup yazı ajanına geri gönderiyor. Yazı ajanı özeti kontrol ediyor, kendi taslağına ekliyor ve yazıyı tamamlıyor.

Bu senaryoda kritik soru şu: Eğer araştırma ajanı yanlış bir kaynak kullanmışsa, kim sorumlu?

Sorumluluk Boşluğu ve Üç Güvenlik Katmanı

A2A delegasyonunda en tehlikeli durum, sorumluluğun kimde olduğunun belirsizleşmesidir. Üç ajan veya iki ajan bir zincirde çalıştığında, her ajan kendi görevini yapıyor gibi görünür; ancak hata kaynağı, zincirdeki herhangi bir noktada gizli olabilir.

Bu riski azaltmak için üç katmanlı bir güvenlik modeli kurulabilir:

Birinci katman: Devreden ajanın sorumluluğu. Yazı ajanı araştırma ajanına iş devrederken, devretilen kaliteden sorumlu kaldığını kabul eder. Araştırma ajanı hata yaparsa, bu hatayı yakalayan ve düzelten yazı ajanıdır. Bu, onay mekanizması olmadan çalışan bir değerlendirme süreci yaratır.

İkinci katman: Veto noktaları. Bazı devretmeler risk taşır. Örneğin, yazı ajanının araştırma ajanına müşteri verisi erişimi izin vermesi veya araştırma ajanının harici bir API’ye otomatik istek atması gibi. Bu tür riskli devretmeler, insan onayı gerektiren veto noktaları oluşturur. Proje müdürü veya veri sorumlusu, veto noktasında devretmeyi onaylar veya reddeder.

Üçüncü katman: Sonuç doğrulama. Araştırma ajanı işini bitirdiğinde, yazı ajanı sonucu kabul etmeden önce doğrulama yapar. Bu doğrulama, otomatik veya manuel olabilir. Yüksek riskli bilgi için her zaman insan doğrulaması gerekir.

Onay Hiyerarşisi: Kimin Yetkisi Ne Zaman?

Bir organizasyonda ajanlar birbirine iş devrederken, onay gereksinimi risk seviyesine göre değişir. Üç seviyeli bir hiyerarşi öneriyorum:

Seviye 1: Ajanlar arası düşük riskli iş devri. Örneğin, araştırma ajanının yazı ajanına bir özet göndermesi. Bu tür devretmeler, aynı iş akışının parçası oldukları için otomatik onaylanır.

Seviye 2: Sınırlı otonomi. Mali ajanın 10.000 TL altında fatura oluşturması. Bu limit altında özerk davranır; üzerinde, mali müdür onayı gerektirir.

Seviye 3: Tam insan onayı. Her türlü harici veri paylaşımı, hukuki veya mali risk taşıyan devretmeler. İnsan, devretme mesajını onaylamadan ajan işe başlayamaz.

Bu hiyerarşi, ajanların ne zaman özgürce çalışabileceğini ve ne zaman insan müdahalesine ihtiyaç duyacağını netleştirir.

Sonuç Doğrulama: Otomatik, Manuel veya Risk Tabanlı?

Araştırma ajanının döndürdüğü özeti, yazı ajanı üç şekilde doğrulayabilir:

Otomatik doğrulama: URL’ler açılır, metinler kaynaklarla karşılaştırılır, tarih ve veri tutarlılığı kontrol edilir. Düşük riskli, yapısal kontroller için uygundur.

Manuel doğrulama: Bir insan, özeti orijinal kaynaklarla karşılaştırır. Yüksek riskli bilgi için gerekli.

Risk tabanlı doğrulama: Bilginin doğasına göre doğrulama derinliği belirlenir. Para, hukuk, sağlık veya müşteri verisi her zaman manuel doğrulama gerektirir.

Doğrulama başarısız olursa, sonuç reddedilir ve ajana tekrar gönderilir. Tekrar eden hatalar, ajanın politikasında kısıtlamaya yol açar.

Operasyonel Bir Örnek: Yazı, Araştırma ve Mali Ajanı

Bir organizasyonda üç ajan çalıştığını düşünelim:

Günlük iş akışı şöyle işler:

  1. Müşteri, bir blog yazısı talebi gönderir.
  2. Yazı ajanı taslağı hazırlar.
  3. Üçüncü bölüm için araştırma ajanına delegasyon gönderir.
  4. Araştırma ajanı özeti döndürür.
  5. Yazı ajanı özeti doğrular, yazıyı tamamlar.
  6. Müşteri onayı gelince yazı yayınlanır.
  7. Mali ajan, yazılı sözleşmeye göre fatura oluşturur.

Bu akışta her ajanın sorumluluğu net. Hata kaynağı belirlenebilir. Onay mekanizmaları risk seviyesine göre çalışır.

Sorumluluk İzleme: Git ve policy.md ile Versiyon Kontrolü

A2A delegasyonunda sorumluluğun izlenebilir olması için, her devretme kaydının tutulması gerekir. policy.md dosyaları, hangi ajanın hangi işi devredebileceğini, onay kurallarını ve veto noktalarını tanımlar.

Bu dosyalar Git’te versiyonlandırıldığında:

Aksi halde, ajanların ne yaptığı, neyi devrettiği ve kimin onay verdiği kaybolur.

Sorular: Organizasyonunuzda A2A Delegasyon Var Mı?

Sorunuz: “Bu ajanlar birbirine iş devreder mi? Devrederse, delegasyon kuralı nedir? Onay mekanizması nedir ve sonucu kim doğrular?”

Cevaplarınız belirsizse, ajanlarınızın birbirine iş devretmesine izin vermeyin. Bu izin, sorumluluk ve onay mekanizmaları tanımlanmadan tehlike yaratır.

Kurumsal A2A delegasyonu, yalnızca şu koşullarda güvenlidir:

Bu ölçütlerin kaçını karşılıyorsanız, organizasyonunuzda o kadar güvenli A2A delegasyonu vardır.