Eksik Katman: Yapay Zeka Ajanlarını Kurumsal Hiyerarşilere Göre Yapılandırma

Kurumların yapay zekâyla çalışmalarını nasıl yapılandırdığına dair bir referans model

Jose Martinez · 1 Ekim 2026 · v1.8.1 (Claude Code üzerinde ölçülmüştür; 1 Ekim 2026'da Anthropic belgeleriyle yeniden doğrulanmıştır)

Beş satırda özet.

1. Kurumlar birer ağaçtır: firma, iş kolu, proje, görev. Oysa Claude'un projeleri düzdür: Sohbetin tek bir 3.000 karakterlik organizasyon bloğu vardır; sohbetteki ve Cowork'teki projeler iç içe geçmez ya da birbirinden miras almaz ve bir projede bağlayıcı hesap bir kişiye veya tüm kuruma ait olur, asla bir dala değil.

1. Bu yüzden her proje, kendi iş kolunun kurallarının elle eklenmiş bir kopyasını alır; bu kopyalar zamanla birbirinden uzaklaşır ve kimse hangi kuralın bir yanıtı ürettiğini göremez.

1. Anthropic bu ağacı çoktan iki kez inşa etti. Claude Code talimatları klasöre göre iç içe geçirir ve 1 Ekim 2026 itibarıyla bir kişinin modlarından önce kurumun modlarını çalıştırır. Slack üzerindeki Claude Tag ise talimatları ve kimlik bilgilerini kurumdan çalışma alanına, oradan da kanala aktarır. Ancak ikisi de projeye ulaşamaz. Aynı model bunu başarabilir: Bir iş kolu katmanı, kendi klasörlerinden doğan projeler, tiplendirilmiş görevler, çakışmaları model görmeden reddeden bir derleyici ve Team planında çalışan düğüm bazlı izinler.

1. Bunu Claude Code'da iki kez ölçtüm. Birbiriyle çelişen bir kurum kuralı ve bir proje kuralı, ayrı CLAUDE.md seviyelerinde ve hiçbiri bağlayıcı olarak işaretlenmemişken: Proje kuralı 20 denemenin 20'sinde kazandı. Aynı kurum kuralı yalnızca sözcüklerle "zorunlu" olarak işaretlendiğinde: 20 denemenin 20'sinde kazandı. Öncelik yapı tarafından değil, herhangi bir katmanı düzenleyen herkesin değiştirebileceği ifadelerle belirlendi.

1. Sistem bugün çalışıyor. Geliştirdiğim bir masaüstü uygulaması, Claude Code'u bu ağacın içinde çalıştırıyor. Her katmanı bir CLAUDE.md olarak bağlar, Claude'u o düğümde kişinin yapabilecekleriyle sınırlar, çakışmayı yazıldığı anda reddeder ve her yanıtı kurallarıyla, tokenlarıyla ve inceleyicisiyle birlikte kaydeder. Ölçümlerde ağaç yapısı, düz kopyalara kıyasla %20–34 daha az talimat tokenı yükledi.

Kurumlar birer ağaçtır. Firma politikayı belirler, iş kolu standartlarını koyar, proje bunları tek bir işe uygular ve görev tek bir çıktıyı teslim eder. İçinde çalıştığım her kalite sistemi bu şekilde kurulmuştur; neredeyse her şirket dosya sunucusundaki klasör ağacı da öyledir: firma, iş kolu, yıl ve ardından her biri tüm bu bilgileri kodlayan bir iş numarasıyla adlandırılan, iş başına bir klasör.

Yapay zekâ projeleri ise düzdür. Örnek olarak Claude'u kullanıyorum çünkü her gün içinde çalıştığım ürün o ve cevabı kendi arayüzlerinin ikisinde zaten sunuyor. Claude sohbetinde projeler iç içe geçirilemez ve organizasyon talimatları herkese uygulanan, en fazla 3.000 karakterlik tek bir bloktur. Enterprise planında yöneticiler izinleri gruba göre sınırlandırabilir. Team planında ise roller tüm kurumu kapsar. Sohbette veya Cowork'te belgelenen hiçbir şey, talimatları bir departmana veya iş koluna, oradan da projelere indirgemez. Enterprise'ta beceriler ve projeler bir grupla paylaşılabilir ama bu dağıtımdır, miras alma değil.

İşte eksik olan katman budur: Kurum ile proje arasındaki katman. Bu makale neyin eksik olduğunu, neden önemli olduğunu, gerçekte ne kadara mal olduğunu ve izinleri ile veri yapısı dahil olmak üzere herhangi bir platformun uygulayabileceği bir referans modeli ortaya koyuyor.

1. Bugün var olan durum

29 Eylül – 1 Ekim 2026 tarihlerinde Anthropic belgeleriyle karşılaştırılmıştır. Claude'un bir ekibin işinin yürütüldüğü dört arayüzü vardır ve her birinin kendine özgü bir talimat modeli bulunur:

İzinler plana göre değişir:

Anthropic izinler için ağacın yarısını inşa etmiş durumda. Enterprise'ta özel roller gruplara atanır; "özel roller ayrıca bir rolün hangi bağlayıcıları ve bu bağlayıcılardaki hangi araçları kullanabileceğini de kontrol eder"; platform genelinde kurum, rol ve kullanıcı seviyeleri arasında "en kısıtlayıcı seviye kazanır", ancak bir üyenin birden fazla rolü birbirini tamamlar; yöneticiler "Geçerli rolü görüntüle" seçeneğini ve bir "Tarafından verildi" etiketini görebilir; grupların kendi harcama limitleri olabilir. Ancak bunlar bir ağaç değil, düz gruplardır ve hiçbiri talimatlara ulaşmaz. Buna en yakın şey eklentilerdir: Enterprise'ta bir sahip, bir eklentiyi ve onun becerilerini belirli bir grup için zorunlu veya varsayılan olarak yüklü hale getirebilir; bunun belirtilen bir sırası vardır ("grup ayarı, ardından kurum geneli ayar, ardından pazar yeri varsayılanı"). Bu bir projeyi değil, bir insan grubunu hedefler; projeler arasında hiçbir şey miras alınmaz ve bir beceri yine yalnızca Claude onu alakalı bulduğunda yüklenir. Team planında tüm kurumu kapsayan roller ve kişi bazlı paylaşım vardır; eklenti ayarlarının, belgelerin ifadesiyle, "grup ayarı yoktur". Üstelik Team, küçük ve orta ölçekli firmalar için tasarlanmış plandır.

Anthropic tüm ağacı, projelerin dışında iki kez inşa etti.

Claude Code'da, klasöre göre. Claude Code, CLAUDE.md dosyalarını dört seviyeden yükler; "keşfedilen tüm dosyalar birbirini geçersiz kılmak yerine bağlama eklenir", "dosya sistemi kökünden çalışma dizininize doğru" sıralanır ve alt dizinlerdeki dosyalar "talep üzerine yüklenir". Bir kurumun bloğu, her makinede yönetilen bir dosya olarak veya yönetici konsolundan metin şeklinde (claudeMd anahtarı) gelebilir. Belgeler bu sınırı açıkça belirtir: Claude bu dosyalara "zorunlu bir yapılandırma olarak değil, bağlam olarak" yaklaşır ve "iki talimat birbiriyle çelişirse, Claude rastgele birini seçebilir."

Claude Tag'de, Slack kanalına göre. Claude Tag, Team ve Enterprise'ta genel beta aşamasında olan, bir ekibin Slack'indeki Claude'dur. Ayarları bir kapsama bağlanır ve "kapsam, bir paketin uygulandığı yerdir: Varsayılan Slack erişimi (kurum geneli kök), bir çalışma alanı veya tek bir kanal." Bu makalenin geri kalanında talep edilen üç şey şimdiden mevcut:

• Talimatlar miras alınır. "Kapsam başına özel talimatlar birleştirilir; önce Varsayılan Slack erişimi, sonra çalışma alanı, ardından kanal. Bir kanalın talimatları, üsttekinin yerini almak yerine ona ekleme yapar."

• Kimlik bilgileri dala aittir. Kanallarda Claude, bir yöneticinin bir kapsama eklediği hizmet hesaplarıyla işlem yapar ve "en dar kapsamdaki kimlik bilgisi kullanılır: kanal çalışma alanını, çalışma alanı da Varsayılan Slack erişimini yener."

• Erişimin nereden geldiğini görebilirsiniz. Her bağlayıcı, depo ve eklenti satırı, daha geniş bir kapsamdan "Miras alındığını" veya bir paketten "Eklendiğini" belirtir. Harcamalar kurum ve kanal bazında sınırlandırılır ve kanal bazında raporlanır.

Sınırlar da belgelenmiştir. Ağaç Slack'in şeklini alır: üç sabit seviye vardır ve Slack kanalları iç içe geçmez. Talimatlar "zorunlu bir koruma mekanizması değil, bir yönlendirmedir" ve belgeler kapsamlar arası çakışmaları kontrol eden bir mekanizmadan bahsetmez. "Her görevin ve kimin istediğinin eylem bazlı bir kaydı yoktur." Ayrıca bir projenin sınırında durur: "claude.ai adresindeki Projeler burada geçerli değildir; Claude Slack'te bir Projenin talimatlarını veya bilgi tabanını okumaz ve bir kanal bir Projeye yönlendirilemez."

1 Ekim 2026'da ne değişti. Erken erişimde olan modlar, Claude Code 2.1.287 ile aktif edildi: Bunlar, bir eklentinin içinde çalışan ve bir promptu veya sistem promptunun bir bölümünü yeniden yazabilen, bir araç çağrısını engelleyebilen veya değiştirebilen, bir izin talebini onaylayabilen ya da reddedebilen ve arayüzde paneller çizebilen fonksiyonlardır. Bunlarla ilgili üç detay burada önem taşıyor:

• Belirtilmiş bir sırayı taşırlar. Yerleşik bir koruma mekanizması ve kurumun kendi modları önce, ardından kişinin yüklediği modlar çalışır. "İlk mod en dıştakidir: olayı diğerlerinden önce, sonucu ise onlardan sonra görür ve diğerlerinin çalışıp çalışmayacağına karar verir." Koruma mekanizmasının yüklendiği yerde (yönetilen ayarlara sahip bir makine veya Team/Enterprise girişi), bir kişinin modu "sistem promptunu, yönetilen CLAUDE.md'nizi ve diğer yönetilen talimatları" değiştiremez ve bir reddetme kuralının engellediği bir araç çağrısını onaylayamaz. İşte bu, makalenin talep ettiği, yapı tarafından belirlenen önceliktir. Bu bir kilit değil, varsayılandır: Claude Code'u --safe-mode ile başlatan biri, kurumunki dahil yüklü modlar olmadan çalışır, ancak yönetilen kancalar ve reddetme kuralları geçerliliğini korur.

• Sıranın iki sahibi vardır. Kurumun modları kişinin modlarından önce veya kurum tercih ederse sonra çalışır. İş kolu için bir seviye yoktur. Yönetici konsolundan iletilen ayarlar "kurumdaki tüm kullanıcılara eşit şekilde uygulanır. Grup bazlı yapılandırmalar henüz desteklenmemektedir." Her grup için farklı bir politika isteyen bir kurumun, her ikisi de BT üzerinden ilerleyen iki yolu vardır: Her grubun makinelerine farklı bir ayar dosyası dağıtmak veya "IdP grubu başına yönetilen ayarlar ileten" kendi sunucunuzda barındırılan bir ağ geçidi çalıştırmak.

• Sohbete ulaşmazlar ve Cowork'e düzensiz ulaşırlar. "Modlar, Claude Code CLI'da ve Claude Desktop uygulamasının Code sekmesinde çalışır." Bir mod, bir eklentinin hooks/hooks.json dosyasında gelir ve Anthropic'in eklenti destek tablosu bu dosyayı sohbette "Yok sayıldı" olarak işaretler. Aynı tablo bunu Cowork'te "Yükleniyor" olarak işaretler çünkü "Claude Desktop uygulamasındaki Cowork oturumlarını Claude Code üzerinde çalıştırır"; mod sayfaları Cowork'ten bahsetmez ve ben bunu test etmedim. Kurumun orada kontrol ettiği şey daha zayıftır: Bir Cowork oturumunda Claude Code, "kullanıcı Team veya Enterprise hesabıyla giriş yapsa bile claude.ai yönetici konsolundan sunucu tarafından yönetilen ayarları asla çekmez" ve uzak Cowork oturumlarının okuyacağı bir cihaz politikası yoktur.

Neler yayına giriyor. Cowork, Claude ile birleşiyor: Yardım merkezi artık "Claude Cowork artık sadece Claude oldu" diyor; önce Pro ve Max'te, Team ve Enterprise ise "sohbeti ve Claude Cowork'ü bugünkü haliyle koruyacak". 6 Ekim 2026'da Pro ve Max'teki yeni Cowork görevleri buluta taşınıyor. Ayrıca projelerin yeni bir sürümü, önce Claude Code'da başlayıp ardından sohbet, Cowork, Team ve Enterprise'ın takip edeceği şekilde Pro ve Max'te genel betaya girdi; bunda "bir proje tek bir konuşmadır" ve Claude bunu paralel dallara böler. Hâlâ tek bir seviyedir: "Bir proje tek bir kullanıcıya aittir" ve "beta sürecinde projeler için kurum düzeyinde kontroller yoktur."

Yani ağaç, Anthropic için yeni bir fikir değil. Kod için klasörle, Slack için kanalla var ve her ikisinde de kurum ilk sırada geliyor. Bir firmanın işini dosyaladığı yer olan projenin ne bir ebeveyni ne de üstünde bir dalı var. Anthropic'in iki başka hizmeti de aynı yönü işaret ediyor ancak bu makalenin kapsamı dışında: Claude for Government ayarları tenant, grup ve kurum zinciri üzerinden çözer ve üçüncü taraf sağlayıcılardaki Claude Desktop'ta beta aşamasında grup bazlı politikalar bulunur.

2. Neden önemli?

Projeler birer kapsayıcı değildir. Gerçek bir iş kapsayıcıdır. Bir anahtarı (iş numarası), bir ebeveyni (iş kolu), bir yaşam döngüsü (açık, kapalı, yıla göre arşivlenmiş), bir klasörü, bir müşterisi, insanları, kuralları ve teslimatları vardır. Bir Claude projesinin serbest metin bir adı vardır; anahtarı, ebeveyni ve alt öğesi yoktur ve belgelenmiş yaşam döngüsü arşivleme ve silmedir. Cowork bir projeyi yerel bir klasöre bağlayabilir, ancak bunu yalnızca elle, her seferinde tek bir proje için, bir anahtar deseni ve ebeveyn olmadan yapar. Bir iş kolu yılda yüzlerce iş açabilir. Bu da iki kötü seçenek bırakır: Her biri kuralların kendi kopyasına sahip, iş başına bir adet elle oluşturulmuş Claude projesi ya da farklı müşterilerin bağlamlarının yan yana durduğu, iş kolu başına tek bir proje.

Yük aktarım yolu kırılır. Yapı mühendisliğinde her yükün temele ulaşan kesintisiz bir yolu olması gerekir. Bir elemanı çıkarırsanız, üstündeki hiçbir şey aşağı aktarılamaz. Kurallar da aynı şekilde davranır. Kurum ile proje arasında bir katman olmadığında, bir iş kolunun standartları, şablonları ve onay kuralları yaşayacak bir yer bulamaz. Böylece her proje elle eklenmiş bir kopya alır.

Kopyalar birbirinden uzaklaşır. Bir projedeki kuralı düzeltirsiniz, diğerleri eski sürümü tutmaya devam eder. Her proje kendi yerel kontrolünden geçmeye devam eder. Uyumsuzluk ancak biri projeleri yan yana karşılaştırdığında ortaya çıkar ve regüle edilen işlerde bu kişi genellikle bir denetçidir. Altyapı ekipleri bu hatayı iyi bilir. Firefly'ın 2026 araştırmasında, katılımcıların yaklaşık üçte biri yapılandırma sapmasını maliyetli üretim hatalarıyla ilişkilendirdi ve yaklaşık beşte birinin bunu tespit edecek veya düzeltecek bir süreci yoktu.

Kimlik de düzdür. Birçok kişi birden fazla kurumda çalışır ve her birinin kendi yalıtılmış bağlamına ihtiyacı vardır. Bunlardan herhangi birinin içinde, sohbette ve Cowork'te bir bağlayıcı hesap bir dala değil, bir kişiye aittir. Enterprise rolleri bir grubun hangi bağlayıcıları kullanabileceğine karar verebilir ve bir yönetici bir bağlayıcıyı tüm kurum için tek seferde yetkilendirebilir; özel bir bağlayıcı herkes için tek bir ortak kimlik bilgisi bile taşıyabilir (beta aşamasında). Her iki durumda da hesap kişinin veya kurumundur, asla bir dalın değil: İki müşteriye hizmet veren bir danışman, her müşterinin Drive'ını o müşterinin projelerine bağlayamaz. Paylaşılan projeler durumu daha da keskinleştirir: "Bağlayıcılar yalnızca özel projelerde kullanılabilir." Claude Tag, bir Slack kanalına bağlı hizmet hesabıyla diğer tasarımın mümkün olduğunu gösterir ve bunun projede nerede durduğunu ortaya koyar. Anthropic'in Google bağlayıcı sayfası tek bir bağlı Google hesabından bahseder ve bunu değiştirmenin belgelenmiş yolu bağlantıyı kesip yeniden bağlamaktır; aşağıdaki üç açık sorun birden fazla hesap talep ediyor. Sınır kişinin kafasında yaşıyor ki bu tam da sessizce çöken türden manuel bir sınırdır.

Kimse hangi kuralın uygulandığını göremez. Claude Enterprise yöneticilere izinler için bir "Geçerli rolü görüntüle" sunar ve Claude Code'un /context komutu hangi bellek dosyalarının yüklendiğini listeler. Bir Claude Code modu artık kendi panelini çizebilir, dolayısıyla geçerli talimatlar görünümü orada herkesin geliştirebileceği bir şeydir. Claude Tag, her bağlayıcıyı ve depoyu miras aldığı kapsamla etiketler, ancak talimatlar için belgeleri "Claude'dan yönetici talimatlarını tekrarlamasını isteyin" der. Hiçbir arayüz, belirli bir yanıt için hangi talimatın hangi katmandan geldiğini göstermez. Kaynak izi olmadan denetim izi olmaz, denetim izi olmadan da kalite sistemi olmaz.

İnsanlar bunun parçalarını talep ediyor. Anthropic'in genel sorun takipçisindeki açık sorunlar (github.com/anthropics/claude-code), 2026-10-01 tarihinde kontrol edilmiştir:

Yedinci bir sorun olan #47741, kurum tarafından yönetilen bir CLAUDE.md talep etmişti ve Claude Code'da zaten olduğu için kapatıldı. Mesele şu: Katmanlar Code'da ve Slack'te var ve sorunlar bunları projelerin olduğu yerde talep ediyor.

3. Ne kadara mal oluyor ve token neyi gizliyor?

3.1 Tokenlar engel değil

Daha fazla katman, her mesajla daha fazla bağlam anlamına gelebilir ve yapay zekâ token başına ücretlendirilir. Bu açıklama yalnızca kısmen doğru. Kullanım bazlı Enterprise planlarında kullanım API tarifeleri üzerinden faturalandırılır, yani daha fazla bağlam daha az değil, daha fazla gelir demektir. Team'de ek kullanım etkinleştirilmediği sürece koltuk ücretleri sabittir ve ekstra tokenlar, üyelerin haftalık limitlerine daha erken ulaşması olarak kendini gösterir. Aynı tokenlarla faturalandırılan Claude Code ise halihazırda dört seviyeli bir basamaklı yapı sunuyor. Eğer engel token olsaydı, bu yapı var olmazdı. Bölüm 3.2'de ölçüldüğü üzere, Claude Code'un kendi sistem promptu ve araçları bizim herhangi bir talimatımızdan önce yaklaşık 30.200 token tuttu; bir projenin tam talimatları buna %3,5–5,2 ekledi.

3.2 Uygulamalı bir örnek

Her görseldeki etiketler: REAL = 29 Eylül ile 1 Ekim 2026 arasında ölçülen veya Anthropic belgeleriyle doğrulanan; EST = simüle edilen; IND = açıklayıcı.

Önce ölçümler. Aynı soruyu bir demo proje üzerinde Claude Code'da (claude -p, Claude Sonnet 5.5) her koşul için beş kez çalıştırdım ve Claude Code'un bizzat bildirdiği girdi tokenlarını aldım. Bunu 30 Eylül'de Claude Code 2.1.286'da ve 1 Ekim'de 2.1.287'de çalıştırdım; talimat sayıları aynıydı. Hiç proje talimatı olmayan bir çalıştırmayı çıkardığımızda, her düzenin ne kadara mal olduğu ortaya çıkıyor:

Aşağıdaki simülasyonun gösteremediği iki şey var. Basamaklı yapı, aynı kurallar için derlenmiş dosyadan 224 token daha fazla maliyetlidir: Her ek dosya bir ek yük taşır; burada bu yük, uygulamanın her seviyedeki dosyaya koyduğu işaretçi ve başlık ile Claude Code'un yüklediği her dosyanın etrafına eklediği çerçevedir. Daha fazla seviye, daha fazla ek yük demektir. Ayrıca Claude Code, genel token hesaplayıcısının × 1,30 ile tahmin ettiğinden bile %21–26 daha fazlasını yükledi; bu farkın bir kısmı aynı dosya başına düşen ek yüktür. Oranlar bundan etkilenmez, mutlak dolar rakamları etkilenir; bu yüzden simülasyonun dolar değerlerini düşük kabul edin.

Sonra firma ölçeğinde simülasyon. Açıklayıcı bir firma için bir aylık talimat tokenlarını simüle ettim: Üç iş kolunda 40 kişi, 250 aktif proje, iş kolu başına altı rapor türü, kişi başı iş günü başına beşli oturumlar halinde 35 mesaj, toplamda 29.400 mesaj. Token boyutları, örnek talimat metinleri üzerinde Anthropic'in genel eski token hesaplayıcısıyla (Anthropic'in kendisinin Claude 3 ve sonrası için "çok kaba bir yaklaşım" dediği araç) sayıldı ve Claude 4.7+ hesaplayıcısı için 1,30 ile ölçeklendirildi. Organizasyon bloğu 597 karakterlik bir örnekten 3.000 karakterlik sınıra ekstrapole edildi ve iş kolu kılavuzu 953 karakterlik bir örneğin üç katı olarak alındı. Fiyatlar Claude Sonnet 5.5 liste fiyatlarıdır (girdi 2 $, 5 dakikalık önbellek yazma 2,50 $, önbellek okuma milyon token başına 0,20 $). Prompt önbelleği beş dakika sürer ve her isabetle yenilenir.

