Rol, Politika, Delegasyon ve Versiyon Kontrolü: Ajan Organizasyonunun Tamamı

Altı yazı boyunca tek bir sorunu farklı açılardan ele aldık. Şirketlerde çalışanların kendi hesaplarıyla iş yapan, kimsenin görmediği AI araçları var. Bu gölge AI durumunu ilk yazıda somut senaryolarla anlattık. Sonra ajan ile aracı ayırdık, organizasyon şemasına ajan düğümleri ekledik, politika ve durum tanımını yazdık, ajanlar arası iş devri ve hibrit ekip düzenini inceledik. Bu son yazıda parçaları bir araya getirip tam tabloyu görelim.

Parçalar birleşince ne ortaya çıkıyor?

Her parça tek başına yarı çözüm. Ajan tanımlarsınız ama politika yoksa sınırları yoktur. Politika yazarsınız ama organizasyon şemasında yeri yoksa sahipsizdir. Sahibi vardır ama delegasyon kuralları yoksa işleri elle taşıtırsınız. Hepsini tanımlarsınız ama versiyon kontrolü yoksa kim neyi ne zaman değiştirdiğini bilmez.

Birlikte çalıştıklarında ortaya şu yapı çıkıyor:

1. Her ajan tanımlı bir varlık. Adı, sorumlusu, kullandığı model, sahip olduğu beceriler ve uymak zorunda olduğu politika kayıtlı.
2. Her ajan organizasyon ağacında bir düğüm. Bir departmana bağlı ve bir responsible_id’ye sahip. Yani her ajanın arkasında hesap verebilir bir insan var.
3. Politika dosyası sınırları çiziyor. Hangi becerileri çağırabilir, hangi veriye erişebilir, hangi durumda insan onayı gerekir. Taslak, aktif ve pasif durumları sayesinde bir ajanın üretime alınması bilinçli bir karar.
4. İş devri kurallı. Bir ajan yapamadığı işi başka ajana devredebilir, kritik noktalarda onay akışı devreye girer, sonuç teslim alınmadan önce kontrol edilir.
5. Bütün bu tanımlar dosyada ve Git’te. Organizasyonun kendisi versiyonlanıyor. Değişiklik pull request ile öneriliyor, gözden geçiriliyor ve geçmişiyle birlikte saklanıyor.

Buna config-as-code diyoruz ama asıl önemi şu: şirketin AI kullanım biçimi artık kişilerin başındaki bilgi değil, denetlenebilir bir yapı.

Slack veya ChatGPT neden tek başına yetmiyor?

Çoğu ekip bu ihtiyacı önce mevcut araçlarla çözmeye çalışıyor. Bir Slack kanalı açıp bot ekliyorsunuz, ya da ekipteki herkese ChatGPT Enterprise lisansı veriyorsunuz. Kısa vadede işe yarar gibi görünüyor.

Sorun şu ki bu araçlar konuşma yüzeyi. Ajanın kim olduğunu, kimin sorumlu olduğunu, neler yapabileceğini, kimi devredip kimi devredemeyeceğini bilmiyorlar. Bu bilgileri sohbet içine gömerseniz bir süre sonra kimse hangi ajanın hangi kurallarla çalıştığını hatırlamaz. Sorumlu kişi değiştiğinde hiçbir yeri güncellemezsiniz, çünkü güncellenecek tek bir yer yoktur. Bir ajanın davranışı değiştiğinde neyin değiştiğini bulmak için mesaj geçmişini karıştırırsınız.

Dosya tabanlı Markdown tanımları ve Git geçmişi bunu tersine çevirir. Ajanın tanımı bir dosyadır, politikası bir dosyadır, değişiklik bir commit’tir, tartışması PR üzerindedir. Yeni katılan biri depoya bakarak organizasyonda hangi ajanların olduğunu, kimin neye yetkili olduğunu on dakikada öğrenir. Denetim soran birine Git log’unu gösterirsiniz.

Self-hosted olmasının da ayrı bir payı var: ajan tanımlarınız, politikanız ve organizasyon yapınız kendi altyapınızda durur. Hangi modelin kullanılacağı, verinin nereden geçeceği şirket kararıdır, araç satıcısının yol haritasının değil.

Küçük bir örnek üzerinden

Tekrar aynı senaryo: üretim firmasında teklif hazırlayan bir ajan düşünelim. Bu seride anlatılan yapıyla tanımı kabaca şöyle olur:

• Adı: teklif-ajani. Departmanı: satış. Responsible_id: satış müdürünün kullanıcı kimliği.
• Becerileri: ürün kataloğundan fiyat çekme, müşteri geçmişini okuma, teklif taslağı oluşturma. Maliyet hesabı becerisi yok; o işi maliyet-ajani’na devreder.
• Politikası: belirli bir tutarın üzerindeki teklifler insan onayından geçmeden gönderilemez. Müşteri sözleşme verisi sadece okunabilir.
• Durumu: aktif. Tanımı ve politikası Git’te; son değişikliği iki hafta önce, bir PR ile yapıldı ve satış müdürü onayladı.

Bu dört satır, altı yazıdaki tüm kavramların tek örnekte buluşması. Buraya kadar gelmek için yeni bir teknoloji gerekmiyor; gerekli olan ajanları araç olarak değil, organizasyon üyesi olarak düşünmek.

Kurulum sonrası günlük iş nasıl değişiyor?

Bu yapının kurulduğunda fark en çok üç anda ortaya çıkar.

Birincisi yeni bir ajan ihtiyacı doğduğunda. Eskiden biri “şu işi yapan bir bot kuralım” der ve kimse ne kurulduğunu tam bilmezdi. Şimdi istek bir PR ile açılır: ajanın tanımı, sorumlusu ve politikası yazılır, ilgili kişiler gözden geçirir, merge edilince ajan resmen var olur. Kurulma anı kayıtlıdır.

İkincisi bir şey ters gittiğinde. Bir ajan yanlış veriyle çalıştıysa veya yetkisi olmayan bir beceriyi çağırdıysa Git geçmişi son değişikliği saniyeler içinde gösterir. Sorun politika mıydı, beceri tanımı mıydı, devri kuralı mıydı, tek tek ayırt edebilirsiniz. Mesaj geçmişinde tahmin yürütmek zorunda kalmazsınız.

Üçüncüsü insanlar değiştiğinde. Sorumlu müdür şirketten ayrıldığında responsible_id’yi tek satırda güncellersiniz ve ajanın sahipsiz kalmadığını herkes görür. Gölge AI dünyasında bu değişim çoğu zaman hiç fark edilmez; ajan sahipsiz kalır ama çalışmaya devam eder.

Nereden başlamalı

Hepsi birden kurulmaz. Sıralamamız bu serinin sırasıydı ve pratikte de aynı sıra işliyor:

1. Önce mevcut durumu çıkarın. Kim hangi aracı, hangi hesapla, hangi iş için kullanıyor?
2. Gerçekten iş yapan her şeyi ajan olarak tanımlayın ve her birine bir sorumlu atayın.
3. Sınırları politika dosyasına yazın. İlk hali eksik olabilir; önemli olan yazılı olması.
4. İnsan onayı gereken noktaları belirleyin ve iş devri kurallarını buna göre kurun.
5. Tümünü Git’e alın. Bundan sonra her değişiklik PR ile.

Şirketinizde ajanları bu şekilde organize etmeyi düşünüyorsanız veya mevcut kurulumunuzu bu çerçeveye taşımak isterseniz yazabilirsiniz; bu konudaki deneyimlerimizi paylaşmaktan memnuniyet duyarız.