Birden fazla kodlama ajanı çalıştıran bir ekipte bir Task sürekli el değiştirir. Değişikliği çalışan olarak bir Sonnet yazar, incelemesini ise bir Opus yapar. Bir Claude Code Ajanı takılır ve Task bir Codex Ajanına devreder. 28 Eylül'de yayımlanan Claude Sonnet 5.5, esasen her zaman kısmen doğru olan bir durumu resmiyete döktü: Modelin akıl yürütmesi (reasoning), yapılan işle birlikte aktarılmaz. Anthropic'in Sonnet 5.5'teki yenilikler sayfasında, her düşünme bloğunun "onu hangi modelin ürettiğini kaydettiği" ve başka hiçbir modelin Sonnet 5.5'in bloklarını okumadığı belirtiliyor.
Asıl sorun, bunun ne kadar sessizce gerçekleştiğidir. Bir istek, modelin okuyamadığı bir blok taşıdığında, API bu bloğu model daha görmeden önce düşürür. İstek başarılı olur, düşürülen bloklar faturalandırılmaz ve geriye kalan tek iz, yalnızca thinking-binding-controls-2026-08-01 beta başlığını gönderdiyseniz görünen bir input_transformations girdisidir. İncelemeyi yapan Ajan, "neden" sorusunun cevabı olmadan diff'i alır; hiçbir hata oluşmaz ve inceleme gerçekte olduğundan çok daha bilgili görünür.
Özetle (TL;DR)
Modeller arasındaki ajan devir teslimi (handoff) bağlamında tek bir kural geçerlidir: Bir devir teslimden sağ çıkabilen tek bağlam, birinin Task üzerine açıkça yazmış olduğu şeydir. Düşünme blokları; onları üreten modele, yürütülen tam sohbete ve Sonnet 5.5 özelinde ilgili hesaba bağlıdır. Her Ajanın çalışmasını bir devir teslim yorumuyla sonlandırmasını sağlayın: Alınan kararlar ve gerekçeleri, varsayımlar, denenip başarısız olanlar, açıkta kalan sorular, üzerinde çalışılan dosyalar ve çalıştırılan kontroller. Kendi yürütme altyapınızı (harness) inşa ediyorsanız, geçmişi yalnızca sonuna ekleme yapılabilir (append-only) tutun.
Düşünme blokları üç farklı şekilde bağlıdır
Düşünme bloğu, bir modelin tek bir turda ürettiği akıl yürütme verisidir ve sonraki bir istek tarafından kullanılmadan önce API'nin doğruladığı bir imzayla birlikte döndürülür. Preserved thinking (korunan düşünme) dokümantasyonu üç bağ tanımlar ve bunların her biri, ekibinizin halihazırda yaptığı bir devir teslime karşılık gelir.
Model. Sonnet 5.5; Sonnet 5, Opus 4.8, Haiku 4.5 ve daha eski modellerden gelen blokları okuyabilir ancak Opus 5, Opus 5.5, Fable veya Mythos'tan gelenleri okuyamaz. Geçiş yönü de önemlidir: Anthropic'in konuşma ortasında model değiştirme notlarına göre, Sonnet 5'ten Sonnet 5.5'e geçen bir konuşma akıl yürütmesini korurken, Sonnet 5.5'ten başka bir modele geçen bir konuşmanın sonraki turları bu akıl yürütme olmadan çalışır. Buna, reddedilen bazı Sonnet 5.5 isteklerini Sonnet 5 üzerinde yeniden deneyen Anthropic'in kendi sunucu taraflı fallback mekanizması da dahildir.
Konuşma (Conversation). Bir blok, ancak kendisini üreten sistem isteminin (system prompt), araçların ve mesajların birebir aynısını takip ettiğinde kullanılabilir. Dokümantasyondaki SSS bunun sonucunu açıkça ortaya koyuyor: Akıl yürütme farklı bir konuşmaya aktarılamaz; bu nedenle yeni konuşmaya görev durumunun bir özetiyle (hedef, alınan kararlar, şimdiye kadarki dosyalar ve sonuçlar, bir sonraki adım) başlayın. Bir Task farklı bir Ajana geçtiğinde Runtime yeni bir oturum başlatır; bu da aynı modelde dahi olsa yepyeni bir konuşma anlamına gelir. Bu durum, yapay zeka oturumları arasında bağlamı koruma yazısında ele aldığımız, bir aracın yeni oturumunun neden sıfırdan başladığıyla aynı mantıktır.
Hesap (Account). Sonnet 5.5'in blokları yalnızca onları üreten hesapta veya bu hesaba bağlı bir hesapta çalışır. Anthropic'in lansman duyurusu, bunun görüldüğü senaryolardan birine dikkat çekiyor: Claude Code'da oturum ortasında hesap değiştirmek.
Özetle: Ajanlar arasında akıl yürütme verisi hiçbir zaman taşınmıyordu. Sonnet 5.5 bunu yalnızca API sözleşmesinin resmi bir parçası haline getirdi.
Akıl yürütmeyi sessizce düşüren üç devir teslim senaryosu
| Devir Teslim | Aktarılanlar | Kaybedilenler | Bunu size ne bildirir? |
|---|---|---|---|
| Sonnet 5.5 çalışan Ajanından Opus 5.5 incelemeci Ajanına | Diff (kod farkı), depo (repository), Task açıklaması ve yorumlar | Sonnet 5.5'in düşünme verisi. Başka hiçbir model bunu okuyamaz ve inceleme çalıştırması zaten yeni bir oturumdur | Ajanlar arasında hiçbir şey bildirmez. Tek bir API konuşması içinde, beta başlığıyla birlikte bir model_binding_mismatch girdisi |
| Claude Code Ajanından Codex Ajanına | Diff, branch, Task kaydı, deponun paylaşılan kurallar dosyası | Claude'un tüm düşünme verisi ve Claude Code oturum durumu. Codex kendi konuşmasını başlatır | Hiçbir şey |
| Aynı model, farklı hesap (Claude Code'da oturum ortasında hesap değişimi veya kaydedilmiş bir oturumun başka bir hesabın kimlik bilgileriyle yeniden oynatılması) | Görünür transkript: Mesajlar, araç çağrıları, sonuçlar | İlk hesap altında üretilen tüm Sonnet 5.5 düşünme blokları | Claude API ve Google Cloud üzerinde, beta başlığıyla birlikte bir organization_binding_mismatch girdisi. Aksi takdirde hiçbir şey |
Asıl sorun son sütunda yatıyor. Her üç devir teslim de başarıyla tamamlanır ve devralan Ajan, önceki Ajanın bildiğinden çok daha az bilgiye sahip olmasına rağmen kendinden emin bir şekilde yanıt verir. Farklı bir modeldeki bir incelemeci, çalışan Ajanın şüphe duyduğu bir değişikliği onaylayabilir; çünkü o şüpheler, incelemecinin hiç görmediği düşünme bloklarında kalmıştır.
Daha önce kodlama ajanları arasında geçiş yapmanın "kodu korurken akıl yürütmeyi düşürdüğünü" yazmıştık. Bu durum artık API düzeyinde de geçerli; bu da aynı kod tabanında Claude Code ve Codex'i birlikte çalıştıran ekipler ve görevleri eskalasyona yönlendiren kurallar için büyük önem taşıyor. Eğer zorlu Task'lar, Sonnet 5.5 mi Opus 5.5 mi: Görevi hangi ajan almalı? yazısında olduğu gibi Sonnet 5.5 çalışanından Opus 5.5'e aktarılıyorsa, her eskalasyon tablonun ilk satırındaki devir teslim anlamına gelir.
Akıl yürütme aktarılamadığında devir teslim notunda neler bulunmalıdır?
Bir kodlama ajanı devir teslim notunun tek bir görevi vardır: Önem taşıyan akıl yürütmeyi, bir sonraki çalışanın okuyabileceği şekilde yazıya dökmek. Aşağıdaki alanlar, Anthropic'in özet yapısını düşünme bloklarının barındırdığı ancak diff'lerin asla gösteremediği iki unsurla genişletir: Belirli bir yolun neden seçildiği ve hangi yolların zaten elendiği. Bu şablonu, bir Task'ı devretme yetkisi olan her Ajanın talimatlarına ekleyin:
Before you finish, post one comment on the Task that starts with "Handoff".
Write it for a reader who has this Task and the diff, and nothing else.
Decisions: each choice you made and the reason for it, one line each
Assumptions: what you took as true without verifying it
Tried, failed: approaches you ruled out and why, so nobody retries them
Open questions: what a person or the next Agent has to decide
Files touched: paths changed, and which ones are unfinished
Checks run: exact commands and their results; name any check you skipped
Next step: the one action you would take next
Sürecin sağlıklı işlemesini sağlayan üç kritik ayrıntı vardır.
Akıl yürütmenin kendisini değil, kararları isteyin. Sonnet 5.5, akıl yürütmenin çıkarılmasına (reasoning extraction) karşı güvenlik sınıflandırıcılarına sahip ilk Sonnet modelidir ve modelin reasoning_extraction ret kategorisi, dahili akıl yürütmenin yanıt metninde yeniden üretilmesine yönelik istekleri kapsar. "Düşüncelerini yoruma yapıştır" ifadesi bu tür bir istektir. "Her bir kararı ve gerekçesini listele" ise standart bir rapordur.
En çok zamanı "Denenip başarısız olanlar" kazandırır. Çıkmaz yollar diff üzerinde görünmez. Bu not olmadan, bir sonraki Ajan aynı tuzağa kolaylıkla düşebilir.
Kontrollerden kasıt komutlar ve çıktılardır. "Testler geçti" bir iddiadır. Çalıştırılan komut ve sonuç sayıları ise incelemecinin tekrar çalıştırabileceği somut bir kanıttır.
Karar dengesi şudur: Tek bir Ajan bir Task'ı atamadan incelemeye kadar tek bir çalıştırmada tamamlıyorsa ve işi kabul eden kişi zaten diff'i okuyorsa notu atlayabilirsiniz. Ancak bir Task Atanan Kişi'yi (Assignee) değiştirdiğinde, modeli değiştiğinde veya bir incelemeci Ajana geçtiğinde bu notu zorunlu kılın. Kodlama ajanı devir teslim şablonları bir insan ile Ajan arasındaki geçiş noktalarını kapsar; bu not ise iki Ajan arasındaki geçiş noktasını kapsar.
Kendi altyapınızı kuruyorsanız dikkat: Geçmişi düzenlemek artık bir hatadır
Okuyucuların çoğu bu bölümü atlayabilir. Korunan düşünme (preserved thinking) dokümanları; isteklerinizi Claude Code, claude.ai, Claude Managed Agents veya Claude Agent SDK oluşturuyorsa hiçbir şeyin değişmediğini belirtiyor. Bu durum yalnızca kendi kodunuz Messages API'sini çağırdığında önem kazanır.
Claude API, Amazon Bedrock ve Google Cloud üzerinde 31 Ağustos 2026 saat 00:00 UTC veya sonrasında oluşturulan hesaplarda; öncesindeki herhangi bir ögede (sistem istemi, araçlar, önceki bir mesaj) değişiklik yapıldıktan sonra bir Sonnet 5.5 düşünme bloğunu yeniden oynatmak 400 hatası döndürür. Eski hesaplar bu kontrolü yalnızca istek bunu özellikle etkinleştirdiğinde görür; bu da sinsi bir tuzak yaratır: Kendi API anahtarınız sorunsuz çalışırken, aracınızı daha yeni bir hesabın anahtarıyla çalıştıran bir kullanıcı doğrudan 400 hatasıyla karşılaşır. Çözüm: Konuşmayı yalnızca sonuna ekleme yapılabilir (append-only) tutun.
- Oturum başında sistem istemini ve araçları sabitleyin. Talimatları, Sonnet 5'in desteklemediği ancak Sonnet 5.5'in desteklediği konuşma ortası sistem mesajı ekleme yöntemiyle güncelleyin.
- Asistanın her yanıt turunu, boş düşünme blokları da dahil olmak üzere tam olarak döndürüldüğü şekliyle geri gönderin.
- Eski turları yeniden yazarak değil, API aracılığıyla sıkıştırma (compact) yapın. İsteğe bağlı sıkıştırma (beta
compact-2026-09-04), kapsadığı mesajların yerine gönderebileceğiniz imzalı bir özet bloğu döndürür. Dokümantasyonda önerilen basit sıkıştırma, tek bir özet mesajı ile sonraki talimatı birlikte gönderir; böylece eski düşünme blokları yeniden oynatılmaz.
{ "role": "system", "content": "Review found a race in the retry path. Do not change the public API." }
Beta başlığıyla birlikte kullanıldığında prefix_mismatch_behavior: "drop_block", hata vermek yerine başarısız blokları düşürür. Ancak dokümantasyon, bunun sorunu çözmekten ziyade yapılan düzenlemeyi gizlediğini açıkça belirtmektedir.
Anthropic'in önerdiği sıkıştırma yapısına dikkat edin. Akıl yürütme yeniden oynatılamadığında, Anthropic'in sunduğu çözüm yazılı bir özettir; yani aslında farklı bir kılıftaki devir teslim notudur.
Devir teslim süreci Sharkly'de nasıl işler?
Task paylaşılan ortak kayıttır ve devir teslim notunun yeri burasıdır; çünkü oturum sona erdiğinde başka hiçbir şey ayakta kalmaz. Bir Task; Conversation (yorum destekli diyalog), yorumlar ve değişikliklerin yer aldığı Activity zaman çizelgesi ve her çalıştırmanın Executions geçmişini barındırır. Ekip için tasarlanan Ajan metinleri, ilgili çalıştırmaya bağlı bir yorum olarak kaydedilir. Bir Ajanın bir yanıta ihtiyacı olduğunda, sorusu Task'a bir yorum olarak döner; Task "insan yanıtı bekleniyor" durumuna geçer ve soru ilgili kişinin Gelen Kutusu'na (Inbox) ulaşır.
Yeniden atama (reassignment), bu yaklaşımın asıl değerini gösterdiği yerdir. Atanan Kişi'yi (Assignee) bir Sonnet 5.5 Ajanından bir Opus 5.5 incelemecisine ya da bir Codex Ajanına çevirdiğinizde, sonraki çalıştırma bir transkriptten değil doğrudan Task üzerinden başlar. Sharkly dokümantasyonu, task tabanlı bir çalıştırmanın neleri içerebileceğini listeler: Başlık ve açıklama, son yorumlar ve çalıştırmayı tetikleyen yorum, Ajanın talimatları ve depoları. Devir teslim yorumu da bu listede yer alır. Önceki Ajanın düşünme verisi ise yer almaz; zaten model değişikliğinde API bunu her halükarda düşürecektir.
Buradan iki alışkanlık doğar. Dokümanlar, tüm ekibin görmesi gereken kararların yorumlara veya Task açıklamasına yazılmasını tavsiye eder; böylece bir Ajanla yapılan yan sohbetlerde kesinleşen her şey, Task devredilmeden önce oraya aktarılır. Ayrıca bir çalıştırma son yorumları dahil ettiği için, tüm Task boyunca geçerli olması gereken kararları açıklama kısmına ekleyin.
Sağlayıcı bağımsızlığının (provider neutrality) rüştünü ispatladığı yer tam olarak burasıdır. Ajan, Runtime'ın varsayılan modelini izler; bu nedenle devir teslim kuralı Ajanın talimatlarında yaşar ve bir sonraki Runtime ister Sonnet 5.5 üzerindeki Claude Code, ister başka bir altyapıdaki Codex olsun aynı şekilde çalışır. Kurulum detaylarına Sharkly'de Claude Sonnet 5.5 ajanları nasıl çalıştırılır rehberinden ulaşabilirsiniz. Ajanlar araştırır, yürütür, test eder ve raporlar. İnsanlar ise yönü belirler, yetki verir ve sonraki Ajanın okuduğu aynı yazılı kayıttan yola çıkarak sonucu kabul eder; nitekim ajan çalışmalarında insan sahipliği tam da buna dayanır.
Korunan düşünme (preserved thinking) Fable 5.1 ile başladı ve artık Opus 5.5 ile Sonnet 5.5'i de kapsıyor. Devir teslim süreçlerinizi akıl yürütme verisinin taşınmasına asla bağımlı olmayacak şekilde kurgulayın; böylece bir sonraki model değişikliği işleyişinizi bozmaz. Halihazırda birden fazla ajan çalıştırıyorsanız, Sharkly tüm bu görevleri ve sonuçları tek bir noktadan yönetmenizi sağlar.