• Düz (bugünün geçici çözümü): Organizasyon bloğu, ardından her projenin iş kolu kılavuzunun kendi kopyası, altı rapor şablonunun tamamı ve projeye özgü detaylar.

• Ağaç: Kurum, iş kolu, yalnızca kullanılan rapor şablonu, ardından projeye özgü detaylar; en çok paylaşılanlar önce gelecek şekilde derlenmiş.

Tablonun arkasındaki boyutlar: organizasyon bloğu 830 token (3.000 karakter), iş kolu kılavuzu 729, bir rapor şablonu 147, projeye özgü detaylar 98 (yuvarlanmış; toplamlar yuvarlamadan önce hesaplandı). Simülasyon, organizasyon bloğunun hemen öncesinde yer alan Claude'un kendi sistem promptunu göz ardı eder.

İki dürüst uyarı. Birincisi, ağaç tek başına token tasarrufu sağlamaz. −%29'luk oran tiplendirilmiş görevlerden gelir: Altı şablonun tamamı değil, yalnızca yazılan raporun şablonu yüklenir. −%62'lik oran çoğunlukla en çok paylaşılan katmanların önce derlenmesinden gelir, böylece yüzlerce proje bayt bazında birebir aynı bir öneki paylaşır: Altı şablonun tamamı yüklüyken bile yalnızca sıralama, paylaşılan önbellek maliyetini 36 $'dan 18 $'a (−%51) düşürür ve tiplendirilmiş görevler geri kalanını sağlar. Bu ikinci tasarruf ancak önbellek kullanıcılar arasında paylaşılabiliyorsa mümkündür. Claude API'de önbellekler kurumlar arasında ve bir kurum içinde çalışma alanı başına yalıtılmıştır, dolayısıyla birebir aynı önekler bir çalışma alanı içindeki istekler arasında yeniden kullanılır; claude.ai için bu belgelenmemiştir. Dağıtılan haliyle Claude Code'da bu gerçekleşmez: Orada "önbellek fiilen tek bir makine ve dizinle sınırlıdır", bu yüzden iki farklı proje klasöründeki iki kişi birbirinin önbelleğini kaçırır. Son sütunu bugün mevcut olan bir şey olarak değil, sohbette yerel bir katmanın ne kazandırabileceği olarak okuyun. Haklı bir itiraz: Beceriler zaten talep üzerine yüklenir, dolayısıyla şablonlarını Becerilere taşıyan düz bir çalışma alanı −%29'un bir kısmını bugün elde eder. Becerilerin sohbette ve Cowork'te eksik olan yanı kapsam ve mirastır: Bir beceri tek bir iş koluna ait olup o iş kolunun projelerine akamaz. (Claude Code'da bir alt klasördeki beceri, o klasörde veya altında başlatılan oturumlar için yüklenir.) İkincisi, bunlar yalnızca talimat tokenlarıdır ve bu ölçekte önbelleğe bağlı olarak aylık 14 ila 149 $ arasında değişir. Gerçek faturalara konuşma geçmişi ve çıktılar hakimdir. Ağaç lehine güçlü argüman doğruluk ve Team planında kapasitedir. Fatura değil.

Yukarıdaki ölçüm, varsayılan boyutlar yerine gerçek bir ağaçta, Claude Code'da tiplendirilmiş görev etkisini yeniden üretir: Simülasyonun −%29'una karşı basamaklı yapıda −%20 ve derlenmiş halde −%34. Tek bir görev tipine sahip bir iş kolu, tiplendirilmiş görevlerden hiçbir tasarruf sağlamaz.

3.3 Gerçek Claude'dan aynı yanıt

Claude Code'a aynı soruyu kırk kez sordum: Dört koşulun her birinde on bağımsız yanıt, bir gün arayla beşerli iki parti halinde. Soru, zemin iyileştirmesinde yapılan bir saha yoğunluk testinin geçip geçmediğiydi; 112,3 pcf değerine karşılık maksimum kuru yoğunluk 115,8 pcf ve %98 gerekliydi. Talimatlar ya firmanın altı kuralı ya da tek satırlık bir "yardımsever asistan" promptuydu ve dil İngilizce veya İspanyolcaydı. Kırk yanıtın tamamı aynı karara vardı: %97,0, başarısız.

Claude Code iki çıktı sayısı bildirir: faturalandırılan tokenlar ve bunların okuyucunun asla görmediği düşünme kısmına ait olanları.

Dört bulgu:

• Firmanın kuralları yanıtları ekranda 1,4 kat, faturada ise 1,8–1,9 kat uzattı. Görünen ek kısım, kuralların talep ettiği bayraklar, standartlar ve sınırlamalar bölümleriydi. Bir kalite sisteminde değerli olan kısım bunlardır.

• Firmanın kuralları altında, faturalandırılan çıktının üçte birinden fazlası görünmezdi. Faturalandırılan çıktı tokenlarının %37'si düşünmeydi; sade promptta bu oran %16'ydı. İngilizcede okuyucu 447 token görür ve 711 token için ödeme yapar.

• İspanyolca, kelime sayısında %4'lük fark içindeki yanıtlar için İngilizcenin 1,2 katı görünür token maliyeti yarattı. Aynı şekilde ölçüldüğünde, firmanın kuralları İspanyolca yazıldığında 1,53 kat girdi tokenı aldı.

• Aynı karar 317 ile 953 token arasında faturalandırıldı; en uzun yanıt en kısadan üç kat fazlaydı. Token başına faturalandırma titizliği dolgudan ayırt edemez. Kabul kriterleri edebilir.

Bu oranlar beşli partiler arasında değişir. Firmanın kuralları için ekrandaki oran ilk partide 1,43–1,52, ikinci partide 1,27–1,31'di; faturalandırılan oran 1,78–1,82 ve ardından 1,70–2,05 oldu; İspanyolca oranı 1,29–1,38 ve ardından 1,14–1,18'di. Yön hiç değişmedi. Boyut bir anlamlı basamağa kadar güvenilirdir.

Yöntem: 2026-09-30'da Claude Code 2.1.286 ve 2026-10-01'de 2.1.287, claude -p --output-format json, Claude Sonnet 5.5. Tüm araçlar devre dışı bırakıldı ve kişisel ~/.claude dosyaları hariç tutuldu, böylece koşullar arasında yalnızca belirtilen talimatlar farklıydı. Token sayıları, thinking_tokens dahil olmak üzere Claude Code'un kendi kullanım raporudur; aylık maliyet, Sonnet 5.5'in milyon çıktı tokenı başına 10 $'lık fiyatını faturalandırılan ortalamaya uygular. Ölçüm betiği, her iki parti, havuzlanmış rakamlar ve tüm yanıtlar yazar tarafından saklanmakta olup talep üzerine sağlanabilir. Bu makalenin ilk sürümü bu sayıları alt ajanlar ve genel token hesaplayıcısıyla tahmin etmişti; bu tahminler artık geçerliliğini yitirmiştir.

3.4 Kurallar çeliştiğinde kararı ifadeler belirler

Anthropic'in belgeleri, çelişkili talimatların "rastgele" çözülebileceğini kabul eder. Eksik bir iş kolu katmanının yaratacağı türden bir çelişkiyi test ettim. Kurum kuralı ABD geleneksel birimlerinin kullanılmasını söylerken, bir proje kuralı yoğunlukların SI birimleriyle raporlanmasını söylüyordu. Bunları bir ağacın yapacağı gibi yerleştirdim: Kurum kuralını depolama kökündeki bir CLAUDE.md'ye, proje kuralını proje klasöründeki bir CLAUDE.md'ye koydum; ikisi de Claude Code'un kendi basamaklı yapısı tarafından yüklendi. Ardından aynı kurulumu, kurum kuralı yalnızca sözcüklerle zorunlu olarak işaretlenmiş şekilde çalıştırdım: Etiketinde ENFORCED (ZORUNLU) ibaresi ve eklenen bir cümle vardı: "Bu kural zorunludur: hiçbir iş kolu veya proje kuralı bunu geçersiz kılamaz." Her kurulum 30 Eylül'de on kez ve 1 Ekim'de on kez daha çalıştırıldı.

Rastgele değildi. Hiçbir şey belirtilmediğinde, Claude her seferinde daha yakın ve daha spesifik olan kuralı seçti. Yirmi yanıtın on dördü nedenini açıkladı ("bu kural, firma geneli ABD geleneksel birim kuralından daha spesifiktir" veya kurum kuralını geçersiz kıldığı); beşi yalnızca proje kuralına atıfta bulundu ve firmanın kuralıyla çeliştiğinden hiç bahsetmedi. Bağlayıcılık sözcüklerle belirtildiğinde ise kurum kuralı her seferinde kazandı ve her yanıt zorunlu firma kuralının öncelikli olduğunu söyledi. İkinci parti birimleri her seferinde 10'da 10 oranında yeniden üretti ve iki satır arasındaki fark şansın çok ötesindeydi (Fisher kesin testi, p < 0,0001). Açıklamalar o kadar tutarlı değildi: İlk partide on yanıttan dokuzu proje kuralının neden kazandığını açıklarken, ikinci partide bu oran onda beşti.

Bu durum model için iyi, çalışma alanı içinse kötü bir haber. Önceliklendirme mevcut, ancak kuralların lafzında yaşıyor; yani herhangi bir katmanı düzenleyen herkes bunu değiştirebiliyor ve kimse bunu bir öncelik kararı olarak incelemiyor. Ayrıca alt kural kazandığında, yanıtların dörtte biri okuyucuya daha üst düzey bir kuralın devre dışı bırakıldığını söylemedi. Bu makalenin ilk sürümünde yapılan bir pilot çalışmada (kurallar basamaklı yapı yerine tek bir prompt içinde verildiğinde), yalnızca sıraları değiştirildiğinde bile sonuçlar değişti (organizasyon kuralı önce: 5 üzerinden 5 SI; organizasyon kuralı sonda: 5 üzerinden 2 SI ve 5 üzerinden 3'ü her iki birimi de verdi veya hangisinin geçerli olduğunu sordu).

Hiçbir modelden, organizasyonun kural yazılırken yakalayabileceği bir çelişkiyi çözmesi istenmemelidir. Claude Code'un bu konuda iki kısmi yanıtı var. /doctor prompt-audit komutu, bir kişi çalıştırdığında Claude'dan birbirleriyle çelişen talimat dosyalarını aramasını ister. Ayrıca 1 Ekim'den bu yana bir mod, kod içinde bir sıra dayatabiliyor: organizasyonun modları kişinin modlarından önce çalışıyor ve yerleşik koruma yüklendiğinde, deny (reddet) kuralları kişinin modunu geçersiz kılıyor. Ancak hiçbiri talimat metnini kapsamıyor. Talimat dosyaları hâlâ ardışık olarak birleştiriliyor ve dokümantasyon sonucu üç farklı şekilde tanımlıyor: Claude "keyfi olarak birini seçebilir"; bir kullanıcı kuralı ile bir proje kuralı çeliştiğinde "Claude ikisinden birini takip edebilir"; ve "talimatlar çeliştiğinde, Claude bunları uzlaştırmak için kendi muhakemesini kullanır." Yirmi üzerinden yirmilik sonuç, bu muhakemenin burada nasıl göründüğünü ortaya koyuyor. Claude Tag, üç kapsamı için bir sıra belirliyor ve sonucu "zorunlu bir güvenlik bariyeri değil, yönlendirme" olarak adlandırıyor. Referans uygulamanın kontrol mekanizması ise tam da bu değişikliği reddediyor: "R-22 units.density=SI olarak ayarlıyor; R-01 (org:firm) US'yi zorunlu kılıyor", ve bu kontrol hiçbir şey Claude'a ulaşmadan önce gerçekleşiyor; üstelik "enforced" (zorunlu kılınmış) ifadesi kuralın içindeki bir cümle değil, kural üzerindeki bir alandır.

Talimat yoğunluğu durumu daha da kötüleştiriyor. IFScale kıyaslamasında (2025), Claude Sonnet 4'ün doğruluk oranı 10 eşzamanlı talimatta %100'den, 500 talimatta %42,9'a düştü.

3.5 Hesaplama gücü veya enerji daha adil bir birim olur muydu?

Token, tek bir model içinde hesaplama gücü için makul bir göstergedir: daha fazla token, donanım için gerçekten daha fazla iş anlamına gelir. Hesaplama gücüne veya enerjiye dayalı bir fiyatlandırmanın dil cezasını düzeltmeyecek olmasının nedeni de budur. İspanyolca daha pahalıya mal oluyor çünkü tokenizer onu daha az sıkıştırabiliyor ve bu ekstra tokenler gerçek bir hesaplama yükü yaratıyor. Bunun çözümü daha iyi bir tokenizer veya içeriğe göre normalleştirilmiş bir ölçüm sistemidir.

Normalleştirilmiş bir hesaplama birimi yine de üç açıdan faydalı olacaktır. Farklı modelleri ve sağlayıcıları karşılaştırılabilir kılar. Fizikseldir ve örneğin sürdürülebilirlik raporlaması için raporlanabilir. Ve eğer katsayı referans donanıma göre sabitlenirse, sağlayıcı kendi verimlilik kazanımlarını elinde tutar ki bu da doğru teşvik mekanizmasıdır. Bunun bir emsali de var: bulut sağlayıcıları bir zamanlar EC2 Compute Unit gibi normalleştirilmiş birimler satıyordu.

Ancak ciddi sorunları da bulunuyor. Müşteri, bir standart ve bir denetçi olmadan bunu doğrulayamaz. Gerçek enerji tüketimi donanıma, veri merkezi verimliliğine, toplu işlemeye (batching) ve elektrik şebekesine bağlıdır. Ayrıca Anthropic, istek başına enerji tüketimini yayınlamıyor; yalnızca üçüncü taraf tahminlerini bulabildim. En önemlisi, hesaplama gücü hâlâ bir girdidir. Yanıtın doğru olup olmadığını söylemez.

Sonuç olarak üç ayrı katman öneriyorum:

1. Token veya normalleştirilmiş bir hesaplama birimi üzerinden faturalandır.

1. Görev ve düğüm başına enerji tüketimini açıkla.

1. Doğrulanmış sonuç başına maliyet üzerinden yönet.

Team planı için atılması gereken asgari adım, haftalık limiti belirli bir birimde yayınlamaktır. Oturum başına izin, "Pro planının oturum başına kullanım izninin 1,25 katı" olarak belirtilmiştir; ancak haftalık limit için yayınlanmış hiçbir rakam yoktur. Hiçbiri bütçelendirilemez.

FinOps Foundation'ın dediği gibi, "token faturalama birimidir, değer birimi değil." Değeri tanımlanabilir kılan şey bir hiyerarşidir, çünkü kabul kriterlerinin yaşayabileceği yer orasıdır.

3.6 Neden henüz inşa edilmediğine dair daha olası sebepler

1. Örtük öncelik. Anthropic'in kendi dokümantasyonu, doğrudan çelişen talimatların farklı davranışlara yol açabileceğini kabul ediyor ve 3.4 bölümü, önceliğin kuralların lafzına göre belirlendiğini gösteriyor. Katmanları üst üste yığmak çelişkileri çoğaltır ve talimatlara uyma oranı yoğunlukla birlikte düşer: IFScale kıyaslamasında (2025), test edilen en iyi modeller bile 500 eşzamanlı anahtar kelime talimatında yalnızca %68 doğruluğa ulaşabildi (3.4 bölümünde atıfta bulunulan kıyaslama).

1. İzin mirası. Bilgi bir ağaç yapısı boyunca aşağıya aktarılıyorsa, erişimin de aktarılması gerekir. Bu da her katmanın altında izin modelinin yeniden inşa edilmesi anlamına gelir.

1. Statik katmanlar yerine bellek ve geri çağırma (retrieval) tercih edilmesi.

1. Tüketici odaklı sadelik. Kod araçları dosya sisteminden ücretsiz bir ağaç yapısı devralır. Sohbet ürünlerinin ise bunu icat etmesi gerekir.

Anthropic, Claude sohbet ve Cowork'ta neden hiyerarşi bulunmadığını kamuoyuyla paylaşmadı. Bu bölümdeki her şey, piyasaya sürülen özelliklerden çıkarılmış sonuçlardır.

4. Referans model

Tasarım, bu sorunu halihazırda çözmüş sistemlerden ilham alıyor: bulut kaynak hiyerarşileri (AWS Organizations, Google Cloud Org Policy, Azure yönetim grupları), dizin politikası (Active Directory Group Policy) ve Claude Code'un kendi CLAUDE.md basamaklı yapısı. Düğümler arasındaki ilişkiler beş kelimeyle ifade ediliyor: içerir, miras alır, kullanır, mühürlü ve paylaşımlı.

4.1 Organizasyonun zaten sahip olduğu ağacı bağlayın

İnsanları organizasyonlarını yapay zeka çalışma alanının içinde yeniden kurmaya zorlamayın. Dosya sunucusu veya belge sistemi zaten tek güvenilir kaynaktır. Tek bir yol izleyin:

26GT301 iş numarası ağacı zaten kodluyor: yıl, iş kolu, sıra. Çalışma alanı bu yapıyı kopyalamamalı, bağlamalıdır (mount etmelidir).

4.2 Kural taşıyan düğümler, gruplama düğümleri, projeler ve görevler

• Kural taşıyan düğümler: organizasyon, iş kolu, proje, görev. Her biri aynı üç şeyi taşır: bağlam (talimatlar ve bilgi), politika (hangi araçlara, verilere ve bağlayıcılara izin verildiği) ve kimlikler (kendisine bağlanan bağlayıcı hesapları).

• Gruplama düğümleri: seri, yıl, bölge. Bunlar hiçbir kural taşımaz. Yalnızca gezinme, saklama süresi ve yaşam döngüsü için vardır. Bunları ayırmak, kural ağacını sığ tutar; Microsoft'un yönetim grupları için kendi rehberinde önerdiği gibi üç ila dört seviye ("üç ila dört seviyeden fazla olmamalı").

• Proje, anahtarlanmış bir kapsayıcıdır. Otomatik olarak oluşturulur: İş kolunun anahtar kalıbıyla eşleşen bir klasör göründüğünde (örneğin iş kolunun kökü altında {YY}GT{NNN}_{Name}), bir proje düğümü oluşturulur, iş kolundan miras alır ve yalnızca o klasörle sınırlandırılmış bağlayıcı erişimi elde eder. Sadece iş kolundan farklı olan şeyleri tutar: üyeler, müşteri, spesifikasyonlar. Açık durumdan kapalı duruma, oradan da arşivlenmiş duruma geçer (Şema 2).

• Görev tiplidir. Tipi, iş kolunun kataloğundan gelir (bir yoğunluk raporu, bir sondaj kaydı). Tip, bir şablon ve kabul kriterleri taşır. Çıktı, firmanın adlandırma kuralına uygun olarak proje klasörüne geri kaydedilir ve bir gözden geçiren tarafından kabul edilir. Beceriler (Skills), Claude'un bugün görev tiplerine sahip olduğu en yakın kavramdır. Enterprise planında bir grupla paylaşılabilirler, ancak bu dağıtımdır, miras alma değil: hiçbir şey bir dal boyunca aşağı akmaz.

Bu özyineleme kasıtlıdır. Stafford Beer'in Yaşanabilir Sistem Modeli bunu doğrudan ifade eder: "Özyinelemeli bir organizasyon yapısında, yaşanabilir her sistem bir başka yaşanabilir sistemi içerir ve onun içinde yer alır."

4.3 Birincil bir ebeveyn ve üzerine eklenen katmanlar

Christopher Alexander 1965'te "bir şehir ağaç değildir" demişti. Gerçek yapılar birbiriyle örtüşür. Bir müşteri, bir ajansın spesifikasyonu veya bir görev tipi birkaç iş koluna yayılabilir. Bu nedenle her düğümün bir birincil ebeveyni vardır ve kesişen kural setleri bindirme katmanları (kullanır) olarak eklenir. Çelişkiler her seferinde aynı şekilde çözülür: reddetme (deny) kazanır, aksi takdirde en yakın düğüm kazanır.

4.4 İki kanal, iki anlam

Bu tasarımın çekirdeğidir ve çoğu hiyerarşinin hata yaptığı yerdir.

• Bağlam birleştirilir. Talimatlar ve bilgi, CLAUDE.md'nin yaptığı gibi kökten aşağıya doğru birleştirilir.

• Politika varsayılan olarak reddeder. Bir araca veya bağlayıcıya, yalnızca kökten itibaren tüm yol boyunca bir izin (allow) varsa müsaade edilir ve yukarıdaki herhangi bir yerdeki açık bir reddetme (deny) kazanır; tıpkı AWS Service Control Policies'de olduğu gibi. Bir ebeveyn, bir kuralı zorunlu (enforced) olarak işaretleyebilir ve hiçbir alt düğüm bunu engelleyemez; Group Policy'de olduğu gibi.

İkisini karıştırmak klasik bir hatadır. Tavsiye niteliğindeki bağlam harmanlanmalıdır. Zorunlu kılmalar ise harmanlanmamalıdır.

4.5 Model okumadan önce derleyin

Bugün çelişen talimatlar, yanıt anında model tarafından çözülüyor. Çözüm, model hiçbir şeyi görmeden önce çalışan bir etkin-talimat derleyicisidir:

1. Bağlamı kökten yaprağa birleştirin.

1. Politikayı uygulayın: reddetme kazanır ve bir iznin tüm yol boyunca geçerli olması gerekir.

1. Ebeveynlerden gelen zorunlu kurallara uyun.

1. Her kuralı bir kimlik (ID) ve katmanıyla damgalayın.

1. Bloğu, her parçanın ne kadar geniş paylaşıldığına göre sıralayın ve katman başına bir token bütçesi uygulayın.

Çelişkiler bu adıma asla ulaşmaz: daha önce, bir kural yazılırken reddedilirler ve onay yazardan başka birinden gelir (Şema 3, alt kulvar).

Çelişkiler derleme zamanında çözüldüğü için çıktı, kesinlikle derinliğe göre değil, her parçanın ne kadar geniş paylaşıldığına göre sıralanabilir: organizasyon, iş kolu, görev tipi şablonu ve ardından projeye özgü detaylar. Bu sıra, önbellek isabetlerini maksimize eder (bölüm 3.2). Anthropic'in dört önbellek kesme noktasına, katman başına bir token bütçesiyle eşleşir; ancak pratikte konuşmanın kendisi için bir kesme noktası gerekebilir.

4.6 Kişilere değil, dallara bağlı kimlikler

Bir bağlayıcı kimliği (hesap, tenant, kapsam) bir kişiye değil, bir düğüme bağlanır. Claude Tag, Slack kanalları için zaten bu şekilde çalışır: bir yönetici bir hizmet hesabını bir kapsama bağlar ve en dar kapsamın kimlik bilgisi kazanır. Buradaki model, aynı şeyi bir seviye aşağıda, bir iş kolu ve projeleri üzerinde talep eder. İki organizasyonda çalışan bir kişinin iki mühürlenmiş ağacı vardır; hesapları değil, ağaçları değiştirir. İkisinin sahipleri de açıkça paylaşmadıkça aralarında hiçbir şey geçiş yapamaz. Teknik temel zaten mevcut: MCP yetkilendirme spesifikasyonu, kitleye bağlı OAuth tokenleri (RFC 8707 kaynak göstergeleri, RFC 9728 korunan kaynak meta verileri) kullanır ve sunucuların "başka hiçbir tokeni kabul etmemesi veya iletmemesi gerektiğini" şart koşar (spesifikasyon sürümü 2026-07-28).

4.7 İzinler ağacı takip eder

Temel aktörler: kişiler, gruplar, hizmet hesapları, harici misafirler (örneğin bir müşteri) ve ajanın kendisi.

Ajan, kişiyi veya düğümü asla aşamaz. Claude, çağıran kullanıcının izinleriyle ve düğümün politikasının kesişimiyle hareket eder. Kuralları veya izinleri değiştiremez; yalnızca değişiklik önerebilir. (Bugün Claude, Cowork klasör talimatlarını kendi başına güncelleyebilir. Bu modelde ise bu, birinin onayladığı bir teklif haline gelir.)

Değerlendirme. Yetkilendirmeler yalnızca aşağı akar, asla yukarı veya yana değil. Bir düğümdeki etkin izin, yolundaki rollerin verdiği, tüm yol boyunca politikanın izin verdiği sınırlar içinde kalan ve yukarıdaki herhangi bir reddetme çıkarıldıktan sonra kalan izindir. Bir bindirme katmanı yalnızca kendi içeriğine erişim sağlar: bir spesifikasyonu okumak, onu kullanan projeleri açmaz.

Yaşam döngüsü.

• Açık: roller verildiği gibi uygulanır.

• Kapalı: yeni görev yok, ancak bekleyen incelemeler tamamlanabilir.

• Arşivlenmiş: herkes için salt okunur; yalnızca sahibi geri yükleyebilir ve geri yükleme günlüğe kaydedilir.

• Mühürlenmiş ağaç: açık bir paylaşım olmadan hiçbir şey geçiş yapamaz.

İstisnalar ve yetki devri. İstisnalar süre sınırlı ve gerekçelidir; talepte bulunan dışında biri tarafından onaylanır. Kendiliğinden sona ererler ve sayılırlar, çünkü her geçersiz kılma kalıcı bir bakım adasıdır; SharePoint'in bozuk miras limitleri bunun ibret verici örneğidir. Yetki devri, asla yetkiyi devredenin sahip olduğundan fazlasını veremez. Sahip acil durum erişimi (break-glass) mevcuttur, her zaman günlüğe kaydedilir ve sonrasında incelenir.

Team planında, bu sistem gruplar olmadan da çalışır: yetkilendirme düğümde yaşadığı için, dört rollü bir organizasyon yine de dal bazlı izinlere sahip olur.

4.8 Katmanlar nasıl etkileşime girer

Bir ağaç, ancak değişiklikler içinde dolaşabiliyorsa inşa etmeye değerdir. İşin büyük kısmını üç etkileşim taşır (Şema 5):

• Aşağı itme. Bir iş kolu lideri bir kuralın yeni sürümünü yayınlar. İş kolundaki her proje, bir sonraki derlemesinde bunu okur. Onaylanmış bir istisna, süresi dolana kadar eski sürümü korur ve zaten dosyalanmış çıktılar üretildikleri sürümü muhafaza eder.

• Yukarı çekme. Bir üye bir proje içindeki bir şablonu iyileştirir ve önerir. Öneren kişi değil, iş kolu lideri bunu onaylar ve kardeş projeler bunu miras alır. Bugün bu iyileştirme, gerçekleştiği projede kalır.

• Yatay geçiş. Bir ajans spesifikasyonu tek seferde değişir. Üç iş kolundaki projeler bununla yeniden derlenir ve iş kollarının kendileri değişmez. Bir iş kolu kuralıyla yaşanan çelişki, güncelleme yazılırken reddedilir.

Tek bir istek tüm katmanları aynı anda gösterir (Şema 6): ağaç üyenin yetkisini ve projenin durumunu kontrol eder, derleyici bloğu oluşturur, Claude o proje klasörüne özel bir kimlik üzerinden saha verilerini okur, tipli bir çıktıyı klasöre geri kaydeder ve onu yazmayan bir gözden geçiren kabul eder. Her adım günlüğe kaydedilir ve maliyet proje anahtarına yansıtılır.

4.9 Veri yapısı

Sağlama (provisioning) olay odaklıdır: bir iş kolunun storage_root'u altında key_pattern ile eşleşen yeni bir klasör, proje düğümünü oluşturur. answer_log, her yanıt için köken bilgisi ve düğüm başına maliyet sunar.

4.10 Tokenleri değil, sonuçları ölçün

Her görev tipi kabul kriterleri taşır: bitmiş olma tanımı. Bunlar yerinde olduğunda, yapay zeka işinin daha iyi bir birimi ölçülebilir hale gelir:

doğrulanmış sonuç başına maliyet = (token maliyeti + inceleme süresi) ÷ kabul edilen teslimatlar

Her yanıt bir düğüme kaydedildiği için, yapay zeka maliyeti de tıpkı işçilik ve malzeme gibi bir proje anahtarına yansıtılabilir. Bunun bazı parçaları mevcut: Claude Tag kanal başına harcamayı raporlar ve sınırlar; Claude Code'un telemetri verileri de manuel olarak departman, maliyet merkezi veya depo bazında etiketlenebilir. Ancak hiçbiri bir projeye anahtarlanmamıştır ve hiçbiri kabul edilen teslimatlara bölünmez. İş numarasına göre fatura kesen bir firma için yapay zeka, genel gider yerine doğrudan bir iş maliyeti haline gelir. Mühendislikte kurşun kaleme değil, kontrol edilip mühürlenmiş teslimata para ödersiniz. Yapay zeka işi de aynı şekilde ölçülmelidir.

4.11 İtirazlara yanıtlar

"Beceriler ve eklentiler bunu zaten yapıyor." Bir beceri, Claude onu alakalı bulduğunda yüklenir; bu bir garanti değil, alakadır. Sağlama, bir beceriyi herkese verir; Enterprise'da bunu taşıyan bir eklenti bir grup için zorunlu kılınabilir. Bu, bugün sohbet ve Cowork'ta bir iş koluna en yakın şeydir ve üç açıdan yetersiz kalır: yalnızca Enterprise içindir, projeleri değil insanları hedefler ve bir iş kolundan projelerine hiçbir şey akmaz. Bir iş kolunda her zaman geçerli olması gereken bir kural, alaka tespitine bağlı olamaz.

"Modlar bunu zaten yapıyor." Claude Code'da kısmen, 1 Ekim 2026'dan beri yapıyor. Bir mod sistem promptunu yeniden yazabilir, bir araç çağrısını reddedebilir ve bir panel çizebilir; ayrıca bir organizasyonun modları kişinin modlarından önce çalışır. Dolayısıyla bu makaledeki derleyici, yazma zamanı kontrolü ve etkin talimatlar görünümü bugün bir mod olarak inşa edilebilir ve 6. bölüm bunu söylüyor. Üç sınır kalıyor. Modlar Claude sohbetinde çalışmaz ve Cowork'ta organizasyonun konsol ayarları geçerli değildir. Sıralarının iki sahibi vardır, organizasyon ve kişi; aralarında bir iş kolu yoktur. Enterprise'da bir grup için zorunlu kılınan bir eklenti, o gruba bir mod taşıyabilir, ancak bu mod kişinin kendi modlarından biri olarak çalışır, bir önceliği yoktur. Ve bir mod, yalıtılmamış (unsandboxed) koddur: kişilerin modlarından önce çalışmak için bir organizasyonun modunun her makinede bir dizinde bulunması gerekir ve yönetici konsolundan sunulan ayarlar "dizini bir makineye yerleştiremez". Cihaz yönetimi olmayan bir firma herkese bir mod gönderebilir, ancak bu mod kişilerin kendi modlarının arasında çalışır, onların önünde değil. Bir firmanın, bir departmanın farklı birimlerle raporlama yaptığını söylemek için TypeScript yazması gerekmemelidir.

"Bellek kuralları öğrenecek." Bellek çoğunlukla Claude tarafından, tek bir kişi veya tek bir proje için yazılır ve bir sahip, bir üyenin anılarını okuyamaz veya düzenleyemez. Bir denetçinin, bir kişi tarafından yazılmış, sürümlenmiş, onaylanmış ve her yanıta izlenebilir kurallara ihtiyacı vardır. Anthropic bunu zaten üç kez inşa etti: izinler için "Etkin rolü görüntüle" ve onun "Tarafından verildi" etiketiyle; beceriler ve eklentiler için sürüm geçmişi ve "kendi onayınızı veremezsiniz" adımıyla; ve Claude Tag'in erişimi için "Şuradan miras alındı" etiketleriyle. Bir projedeki talimatlar bunların hiçbirine sahip değildir.

"Claude Tag bunu zaten yapıyor." Slack kanalları için büyük ölçüde evet ve 1. bölüm bunu söylüyor. Hâlâ eksik olan üç şey var. Bir kanal proje değildir: klasörü, anahtarı, yaşam döngüsü yoktur ve "bir kanal bir Projeye yönlendirilemez". Ağaç üç sabit seviyedir, bu nedenle iş kolları ve yüzlerce işi olan bir firma, seviyelerinden ikisini kanal adlarında düzleştirmek zorundadır. Ve dokümantasyon, bir talimat yazılırken çelişki kontrolü yapıldığından bahsetmez; kapsamlar birleştirilir ve uzlaştırma işi modele bırakılır. Eğer bir şey varsa, Claude Tag bu makalenin tasarımı için en güçlü kanıttır: aynı şirket ekipler için bir sistem kurarken miras almayı, kapsama bağlı kimlik bilgilerini ve bir köken etiketini seçti.

"Hiyerarşiler karmaşıklık ekler." Yalnızca derinlikleri sınırsızsa. Microsoft'un yönetim grupları için kendi rehberi "üç ila dört seviyeden fazla olmamalı" şeklindedir. Bu model dört kural taşıyan seviyeyi sabitler ve seri ile yıl gibi gruplama klasörleri hiçbir kural taşımaz.

"Miras almak bir güvenlik riskidir." Erişim dikkatsizce miras alınırsa öyledir. Bulutun cevabı geçerlidir: her seviyede bir izin bulunmalı, herhangi bir yerdeki reddetme kazanmalı, Claude kullanıcı ve düğümün kesişimi olarak hareket etmeli ve Claude'un kendi kural düzenlemeleri teklife dönüşmelidir.

"Daha fazla katman daha fazla token maliyeti demektir." Bölüm 3.2, Claude Code'da tam tersini ölçtü: düz kopyalara kıyasla basamaklı yapıda %20, derlenmiş yapıda %34 daha az talimat tokeni. Her ekstra dosya biraz ek yük getirir, bu yüzden derlemek basamaklı yapıdan daha iyidir. Tipli görevler kullanılmayan şablonları düşürür ve derlenmiş önekler projeler arasında bayt bazında aynıdır, böylece prompt önbelleğe alma bunları yeniden kullanabilir. Claude API'sinde önbellekler çalışma alanı başına yalıtılmıştır, bu nedenle organizasyon başına bir çalışma alanı ağacın köküne eşlenir. Claude Code bugün buna sahip değil: önbelleği tek bir makine ve dizinle sınırlıdır.

"Ekipler kendi projelerini idare edebilir." Bu bugünün geçici çözümüdür ve 5. bölümdeki prototip bunun ne ürettiğini ölçtü: küçük bir demoda yapıştırılan altı kopyadan ikisi güncelliğini yitirmişti.

5. Bugün çalışıyor: bir referans uygulama

Modelin sadece tartışılabilir değil, inşa edilebilir olduğunu göstermek için Worktree'yi geliştirdim; Claude Desktop'a benzer şekilde tasarlanmış, küçük bir masaüstü uygulaması (Node ve Electron, Windows ve Linux'ta geçen 24 test). Yukarıdaki video, uygulamanın gerçek bir çalıştırılmasıdır ve yalnızca Claude'un çalıştığı kısımlardan kısaltılmıştır. Bu, bir mod değil, Claude Code'u dışarıdan yöneten ayrı bir uygulamadır. Kendi başına bir model çağırmaz. Her sohbet, bilgisayarda zaten kurulu olan Claude Code'u (claude -p), Claude Code'un sahip olduğu oturum açma yöntemiyle (bir Claude aboneliği veya bir API anahtarı) çalıştırır. Bunu üç iş kolu ve altı projesi olan kurgusal bir firma üzerinde çalıştırdım. Biri mesaj gönderdiğinde:

• İzin ver. İşlem yapan kişinin proje üzerinde veya üzerinde bir yetkiye sahip olması ve projenin açık olması gerekir. İş kolunda yetkisi olmayan bir yönetici, Claude başlamadan engellendi.

• Kontrol et. Yazma zamanı kontrolü önce çalışır. 3.4 bölümündeki SI kuralı, zorunlu kılınmış bir firma kuralıyla çeliştiği için reddedilir ve asla bir CLAUDE.md'ye ulaşmaz.

• Bağla. Ağaç, gerçek proje klasörlerine her seviye için bir CLAUDE.md olacak şekilde yazılır (depolama kökünde organizasyon, ardından iş kolu, ardından proje) ve Claude Code'un kendi basamaklı yapısı bunları yükler. Derlenmiş mod bunun yerine proje başına tek bir dosya yazar. Uygulamanın işaretleyicisi olmayan dosyaların üzerine asla yazılmaz.

• Çalıştır. Görev şablonu --append-system-prompt-file içine girer. Claude'un neler yapabileceği CLAUDE.md tarafından değil, Claude Code tarafından zorunlu kılınır: --allowedTools, kişinin rolünün her seviyenin politikasıyla kesişimidir, yazmalar proje klasörüyle sınırlıdır ve --permission-mode dontAsk diğer her şeyi reddeder. Gerçek çalıştırmalarda, iş kolunun politikası web'e izin vermediği için bir web araması reddedildi ve proje klasörü dışındaki bir yazma işlemi engellenip günlüğe kaydedildi.

• Günlüğe kaydet ve incele. Her yanıt; kişi, düğüm, her kural etiketi, Claude'un atıfta bulunduğu kurallar ve Claude Code'un bildirdiği girdi, önbellek ve çıktı tokenleri ile birlikte günlüğe kaydedilir. Yanıtı yazmayan bir gözden geçiren onu kabul eder veya iade eder. Demodaki gerçek bir yoğunluk raporu çalıştırması yaklaşık 30 saniye sürdü; üç çalıştırma boyunca Claude Code, liste fiyatları üzerinden yanıt başına 0,08–0,22 ABD doları bildirdi. Claude uyguladığı kurallara atıfta bulundu, kabul sınırına yakın sonuçları işaretledi ve mühendisin alanlarını boş bıraktı.

• Sapma (Drift). Bağlanan her CLAUDE.md ağaçla karşılaştırılır ve elle yapılan düzenlemeler işaretlenir. Daha önceki bir komut satırı prototipi, aynı karşılaştırmayı düz projelere yapıştırılan kopyalar üzerinde çalıştırdı ve altı kopyadan ikisinin güncel olmadığını buldu: biri hâlâ R-07 v3'teydi, diğeri ise bir kuralın elle silindiği bir kopyaydı.

Bunu inşa etmekten çıkan ve Claude Code üzerine talimatlar katmanlayan herkes için geçerli olan üç bulgu:

1. Kişisel talimatlarınız organizasyonun çalıştırmalarına sızar. Varsayılan olarak, her çalıştırma benim kişisel ~/.claude/CLAUDE.md dosyamı, kurallarımı, ajanlarımı ve MCP sunucularımı da yükledi. Uygulama artık bunları claudeMdExcludes ayarı ve --strict-mcp-config ile hariç tutuyor. Benim makinemde bu, bir çalıştırmanın bağlamını 29,6 bin tokenden 21,4 bin tokene düşürdü. Bariz alternatif olan --setting-sources project,local, Windows'taki Claude Code 2.1.284'te tam tersini yaptı: kişisel dosyayı tuttu ve organizasyon ile iş kolunu taşıyan üst klasör CLAUDE.md dosyalarını kaldırdı.

1. Bir kişinin modları da sızar. Modlar, uygulama inşa edildikten bir gün sonra geldi, bu yüzden test ettim. Kendi kullanıcı kapsamıma her prompta bir satır ekleyen tek kancalı bir mod kurdum. Uygulamanın çalıştırmalarına ulaştı: organizasyonun üç kuralı yüklendi, benim kişisel satırım da yüklendi ve yanıt ona uydu. Çalıştırma ayarlarına disableAllHooks eklemek bunu dışarıda tuttu ve üç seviyeli CLAUDE.md'yi sağlam bıraktı; uygulama artık bunu yapıyor. --safe-mode bir alternatif değildir: hem modu hem de onunla birlikte tüm CLAUDE.md basamaklı yapısını kaldırdı. Dokümantasyona göre, bir kişinin kendi ayarlarındaki disableAllHooks, organizasyonun yönettiği şeylerin çalışmaya devam etmesini sağlar.

1. CLAUDE.md bağlamdır, zorunlu kılma ise konfigürasyondur. Anthropic'in dokümantasyonu bunu söylüyor: "Ayar kuralları, Claude'un ne yapmaya karar verdiğinden bağımsız olarak istemci tarafından zorunlu kılınır. CLAUDE.md talimatları Claude'un davranışını şekillendirir ancak katı bir zorunlu kılma katmanı değildir." Uygulama buna dayanıyor. Bir kuralın garanti etmesi gereken her şey araç izinlerine eşlenir; CLAUDE.md'deki her şey ise etiketli bir yönlendirmedir.

Bugünün Claude Code'unda çalışıyor ve derlenmiş metin herhangi bir planda bir sohbete veya Cowork projesinin talimatlarına yapıştırılabilir. Bir bağımlılık tarihli: uygulama claude -p'nin CLAUDE.md dosyalarını yüklemesine güveniyor ve Anthropic'in dokümantasyonu, bunları atlayan --bare seçeneğinin "gelecek bir sürümde -p için varsayılan olacağını" söylüyor. Bu gerçekleştiğinde, uygulama ağacı başka bir yolla geçirmek zorunda kalacak; derlenmiş mod ve --append-system-prompt-file bunu zaten yapabiliyor. Bu, yerel sürüm için çalışan bir spesifikasyondur, bir güvenlik sınırı değil: "olarak hareket etme" bir demo anahtarıdır, bir oturum açma işlemi değil.

6. Halihazırda sunulanlardan bir yol

Artık Claude Code'da. 1 Ekim itibarıyla ağaç bir mod olarak dağıtılabiliyor: Düğümün kurallarını system prompt'un bir bölümüne derleyin, düğüm politikasının reddettiği araç çağrılarını engelleyin ve geçerli talimatları bir panelde görüntüleyin. Bir organizasyon, bu modu herhangi bir kullanıcının yüklediği her şeyden önce çalıştırabilir. Bunu ben geliştirmedim; referans uygulamanın yol haritasındaki ilk madde bu. Claude Code'u ve aynı motor üzerinde çalışan, kullanıcının makinesindeki Cowork oturumlarını kapsayacaktır. Ancak sohbeti kapsamaz.

Sohbet ve Cowork için 30 günlük versiyon. Anthropic gerekli parçalara sahip. Tıpkı Slack'te bir kanalın Claude Tag'de çalışma alanından miras alması gibi, bir projenin talimatlarını miras aldığı bir üst proje tanımlamasına izin verin. İkisini sırayla derleyin, her kurala bir etiket ekleyin ve mevcut "Geçerli rolü görüntüle" (View effective role) panelinin yanına bir "Geçerli talimatları görüntüle" (View effective instructions) paneli koyun. Sadece bu bile, her iş koluna kurallarını saklayacağı tek bir yer sunar.

Bundan sonra her adım kendi başına faydalıdır; işe Team planlarına yardımcı olanlarla başlayalım:

1. İş kolu düğümleri ve anahtar kalıp provizyonu, kodda zaten çalışan CLAUDE.md semantiğini yeniden kullanır. Claude Code'un kendisinde eşleştirme adımı, organizasyonun modları ile kişinin modları arasında bir grup için bir katman ve grup bazlı yönetilen ayarlardır.

1. Görev türleri, kabul kriterleriyle birlikte bir iş koluna kapsamlandırılmış beceriler olarak.

1. Yazma zamanlı çakışma kontrolü, böylece çelişkiler model tarafından değil, ağaç tarafından reddedilir.

1. Düğümlerde yetkilendirmeler (grant), gruplar olmadan Team'de çalışır ve Enterprise'ın özel rollerini genişletir.

1. Projeler için dala bağlı bağlayıcı kimlikleri, tıpkı Claude Tag'in bir hizmet hesabını bir Slack kanalına bağlaması gibi.

1. Tıpkı Claude Tag'in kanal bazlı raporlama yapması gibi, projeye anahtarlanmış düğüm bazlı hesap takibi; belirtilen bir birimde yayınlanmış haftalık bir limit; ve görev başına enerji açıklaması.

7. Sınırlamalar

• Kapsam. 1 Ekim 2026'da code.claude.com/docs ve claude.com/docs adreslerindeki tam sayfa indeksleri başlığa göre sınıflandırıldı (466 sayfa) ve burada atıfta bulunulan yardım merkezi makaleleriyle birlikte yaklaşık 150 sayfa okundu. Bu makalenin önceki sürümleri Claude Tag'i tamamen gözden kaçırmıştı; bu sürüm de başka bir şeyi atlıyor olabilir. Devlet Kurumları için Claude (Claude for Government) ve üçüncü taraf sağlayıcılardaki Claude Desktop'tan bahsedilmiş ancak analiz edilmemiştir.

• Platform özellikleri aylık olarak değişiyor ve bu yazılırken biri değişti bile. Buradaki her ürün iddiası 29 Eylül–1 Ekim 2026 tarihlerini taşıyor ve bunlara güvenmeden önce tekrar doğrulanmalı. Modlar henüz bir günlük; belgelerini okudum ve tek bir senaryoyu test ettim, üretim ortamında kullanmadım.

• 3.1–3.4 bölümlerindeki ölçülen sayılar, iki parti halinde Claude Code'un kendi kullanım raporlarından geliyor: 2026-09-30'da Claude Code 2.1.286 ve 2026-10-01'de 2.1.287, her ikisi de Claude Sonnet 5.5 üzerinde. Betik, her iki parti ve tüm yanıtlar yazar tarafından saklanmakta olup talep üzerine sunulabilir. Bunlar, claude.ai ve Cowork'un paylaşmadığı Claude Code'un kendi prompt'unu (yaklaşık 30.200 token) içerir ve tek bir modeli, tek bir demo projeyi ve tek bir soruyu kapsar. Örneklem boyutları küçüktür: Yanıt uzunluğu için koşul başına on yanıt, çakışma testi için koşul başına yirmi yanıt. Yanıt uzunluğu oranları iki parti arasında değişti (bölüm 3.3); bir gün arayla alınan iki parti ayrıca Claude Code sürümü açısından da farklılık gösteriyor ve bunu şans faktöründen ayıramıyorum.

• 5. bölümdeki çalışma süresi, maliyet ve bağlam boyutları, uygulamanın üç demo çalıştırması ve bir manuel izolasyon testine ait kendi yanıt günlüğünden gelmektedir; bunlar yazarın kendi kayıtlarıdır.

• Çakışma yanıtları, yazar tarafından kör olmayan şekilde, her yanıt okunarak kodlandı (raporlanan birimler; yanıtın hangi kuralın neden kazandığını belirtip belirtmediği; soru sorup sormadığı). Kırk yanıtın tamamı yeniden kodlama için talep üzerine sunulabilir. Testte "uygulanan" (enforced) ifadesinin tek bir formülasyonu kullanıldı; diğer ifadeler, modeller ve kural çiftleri farklı davranabilir.

• 5. bölümdeki mod testi, tek bir Linux makinesinde, tek bir hook içeren tek bir mod ile, Claude Haiku kullanılarak, bir abonelikle giriş yapılmış ve yönetilen ayarlar olmadan gerçekleştirildi. Bir organizasyonun politika modunu, Team veya Enterprise girişindeki yerleşik korumayı ya da masaüstü uygulamasını test etmedim.

• 3.2 bölümdeki maliyet modeli, ölçülmüş bir faturalama değil, örnek bir firmanın simülasyonudur. Yalnızca talimat tokenlarını kapsar; gerçek faturalarda genellikle konuşma geçmişi, çıktı ve düşünme (thinking) süreçleri baskındır. Token boyutları Anthropic'in herkese açık eski tokenizer'ı × 1.30 kullanır; ölçümde Claude Code bu tahminden %21-26 daha fazla yükledi, dolayısıyla dolar cinsinden rakamlar düşük görünmektedir. Yüzdeleri orandır ve geçerlidir. Oturum kalıpları ve önbellek paylaşımı varsayımdır.

• Enterprise üzerindeki sohbet kullanımının API önbellek fiyatlandırmasından yararlanıp yararlanmadığı ve önbelleklerin claude.ai üzerinde kullanıcılar arasında paylaşılıp paylaşılmadığı belgelenmemiştir. Cowork oturumlarını Claude Code üzerinde çalıştırır ve eklenti hook'ları orada yüklenir, ancak mod sayfaları Cowork'u listelemiyor ve ben de test etmedim; 1 Ekim'de masaüstü uygulaması hâlâ modların etkinleştirilmesinden bir sürüm önceki Claude Code 2.1.286'yı içeriyordu. Bir cihazın yönetilen politikası, organizasyon bunları tam bir VM sandbox'ında çalıştırmadığı sürece kullanıcının makinesindeki Cowork oturumlarına ulaşır. İki sayfa, bir kişinin kendi ~/.claude dosyalarının Cowork'a ulaşıp ulaşmadığı konusunda çelişiyor, bu nedenle bu makale bu konuda herhangi bir iddiada bulunmuyor. Ayrıca üst klasörlerdeki CLAUDE.md dosyalarının bir Cowork oturumunda yüklenip yüklenmediğini de test etmedim; eğer yükleniyorsa, referans uygulamanın bağlanan ağacı bugün kullanıcının makinesindeki Cowork'a ulaşacaktır. Pro ve Max'te bu pencere, yeni Cowork görevlerinin buluta taşınacağı 6 Ekim 2026'da daralıyor.

• Niyetler çıkarıma dayalıdır. Anthropic, Claude sohbetinin ve Cowork'un neden düz bir yapıda olduğunu kamuoyuna açıklamadı.

• Kod ve ham veri bu makaleyle birlikte yayınlanmamıştır. Bir okuyucu yalnızca makaleden yola çıkarak ölçümleri tekrar üretemez; video uygulamanın nasıl inşa edildiğini değil, çalıştığını gösterir.

• Referans uygulama kurgusal bir firma üzerinde çalışır. claude.ai veya Cowork ile entegre değildir ve "olarak hareket etme" (acting as) bir giriş değil, bir demo anahtarıdır. İzinler uygulama tarafından değil, Claude Code'un araç listeleri tarafından uygulanır. İzolasyon, o çalıştırma için kişinin kendi hook'larını ve modlarını kapatır; Claude Code'a yerleşik modlar çalışmaya devam eder ve kişisel ajanların adları yine de bağlamda görünebilir. Uygulama, claude -p komutunun CLAUDE.md'yi yüklemesine bağımlıdır ki Anthropic bunun artık varsayılan olmayacağını söylüyor. Kişisel dosya sızıntısı ve --setting-sources sonucu Windows'ta test edildi; ölçümler ve mod testi ise Linux'ta çalıştırıldı.

Kaynaklar

• Anthropic, Organizasyon talimatlarını belirleme

• Anthropic, Roller ve izinler

• Anthropic, Team planı nedir? · Planlar ve fiyatlandırma

• Anthropic, Enterprise planlarında özel rolleri yönetme

• Anthropic, Claude Cowork'te görevlerinizi projelerle düzenleyin

• Anthropic, Google Workspace bağlayıcılarını kullanma

• Anthropic, Enterprise planlarında grupları ve grup harcama limitlerini yönetme

• Anthropic, Projeler nedir? (projelerin yeni sürümü, beta)

• Anthropic, Claude Cowork ile başlayın(genel ve klasör talimatları)

• Anthropic, Claude projenizi nasıl hatırlar (CLAUDE.md) · Tüm ayarlar (claudeMdExcludes, disableAllHooks)

• Anthropic, Claude Code'u modlarla özelleştirin (1 Ekim 2026) · Modlara genel bakış · Organizasyonunuz için modları yönetin · Bir mod ile olaylara tepki verin · Mod referansı

• Anthropic, Claude Tag: Claude Tag nedir? · Kanal bazlı erişimi yapılandırma · Claude Tag'i özelleştirme · Ajan kimliği nasıl çalışır · Denetim · Harcama limiti belirleme

• Anthropic, Claude Code'da Projeler (yeni projeler betası) · Cowork'te Projeler · Claude Code prompt önbelleğe almayı nasıl kullanır · Claude Code'u programatik olarak çalıştırma (--bare) · Claude Code'u genişletme · Proje görünürlüğünü ve paylaşımını yönetme · Bağlayıcıları kullanma · Tüm organizasyonunuz için MCP bağlayıcılarını yetkilendirme · Becerileri sağlama ve yönetme

• Anthropic, Sunucu tarafından yönetilen ayarları yapılandırma (grup bazlı yapılandırma yok) · Organizasyonunuz için eklentileri yönetme (Enterprise'ta gruba göre eklenti kullanılabilirliği) · Platformlar arası eklenti özelliği desteği (hook'lar sohbette yok sayılır, Cowork'ta yüklenir) · Yönetilen ayarları dağıtma (Cowork oturumlarını Claude Code üzerinde çalıştırır)

• Anthropic, Fiyatlandırma (Sonnet 5.5 tarifeleri, tokenizer notu) · Prompt önbelleğe alma (API'de organizasyon ve çalışma alanı başına izole edilmiş önbellekler)

• Anthropic, @anthropic-ai/tokenizer(sayımlar için kullanılan herkese açık tokenizer)

• Microsoft, Yönetim grupları · Landing-zone yönetim grubu tasarımı

• AWS, SCP değerlendirmesi · Google Cloud, Hiyerarşi değerlendirmesi

• Microsoft, Grup İlkesi işleme · SharePoint ayrıntılı izinleri

• FinOps Foundation, Token ekonomisi

• Jaroslawicz ve diğerleri, LLM'ler Aynı Anda Kaç Talimatı Takip Edebilir? (IFScale)

• Firefly, 2026 IaC araştırmasının durumu

• MCP, Yetkilendirme spesifikasyonu, sürüm 2026-07-28

• GitHub, anthropics/claude-code sorunları #68262, #14467, #30554, #27567, #30250, #27302, #47741

• Beer, S. (1979), The Heart of Enterprise; Alexander, C. (1965), “A City is Not a Tree,” Architectural Forum; Simon, H. (1962), “The Architecture of Complexity,” Proc. Am. Phil. Soc.106(6)

• Referans uygulama ve veriler: Worktree uygulaması, testleri, ölçüm betiği, her iki sonuç partisi ve tüm yanıtlar yazar tarafından saklanmakta olup talep üzerine sunulabilir.