Ajanın yanına neden bir çalışma katmanı gerekir?

Bir model bir soruyu yanıtlayabiliyorsa, neden onu doğrudan çalışanların dosyalarında çalıştırmayalım? Çünkü bir yanıt üretmekle bir dosyayı değiştirmek arasında kurum açısından önemli bir mesafe var. Bilgi işlem çalışanı bir yapılandırma hatasını araştırırken modelden açıklama istemek başka, modelin depoda dosya düzenleyip komut çalıştırmasına izin vermek başka. İkinci durumda soru yalnızca yanıtın doğruluğu değil: iş nerede koştu, hangi kimlikle yapıldı, hangi araç çağrısı neye dayanarak ilerledi?

Bu mesafeyi kapatan katmana çoğu zaman harness deniyor. Burada sihirli bir güvenlik kutusundan söz etmiyoruz. Modelin etrafında, oturumu yürüten istemci, kullanılabilen araçlar, çalışma ortamı, kuruma ait bağlam ve karar noktaları var. Böyle bir katman yoksa bir ekip, ajanı ya yalnızca metin üreten bir sohbet olarak kullanır ya da dosya ve terminal erişimini işin sahibini, sınırlarını ve izini düşünmeden açar. İki uç da farklı işleri aynı davranışa zorlar.

Hazır istemci, kuruma ait çalışma düzeni

agentic-organization içindeki ADR-0001, geliştiricinin kendi makinesindeki çalışma istemcisi olarak opencode’u seçiyor. Bunun nedeni yeni bir ajan döngüsü ve terminal arayüzü yazmanın getireceği bakım yükü. Dosya düzenleme, terminal kullanımı ve araçlarla çalışma zaten bir istemcinin işi. Organizasyonun asıl sorusu ise o istemcinin hangi model geçidini, hangi kuralları ve hangi kurumsal araçları kullanacağı.

Kararda üç ayrı temas noktası var: yönetilen yapılandırma model bağlantısının yönünü belirliyor; kurum eklentisi araç çağrısı öncesinde politika kararı istiyor ve olayları raporluyor; sunucudaki MCP yüzeyi kurumun beceri ve iş akışı araçlarını istemciye açıyor. Bunlar bir ürünün tek bir ekranına sıkışmış özellikler değil. Bir çalışanın iş istasyonunda başlayan eylemle kurumun kayıt ve karar noktası arasında köprü kurma girişimi. Önceki politika yazısında de belgeyi okumak ile bir araç çağrısında kuralı işletmek arasındaki farkı ele almıştık.

Burada alternatifler açıkça değerlendirilmiş. Sıfırdan kurumun kendi terminal istemcisini ve yürütücüsünü yazmak daha fazla kontrol verebilirdi; ama ajan döngüsü, dosya farkı, izin akışı ve araç entegrasyonu da baştan yapılacaktı. Yürütücüyü bütünüyle sunucuya taşımak ise yerel dosyalar için ayrı bir protokol ve gecikme demek. ADR-0001 bu nedenle geliştirici için mevcut istemciyi alıp kurum sınırlarına bağlamayı seçiyor. Bu karar, her çalışanı aynı terminale yönlendirmek anlamına gelmiyor.

Bir komutun çevresindeki işler

ADR-0009’un 3pa iş istasyonu aracı, bu tercihin pratik yüzünü anlatıyor. run kodu önce geçide erişimi ve persona oturumunu kontrol ediyor. Ardından sunulan kurum yapılandırmasının imzasını doğrulayıp onu sandbox içindeki istemci yapılandırmasına bağlıyor. Normal compose yolunda opencode, proje dizini bağlanmış bir konteynerde çalışıyor; konteynerin ağ çıkışı ayrı bir vekilden geçiyor. doctor komutu konteyner altyapısı, oturum, erişim ve imzalı yapılandırma gibi ön koşulları denetlemek için var. Böylece geliştiricinin her işte bu parçaları elle birleştirmesi gerekmiyor.

Bu ayrımın sahibi yine insan. Proje dizininin bağlanması, oradaki dosyaların ajan tarafından değiştirilebileceği anlamına gelir; sandbox, yanlış bir değişikliği geri alan bir sürüm kontrol sistemi değildir. Ayrıca run için ağ vekilini devre dışı bırakan ve imza doğrulamasını atlayan seçenekler kodda bulunuyor. Normal yolun özelliklerini bütün çalıştırma biçimlerine yaymak doğru olmaz. Bir kurum, çalışanların hangi başlatma yolunu kullandığını ve hangi istisnaları kabul ettiğini ayrıca yönetmeli.

Araç kararında da benzer bir sınır var. İş istasyonu eklentisinin tool.execute.before kancası politika servisine danışıyor. Karar gerçekten zorlanıyorsa deny ve ask sonuçlarında çağrı durduruluyor; ask bugün tamamlanmış bir onay ekranına dönüşmüyor. Eklenti, servis erişilemez olduğunda varsayılan olarak işlemi sürdürür; ayrıca hata halinde duracak biçimde ayarlanabilir. Politika motorunun varsayılan dry_run kipi de normal kararları kaydeder, zorlamaz. Bunlar bir harness’in varlığıyla politikanın her zaman uygulanmasının aynı iddia olmadığını gösteriyor. Güvenlik sınırı yazısında bu farkı daha ayrıntılı ele almıştık.

Her departman aynı masada çalışmıyor

Geliştiricinin deposu kendi makinesinde olabilir. Satın alma ekibinin işi teklifleri okumak ve karşılaştırmak; üretim ekibi bakım kayıtlarına bakar. Finansta tablolar, İK’da hassas belgeler söz konusudur. Bu örnekler ürünün bu işlemleri eksiksiz otomatikleştirdiği anlamına gelmez. Her birinde araçlar, erişim yetkisi, veri konumu ve gözden geçirme sorumlusu değişir. Hepsine aynı yerel terminal paketini kurmak, organizasyon farkını yok saymak olur.

Nitekim ADR-0014, geliştiricinin dizüstü bilgisayarındaki sandbox yolunu korurken departmanlar için sunucu tarafında çalışma alanı kararını ayırıyor. Aynı kaydın her departmana özel terminal istemcisi kurma kararı ise ADR-0022 tarafından değiştirilmiş: güçlü kullanıcılar için mevcut terminal ekosistemi, diğer çalışanlar için daha sade web görünümü öngörülüyor. Bunları teslim edilmiş bütünleşik bir deneyim gibi anlatmamak gerek. Depodaki bilinen sınırlar, departman çalışma alanında bağlanma ve boşta askıya alma gibi yaşam döngüsü parçalarının henüz eksik olduğunu belirtiyor.

Buradaki ortak fikir belirli bir terminal markası değil. Bir personanın görevi ve bulunduğu ortam, hangi bağlamı göreceğini ve hangi işi başlatacağını etkiler. Üretim için yanlış kayıt üzerinde düzenleme, finans için yanlış dönemin dosyasıyla çalışma, İK için erişim dışı bir belgeyi okuma farklı risklerdir. Harness bu farkları kendiliğinden çözmez; ama araç, kimlik ve politika kararlarının nerede buluşacağını konuşmak için somut bir yer sağlar. Kurumun yapması gereken, bu yerin çevresindeki yetkileri kendi iş akışına göre tarif etmektir.

Başlangıç için tek bir işi seçip dört şeyi yazmak yeterli: kim başlatıyor, dosyalar nerede, ajan hangi araçları çağırabiliyor ve çağrı durduğunda işi kim devralıyor? Sonra aynı işi normal kipte ve servis erişimi kesildiğinde deneyip farkı görmek gerekir. Ajanı yalnızca iyi yanıt veren bir model olarak değerlendirmek, dosya değiştirme anındaki kurumsal sorumluluğu ıskalar.

Bu nedenle harness sorusu aslında organizasyon sorusu: çalışanın başlattığı bir işi hangi istemci, hangi çalışma ortamı ve hangi denetim noktası taşıyacak? agentic-organization deposundaki ADR-0001, ADR-0008 ve ADR-0009 bu seçimin geliştirici iş istasyonu tarafını; ADR-0022 ise farklı kullanıcıların aynı arayüze zorlanmaması gerektiğini gösteriyor. Kendi ekibinizin dosya ve araç akışına bakınca hangi parçanın eksik olduğu daha görünür hale gelir.

Doğrulama notu: Bu yazıdaki tasarım kararları ADR-0001, ADR-0008, ADR-0009, ADR-0014 ve ADR-0022 ile 3pa run, 3pa doctor, iş istasyonu eklentisi ve sandbox kodu karşılaştırılarak yazılmıştır. Departman çalışma alanının eksikleri ve zorlamanın kip bağımlılığı ayrıca kontrol edilmiştir.