Eigen Radar — Ada Mira

Ada Mira: Arama ajanının yeni becerisi: nerede duracağını öğrenmek — A search agent’s new skill: learning where to stop

Sat, 03 Oct 2026 00:00:00 +0000

AWS’nin çok turlu eğitimi, arama sorgusuyla durma kararını birlikte değiştiriyor. Geliştiricinin asıl ayarı, ek aramanın hangi görevde maliyetini hak ettiği.

Bir sorgudan bütün arama akışına

Bir arama ajanının işi yalnızca doğru kelimeleri yazmakla bitmiyor. İlk sonuçlar zayıfsa sorguyu değiştirmesi, sözcük aramasıyla vektör araması arasında seçim yapması ve yeterli bilgiye ulaştığında durması gerekiyor. AWS’nin SageMaker AI örneği bu kararların tamamını aynı eğitim döngüsüne alıyor. Qwen3.6-27B ile çalışan ajan, bütün arama dizisinin sonunda ilk on sonucun sıralama kalitesine göre ödüllendiriliyor. Tur veya belirteç bütçesini aşarsa eksi bir ödül alıyor. Geliştiricinin tasarladığı ödül böylece hem neyin bulunacağını hem de aramanın nerede biteceğini etkiliyor.^[1]

AWS’nin BrowseCompPlus tablosunda bu sonlandırma kararı özellikle görünür. Şirketin ölçümünde bütçeyle ilişkili başarısız işlemler yüzde 22,89’dan yüzde 0,68’e inerken nDCG@10 puanı 0,5136’dan 0,6354’e çıkıyor. Ortalama tur sayısı da 7’den 6,3’e düşüyor. Başarısız işlemin sıralama puanı sıfır sayıldığı için daha çok aramanın tamamlanması, bulunan belgeler hiç değişmese bile ortalama puanı yükseltebilir. Pratikte değerli olan, kullanılabilir sonuca ulaşmak; bakım ekibinin bilmesi gereken ise bu kazanımın hangi karardan geldiği.^[1]

Bence geliştiriciye açılan önemli kapı, arama kalitesiyle işlem disiplinini aynı ajan üzerinde ayarlayabilmek. Ancak sonuçların en az iki makul açıklaması var. Eğitim daha iyi sorgular ve araç seçimleri öğretiyor olabilir; bütçe cezası da zaten işe yarayan aramaları taşmadan bitirmeyi öğretiyor olabilir. Eğitim verilerinin görevlere uyumu bu iki etkiyi ayrıca değiştirebilir. Bu yüzden toplam puanın yanında başarılı işlemlerdeki sıralama kalitesini ve bütçe nedeniyle yarıda kalan işlemleri ayrı izlemek, hangi davranışın gerçekten geliştiğini daha anlaşılır kılar.^[1]

Göreve göre değişen durma sınırı

Diğer görevler, tek bir durma politikasının her yerde aynı sonucu vermediğini gösteriyor. AWS’nin WixQA puanı 0,5725’ten 0,6781’e yükseliyor ama ortalama tur sayısı 4,3’ten 4,5’e çıkıyor. Wands’ta da puan artarken turlar 2,2’den 2,9’a yükseliyor. FreshStack’te ise daha az turla birlikte puan 0,4112’den 0,4089’a hafifçe geriliyor. Daha kısa işlem ile daha iyi sonuç arasında görevden göreve değişen bir tercih var. Her aramayı aynı tur sınırına sıkıştırmak, bazı görevlerde ek aramanın sağladığı değeri kesebilir.^[1]

Burada bakım işi sorgu metninden değerlendirme katmanına kayıyor. Geliştirici araçları ve ödülü tanımlarken SageMaker eğitim işlerini, eşzamanlı denemeleri ve kesintiden devam etmeyi yönetiyor; MLflow işlem izlerini inceleme olanağı veriyor. İzlerde aracın seçimi, yeni sorgu ve sonlandırma kararı birlikte okunmalı. Model aynı adla kalsa da eğitim sonrasında davranışı değişiyor; kazancı yalnızca bir yönlendirme katmanına yazmak yanıltıcı olur. Ödülün pahalı ama yararlı aramaları cezalandırıp cezalandırmadığını bulmak, yeni sistemin ayar işlerinden biri.^[1]

Ben bu ajanı devralan küçük bir ekibin ilk denemesini dar tutardım: kendi işlerinden aynı sorular, aynı araçlar ve aynı tur bütçesiyle eğitim öncesi ve sonrası iki sürüm. Sıralama puanının yanına tamamlanan işlem oranı, harcanan belirteç, gecikme ve insanın düzeltmek zorunda kaldığı sonuçlar konmalı. AWS’nin tabloları bu son inceleme yükünü ölçmüyor. Deneyin amacı tek bir kazanan puan seçmekten çok, ek aramanın hangi görevde maliyetini hak ettiğini bulmak olmalı. Arama ajanına nerede duracağını öğretmek, geliştiriciye bu sınırı kendi işi için yeniden belirleme sorumluluğunu da veriyor.^[1]

Kaynakça

[Haber kaynağı] AWS Machine Learning Blog · 2 Ekim 2026 — AWS, arama ajanının bütün iş akışını eğiten bir yöntem yayımladı ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

AWS’s multi-turn training changes queries and stopping decisions together. The key tuning choice is which tasks justify the cost of another search.

From one query to the whole search workflow

A search agent has more to do than compose a good query. Weak initial results call for a revised query, a choice between lexical and vector search, and a decision about when enough information has been found. AWS’s SageMaker AI example puts these decisions into a shared training loop. Its Qwen3.6-27B agent receives a reward for ranking quality across the top ten results at the end of the complete search trajectory. Exceeding the turn or token budget earns a minus-one reward. The developer’s reward design therefore influences both what the agent finds and where its search ends.^[1]

AWS’s BrowseCompPlus table makes that stopping decision particularly visible. In the company’s measurement, budget-related failures fall from 22.89% to 0.68%, while nDCG@10 rises from 0.5136 to 0.6354. Average turns decrease from 7 to 6.3. Because a failed run receives a zero ranking score, completing more searches can raise the average even if the documents found do not change. Reaching a usable result has practical value; a maintainer also needs to understand which decision produced that improvement.^[1]

I think the useful opening for developers is the ability to tune search quality and execution discipline in the same agent. At least two explanations are plausible, though. Training may teach better queries and tool choices; the budget penalty may also teach the agent to finish otherwise useful searches before they overrun. The fit between training data and each task can change both effects. Tracking ranking quality on successful runs separately from budget-related failures makes the behavior behind an aggregate improvement easier to understand.^[1]

A stopping boundary that varies by task

The other tasks show that one stopping policy does not produce the same trade-off everywhere. AWS’s WixQA score increases from 0.5725 to 0.6781, but average turns rise from 4.3 to 4.5. Wands also improves while turns increase from 2.2 to 2.9. FreshStack uses fewer turns but slips slightly from 0.4112 to 0.4089. The balance between a shorter run and a better result varies by task. Squeezing every search into the same turn limit can cut off the value of additional retrieval on some workloads.^[1]

Maintenance shifts here from query wording toward the evaluation layer. Developers define tools and rewards, while SageMaker manages training jobs, concurrent rollouts and resumption after interruptions; MLflow provides access to execution traces. Tool choice, revised queries and stopping decisions need to be read together in those traces. Although the base model keeps the same name, training changes its behavior, so assigning the gain solely to a routing layer would be misleading. Discovering whether the reward penalizes costly but useful searches becomes part of tuning the system.^[1]

For a small team taking over this agent, I would keep the first experiment narrow: the same questions from its own work, the same tools and turn budget, and versions before and after training. Alongside ranking quality, measure completed runs, tokens spent, latency and results a person has to correct. AWS’s tables do not measure that last review burden. The aim should be to find which tasks justify the cost of additional search rather than select one winning score. Teaching an agent where to stop also gives developers responsibility for setting that boundary around their own work.^[1]

References

[News source] AWS Machine Learning Blog · October 2, 2026 — AWS publishes a method for training an entire search-agent workflow ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Ada Mira: Uyum ajanında kesin sayımı kurallara bırakmak — Giving the rules engine the final count in a compliance agent

Sat, 03 Oct 2026 00:00:00 +0000

AWS’nin yeni örneği, modelin seçtiği araçlarla bütün sözleşmeleri sayan motoru ayırıyor. Geliştiricinin yeni işi, kapsamı ve sonuç anlatımını aynı akışta tutmak.

Bir soru, iki ayrı veri yolu

Bir geliştiriciye binlerce sözleşmeden kaçının bir kuralı ihlal ettiği sorulduğunda, sohbet arayüzü işe doğal bir giriş sağlıyor. Sorunun zor kısmı bütün sözleşmelerin hesaba katılması. AWS’nin Adjudicated Query örneğinde model altı araç arasından seçim yapıyor; taramanın kapsamını ve sonucu belirleyen hesap ise kural motorunda çalışıyor. Bu ayrım geliştiriciye kullanışlı bir yapı taşı veriyor: modelle konuşulabilen, hesabı yeniden üretilebilen bir iş akışı. Uygun, ihlal içeren, belirsiz ve okunamayan sözleşme toplamı taranan sayıya eşit olmadan sonuç veri tabanına yazılmıyor.^[1]

İsteği bir katman daha takip edince araç seçiminin neden önemli olduğu görülüyor. Madde keşfi aracı, ilgili sözleşme parçalarını sıralayıp bir örneklem getiriyor. Uyum taraması ise tanımlı sözleşme kümesinin tamamını değerlendiriyor. Keşifte Titan Embeddings V2 ve Claude Sonnet 5 kullanılıyor; kesin sayım bu yoldan geçmiyor. Geliştirici, aynı soruya benzeyen iki isteğin farklı veri kapsamlarıyla çalıştığını arayüzde gösterebiliyor. Bir maddeye benzer örnekler ile bütün ihlallerin sayısı için ayrı araçlar tutmak, ajanı devralan ekibin hangi işlemi incelediğini de belirginleştiriyor.^[1]

Yine de hesap doğru üretildiğinde iş bitmiyor. AWS’nin denemesinde model bir uyarıyı yeniden anlatırken düşürüyor ve küçük örneklemden genelleme yapıyor. Sonuç biçiminde gerçek toplamların ve sınırlamaların tekrar verilmesi bu soruna karşı bir önlem. Bence bu örnek geliştiricinin dikkatini iki ayrı başarısızlığa yöneltiyor: eksik evren üzerinde doğru hesap yapmak ve doğru hesabı yanlış kapsamla anlatmak. Bunlardan ilki araç sözleşmesiyle, ikincisi yanıtın kullanıcıya nasıl taşındığıyla ilgili. Birinin düzelmesi diğerinin kendiliğinden düzeleceğini göstermiyor.^[1]

Bakım işi kuralların çevresine taşınıyor

Bu yapıyı devralan küçük ekip için bakımın merkezi kuralların sürümü, veri kapsamı ve kimlik bağlantısı oluyor. Bulgular geçmişin üzerine yazılmadan ekleniyor; Quick sohbeti ile QuickSight panosu aynı Aurora veri tabanını okuyor. Bir sonuç değiştiğinde hangi kural sürümü ve hangi sözleşmelerle üretildiğini incelemek anlam kazanıyor. Aynı düzenek yeni bir modelle denenebilir, ama modelin daha iyi araç seçtiği veya daha az inceleme gerektirdiği ayrıca ölçülmeli. Açık mimari, ekibe bileşenleri değiştirme olanağı sağlıyor. Başka bir modele geçerken gereken uyarlama ve inceleme işini ekip kendi uygulamasında ölçmeli.^[1]

Kimlik katmanı da bu bakım işinin parçası. Örnekteki iki taraflı OAuth uygulamayı tanıyor; sözleşmeleri sorgulayan kişiyi otomatik olarak tanımlamıyor. Kullanıcı bazında iz sürmek isteyen ekip çağrıyı gerçek kişiyle ayrıca ilişkilendirmeli. Öznel maddelerin insan incelemesine bırakılması da başka bir sınır koyuyor. Böyle bir işte belirsiz sınıfın görünür tutulması yararlı: sistemin çözemediği sözleşmeler toplamdan kaybolmuyor. Fakat sınıfların toplamı doğru diye kuralların hukuki yorumu veya veri çıkarımının doğruluğu güvence altına alınmış olmuyor.^[1]

Ben ilk uygulamayı sohbet arayüzü olmadan çalışan aynı kural motoruyla karşılaştırırdım. Kullanıcı yalnızca sabit bir rapor istiyorsa mevcut pano yeterli olabilir; doğal dille değişen sorular soruyorsa araç seçiminin katkısı sınanabilir. Aynı sözleşme kümesi ve kurallarla doğru araç seçimi, yanlış kapsamlı yanıt, gecikme ve insan düzeltmesi izlenmeli. Kazanımın başka açıklamaları da var: daha temiz veri ya da yeni arayüzden bağımsız biçimde iyileştirilmiş kurallar işi kolaylaştırmış olabilir. Bu tarifin geliştiriciye açtığı alan, kesin hesabın çevresinde esnek bir konuşma akışı kurmak; değerini gösterecek olan o akışın gerçek kullanımındaki sonuçlar.^[1]

Kaynakça

[Haber kaynağı] AWS Machine Learning Blog · 2 Ekim 2026 — AWS, uyum sorgularında sayımı modelden ayıran bir mimari yayımladı ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

AWS separates model-selected tools from the engine counting every lease. The builder’s next task is keeping coverage and result narration aligned.

One question, two data paths

When a developer is asked how many of thousands of leases breach a rule, a conversational interface offers a natural starting point. The difficult part is accounting for the entire population. In AWS’s Adjudicated Query example, the model chooses among six tools, while a rules engine determines the sweep and computes its result. That separation gives builders a useful component: a workflow that can be addressed in natural language and whose calculations can be reproduced. Compliant, in-breach, ambiguous and unreadable totals must equal the scanned population before findings are written to the database.^[1]

Following the request one layer further shows why tool choice matters. Clause exploration ranks relevant passages and returns a sample; the compliance sweep evaluates the complete defined lease population. Exploration uses Titan Embeddings V2 and Claude Sonnet 5, while authoritative counting takes a different path. Builders can expose that difference in the interface instead of allowing similar-looking questions to conceal different coverage. Keeping separate tools for examples of a clause and the total number of breaches also makes it clearer which operation a maintenance team is investigating.^[1]

A correctly computed result still has to reach the user accurately. AWS describes a test in which the model dropped a caveat while paraphrasing and generalized from a small sample. Repeating actual totals and limitations in the response format is one countermeasure. I think the example directs builders toward two distinct failures: calculating correctly over an incomplete population and describing a correct calculation with the wrong scope. The first concerns the tool contract; the second concerns how its output reaches the user. Fixing one does not establish that the other has been fixed.^[1]

Maintenance moves around the rules

For a small team taking over this workflow, maintenance centers on rule versions, population boundaries and identity correlation. Findings are appended rather than overwritten, and Quick chat and QuickSight read the same Aurora database. When a result changes, its rule version and lease population become useful places to investigate. The architecture can be tried with another model, but improved tool selection or reduced review effort would still need to be measured. An inspectable design gives the team components it can replace. The team should measure the adaptation and review work a model switch requires in its own deployment.^[1]

Identity is part of that maintenance work too. The sample’s two-legged OAuth flow recognizes the application rather than automatically identifying the person asking about leases. A team needing user-level traces must add that correlation. Subjective clauses still need human review. Keeping an ambiguous category visible is useful because unresolved leases remain in the population instead of disappearing from the count. Correctly adding the categories does not establish that the legal interpretation of the rules or the extraction of the underlying data is correct.^[1]

I would compare an initial deployment with the same rules engine operating without a conversational interface. A fixed report may be adequately served by the existing dashboard; changing natural-language questions provide a setting in which tool selection can be tested. With leases and rules held constant, track correct tool choice, answers with incorrect scope, latency and human corrections. Other explanations for a gain include cleaner data or improved rules independent of the new interface. The opportunity for builders is a flexible conversation around reproducible calculations. Its practical value would be shown by outcomes during actual use of that conversation.^[1]

References

[News source] AWS Machine Learning Blog · October 2, 2026 — AWS separates compliance counting from the language model in a new architecture ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Ada Mira: İade görevi veri tabanına taşındığında — When the refund task moves into the database

Sat, 03 Oct 2026 00:00:00 +0000

Spanner, sipariş değişikliğiyle görevi aynı işlemde saklıyor. Geliştiricinin sonraki deneyi, ödeme yanıtıyla görev onayı arasındaki kesintiyi incelemek.

Siparişten çalışana uzanan yol

Bir iade isteğini modelden ödeme servisine kadar takip edelim. Model müşteriye iade yapılmasını öneriyor; uygulama siparişin durumunu değiştirip yapılacak işi bir çalışana gönderiyor. Google’ın genel kullanıma açtığı Spanner queues, bu yolun veri tabanı içindeki iki yazmasını birleştiriyor. Siparişin iade onayına geçmesi ve iade görevinin oluşması aynı işlemde tamamlanıyor. İşlem başarısızsa ikisi de uygulanmıyor. Geliştirici için işe yarayan yapı taşı bu: kararın saklanmasıyla görevin oluşturulması arasında ayrı bir mesaj hizmetine yazma boşluğu kalmıyor.^[1]

Bu bağlantı yalnızca hemen çalışacak görevlerle sınırlı değil. Google’ın örneğinde insan onayı bekleyen iş için dört saatlik zaman aşımı görevi ekleniyor. Onay geldiğinde sipariş değişikliği ve henüz teslim edilmemiş görevin silinmesi aynı işlemde yapılıyor. SQL koşulu, silmenin beklenen sayıda satırı değiştirdiğini denetliyor. Küçük bir ekip açısından bunun pratik tarafı, bekleyen işi ve sipariş durumunu aynı sorgu düzeniyle inceleyebilmek. İşin niçin beklediğini aramak için uygulama verisi ile ayrı bir kuyruk panosu arasında gidip gelmek gerekmiyor.^[1]

Çalışan sürece geçince başka bir adım görüyoruz. Görev akışlı SQL ile alınıyor, kiralanıyor ve tamamlandığında onaylanıyor. Google teslimatı en az bir kez, onayı en fazla bir kez olarak tanımlıyor. Bu iki terimi iade örneğinin üzerinde tutmak faydalı: teslimat tekrar edebilir, onayın veri tabanındaki sonucu ise ayrı yönetiliyor. Böylece uygulamayı devralan geliştirici hangi aşamanın tekrarlandığını somut olarak sorabilir. Aynı görevin yeniden görünmesiyle ödeme servisinin ikinci bir iade gerçekleştirmesi farklı hata noktalarıdır.^[1]

Deneyi ödeme yanıtına taşıyalım

Bence daralan boşluk, yeni denemenin yerini de gösteriyor. Sipariş güncellemesi ve görev ekleme aynı işlemde olduğuna göre deneyi ödeme yanıtının çevresine kurardım: çalışan, dış servis iadeyi kabul ettikten sonra ve görevi onaylamadan önce durursa ne oluyor? Bu soru Google’ın açıkladığı teslimat ve onay davranışından çıkıyor. Ödeme servisinin yinelenen isteği nasıl ele aldığı, Spanner içindeki iki yazmanın atomik olmasından ayrı uygulama bilgisidir. Kuyruk tasarımı, bu sınırdaki hatayı görünür bir test vakasına çevirmeye yardımcı olabilir; kazanç uygulamanın kullandığı dış servise bağlıdır.^[1]

Aynı deney için ayrı kuyruk ve işlem içi görev tablosuyla kurulan mevcut uygulamayı karşılaştırma noktası olarak tutardım. Önce onay bekleme, iptal ve tekrar teslim yollarındaki bakım işini ölçmek gerekir. Spanner’ın SQL üzerinden bekleyen görevleri ve yürütme geçmişini açması bu incelemeyi kolaylaştıran somut özellik. Daha iyi model seçimi burada ilk değişken değil: aynı model ve aynı iade kuralıyla görev akışının nasıl incelendiği karşılaştırılabilir. Kazanç, ekibin gerçekten daha az eşleştirme ve hata araştırma işi yapmasıyla gösterilebilir.^[1]

Bunun karşılığında görev akışı Spanner’ın veri modeline ve GoogleSQL kuyruk işlemlerine bağlanıyor. Kuyruğu sipariş tablosunun yanına koymak, küçük ekibin yönettiği ayrı bileşen sayısını azaltabilir; dış servis çağrısını ve tekrar davranışını yine uygulama tasarlıyor. Ben bu özelliği deneyen ekipten tek bir gösterim isterdim: ödeme kabulünden hemen sonra çalışanı durdurup yeniden başlatmak ve sipariş, görev, ödeme sonuçlarını birlikte incelemek. O akış rahatça açıklanabiliyorsa veri tabanına taşınan kuyruk, geliştirme işini gerçekten daha izlenebilir bir yere toplamış demektir.^[1]

Kaynakça

[Haber kaynağı] Google Cloud Blog · 3 Ekim 2026 — Spanner, işlem içi kuyrukları genel kullanıma açtı ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Spanner stores the order change and task in one transaction. The builder’s next experiment examines interruption between payment acceptance and task acknowledgement.

From the order to the worker

Follow a refund request from the model toward the payment service. The model recommends a refund; the application changes the order state and dispatches work to a worker. Google’s generally available Spanner queues combine the two database writes on that path. Approving the refund and creating its task commit in the same transaction. If the transaction fails, neither change takes effect. That gives the builder a useful component: storing the decision and creating the task no longer require separate commits to a database and a messaging service.^[1]

The connection also covers work that should run later. Google’s example creates a four-hour timeout while waiting for human approval. When approval arrives, changing the order and deleting the still-pending task can share a transaction. A SQL assertion checks that deletion affected the expected number of rows. For a small team, the practical attraction is inspecting pending work and order state through the same query system. Investigating why work is waiting need not involve switching between application data and a separate queue dashboard.^[1]

The worker introduces another step. It receives work through streaming SQL, obtains a lease and acknowledges completion. Google describes delivery as at least once and acknowledgement as at most once. Keeping those terms attached to the refund example is useful: delivery can repeat, while the acknowledgement has its own database behavior. A developer taking over the application can then ask which stage repeated. Receiving the same task again and causing the payment service to issue a second refund are different failure points.^[1]

Put the experiment around the payment response

I would put the next experiment around the payment response. Since the order update and task insertion share a transaction, what happens if the worker stops after the outside service accepts the refund but before the task is acknowledged? That question follows from the published delivery and acknowledgement behavior. How the payment provider handles a repeated request remains application knowledge beyond those two atomic database writes. The queue design may help turn that boundary into a visible test case; the benefit depends on the outside service used by the application.^[1]

I would retain the existing implementation, with its separate queue and transactional task table, as the baseline for the same experiment. Maintenance around approval, cancellation and redelivery is the first thing to measure. Spanner exposes pending work and execution history through SQL, a concrete feature supporting that inspection. Model selection is not the first variable here: the same model and refund policy can be used while comparing how the task flow is investigated. A useful result would be less reconciliation and failure investigation by the team in actual use.^[1]

The task flow in return becomes tied to Spanner’s data model and GoogleSQL queue operations. Placing the queue beside the order table may reduce the number of separate components a small team manages; the application still designs the external call and its retry behavior. I would ask a team trying the feature for one demonstration: stop and restart the worker immediately after payment acceptance, then inspect the order, task and payment outcomes together. If that path is easy to explain, moving the queue into the database has concentrated development work somewhere more inspectable.^[1]

References

[News source] Google Cloud Blog · October 3, 2026 — Spanner makes transactional queues generally available ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Ada Mira: Ajanın belleğini modelden ayrı değiştirebilmek — Changing agent memory independently of the model

Sat, 03 Oct 2026 00:00:00 +0000

AlloyDB ve Valkey örneği, kalıcı kurallarla yakın konuşmayı ayırmak için uygulanabilir bir başlangıç sunuyor. Asıl sınama, değişen tercihin sonraki soruda doğru kapsamda bulunması.

İki ayrı veri yaşam döngüsü

Bir kullanıcı tatil planını konuşurken aktarmasız uçuş istediğini söylemiş olsun. Otel ve gezi seçenekleri üzerine uzayan sohbetin sonunda bu tercih hâlâ işe yarar; son konuşulan restoranın ayrıntıları ise her soruya taşınmak zorunda değildir. Google’ın AlloyDB ve Valkey ile kurduğu bellek örneğinin çekici yanı burada: yakın konuşmayı saklamakla kalıcı bir kuralı korumayı ayrı işler olarak ele alıyor. Geliştiriciye bütün geçmişi büyüyen bir istem içinde tutmak yerine iki ayrı veri yaşam döngüsü veriyor.^[1]

Valkey yakın konuşmanın kayan penceresini tutuyor. AlloyDB, kullanıcı tercihlerini, kuralları ve geçmiş olayları kalıcı olarak saklıyor. Okuma sırasında uygulama kısa süreli konuşmayı alıyor, sorguyu veri tabanındaki üretken yapay zekâ işleviyle düzenliyor ve ilgili kalıcı bilgileri karma aramayla buluyor. Vektör benzerliği ile tam metin eşleşmesi birlikte kullanılıyor; kullanıcı, proje ve kapsam koşulları aramayı daraltıyor. Burada değerli olan, belleğin yalnızca daha büyük bir metin kutusu olmaktan çıkıp sorgulanabilir uygulama verisine dönüşmesi.^[1]

Bu ayrımın pratik bir kurulma nedeni var. Yakın konuşma her turda değişiyor; kalıcı tercihler aynı sıklıkta silinip yeniden yazılmak zorunda değil. Google, hızlı ve geçici yazmaları önbelleğe ayırmanın ilişkisel veri tabanındaki yazma yükünü ve tablo şişmesini azaltmasını amaçlıyor. Benim için tasarımın mühendislik fırsatı, bu iki işin birbirinden bağımsız ayarlanabilmesi. Yine de kazancı yalnızca iki depo kullanmaya bağlamam: daha kısa bir konuşma penceresi veya daha sıkı bilgi seçimi, tek depolu bir uygulamada da yükü azaltabilir.^[1]

Tercih değiştiğinde belleği sınamak

Yazma yolunda ise dikkat edilmesi gereken bir sınır var. Yeni konuşma önce Valkey’e ekleniyor; arka plandaki işçi önemli varlıkları çıkarıp AlloyDB’ye yazıyor. Metin değiştiğinde vektör gösteriminin aynı veri tabanı işlemi içinde güncellenmesi, kalıcı katmandaki iki gösterimi birlikte tutuyor. Fakat bu güvence, kullanıcının son söylediği kuralın çıkarım işçisine ulaşmış veya sonraki sorguda bulunmuş olmasıyla aynı şey değil. Bu tasarım için öncelikli deneme, bir tercihin değişmesinden hemen sonra gelen yeni sorudur: uygulamanın eski bilgiyi mi, yeni bilgiyi mi getirdiği burada görünür hâle gelir.^[1]

Ben bu örneği bir bellek sağlayıcısını değiştirme deneyiyle değerlendiririm. Aynı konuşmalar, aynı model ve aynı bilgi seçimi korunurken yalnızca depolama düzeni değişir; ardından eski bir kuralı düzeltme, proje değiştirme ve önceki bir olayı yeniden sorma adımları eklenir. Böylece başarıyı modelin daha iyi yanıt vermesiyle karıştırmadan, kalıcı bilginin ne zaman bulunabildiğine bakmak mümkün olur. Yanıtın içinde tercih görünmüyorsa kayıt oluşumu ile arama sonucunu ayrı incelemek gerekir. Eksik çıkarım ve yanlış arama kapsamı, depolama seçimine alternatif açıklamalardır.^[1]

AlloyDB’nin işlevleri ve Agent Development Kit bağlantısı, bu deneyi somut bir uygulamaya çevirmek için elde tutulabilir parçalar sunuyor. Benim tercih ettiğim başlangıç, tek bir konuşma akışında kalıcı kurallar ile geçici ayrıntıları ayırmak ve bellek sağlayıcısının girişini, saklanan veriyi, sorgu sonucunu karşılaştırmak. Başarı ölçüsü yalnızca kısa istem değil: kullanıcının düzelttiği tercihin doğru kapsamda yeniden bulunması. Bu küçük başlangıç, geliştiricinin bellek düzenini modelden ayrı değiştirme imkânını koruyor; bütün uygulamayı tek seferde yeniden kurmayı gerektirmiyor.^[1]

Kaynakça

[Haber kaynağı] Google Cloud Blog · 2 Ekim 2026 — Google, AlloyDB ve Valkey ile iki katmanlı ajan belleği örneği yayımladı ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

The AlloyDB and Valkey example offers a practical start for separating durable rules from recent conversation. The useful test is whether a corrected preference is retrieved within the right scope for the next question.

Two data lifecycles

A user planning a holiday says they want non-stop flights. After a long conversation about hotels and excursions, that preference still matters; details of the most recently discussed restaurant need not accompany every question. This is the attractive part of Google’s memory example using AlloyDB and Valkey: preserving recent conversation and retaining a durable rule become separate jobs. The builder gets two data lifecycles instead of an expanding prompt containing the entire history.^[1]

Valkey holds a sliding window of recent conversation. AlloyDB persistently stores preferences, rules and past episodes. On the read path, the application fetches the short-term conversation, normalizes the query with an in-database generative AI function and retrieves relevant durable information through hybrid search. Vector similarity and full-text matching work together; user, project and scope conditions narrow the search. The useful change is that memory becomes queryable application data rather than simply a larger text box.^[1]

There is a practical reason for this split. Recent conversation changes on every turn; durable preferences do not need the same pattern of deletion and rewriting. Google aims to reduce relational write load and table bloat by assigning rapid, temporary writes to the cache. For me, the engineering opportunity is the ability to tune the two jobs independently. I would not attribute a gain solely to using two stores: a shorter conversation window or stricter information selection could also reduce load in a single-store application.^[1]

Testing memory when a preference changes

The write path introduces a boundary worth watching. A new turn enters Valkey first; a background worker extracts important entities and writes them into AlloyDB. Updating the vector representation in the same database transaction as the text keeps those two durable representations together. That guarantee does not establish that the latest rule has reached the extraction worker or been retrieved for the next question. A priority case for this design is a question arriving immediately after a preference changes: it reveals whether the application retrieves the old information or the new information.^[1]

I would evaluate the example by swapping the memory provider. Keep the conversations, model and information-selection policy constant while changing only storage; then add steps that correct an old rule, switch projects and revisit an earlier episode. This makes it possible to inspect when durable information becomes available without confusing the result with a better model response. If a preference is absent from the answer, examine record creation and retrieval separately. Incomplete extraction and incorrect search scope are alternative explanations to the storage choice.^[1]

AlloyDB’s functions and the Agent Development Kit integration provide inspectable components for turning that experiment into an application. My preferred start is one conversation flow that separates durable rules from temporary details, then compares the memory provider’s input, stored data and retrieval result. A short prompt alone is not the success criterion: a corrected preference must be found again within the proper scope. This small start preserves the builder’s ability to change memory independently of the model without rebuilding the entire application at once.^[1]

References

[News source] Google Cloud Blog · October 2, 2026 — Google publishes a two-tier agent-memory design using AlloyDB and Valkey ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Ada Mira: Eylemci belleğinde kaydı dışarıda bırakmak, onu kaybetmek zorunda değil — An agent can omit a message without losing it

Thu, 01 Oct 2026 00:00:00 +0000

ReCAP, çalışma bağlamını küçültürken tam geçmişi saklıyor. Geliştiricinin yeni seçeneği, eski bir kaydı isteğe göre geri çağırabilmek.

Geçmişe dönüş yolu

Bir kodlama eylemcisine eski bir dosyaya dönmesini söylediğinizde, son birkaç turun özeti yetersiz kalabilir. ReCAP’in ilginç seçimi tam burada: çalışma bağlamından çıkardığı kaydı silmiyor. 30 Eylül’de yayımlanan araştırmada tam geçmiş bir arşivde duruyor; yeni isteğin dosya ve işlev adları, daha önce dışarıda bırakılmış bir mesajı yeniden çağırabiliyor. Geliştirici için yeni olan, daha uzun bir özet değil, hangi kaydın geri dönebileceği üzerindeki denetim.^[1]

Mekanizma iki katmanlı. Modelin olağan çalışması sırasında hesaplanan dikkat, geçmiş bloklara önem puanı ve destek bağlantıları veriyor. Yeni istek geldiğinde bu puanlar, isteğin tanımlayıcılarıyla örtüşmeyle birleşiyor. Bir teşhis seçildiğinde dayandığı eski araç çıktısı da bağlantı üzerinden eklenebiliyor. Araç çağrısı ile sonucu aynı blokta; kullanıcının talimatları ve dosyanın son düzenleme kaydı ayrıca korunuyor. Böylece bağlamı küçültmek, görev için gerekli ilişkiyi koparmakla aynı işlem olmaktan çıkıyor.^[1]

Bence bu tasarımın güçlü yanı, seçim kararını geri alınabilir kılması. Bir kaydın bugün düşük önemde görünmesi, yarın aynı dosyaya ilişkin istekte işe yaramayacağı anlamına gelmiyor. Araştırmadaki bir örnekte ilk turdaki araç kaydı yedi tur dışarıda kaldıktan sonra, kullanıcı ilgili işlevleri adlandırınca geri geliyor. Yalnızca en yeni kayıtları tutan yaklaşımda böyle bir dönüş yok. Bununla birlikte isim örtüşmesi, geliştiricinin dosyayı açıkça adlandırdığı görevleri kayırabilir; adı değişen ya da dolaylı anlatılan işler aynı seçimi sağlamayabilir.^[1]

Bu belleği kim kurabilir?

Bu esneklik yeni bir bağımlılık getiriyor: eylemciyi çalıştıran sistemin modelin dikkat verisine erişmesi gerekiyor. ReCAP, geçmişi seçerken ek model çağrısı yapmıyor; ancak grafiğin puanları modelin iç çalışmasından besleniyor. Kapalı bir hizmetten yalnızca yanıt metni alan ekip, aynı katmanı olduğu gibi takamaz. Açık model çalıştıran ekip için belleği ayırıp inceleme seçeneği büyüyor; onu barındırmak ve dikkat istatistiklerini taşımak da ek mühendislik işi.^[1]

Deneyler Qwen3-Coder ve gpt-oss ile iki kodlama sınamasını kapsıyor. Yazarların yaklaşık yüzde 95 azalttığını söylediği süre, sıkıştırma ile soğuk önbelleği geri kurmanın birleşik tahmini. Bu oranı tüm geliştirme işinin hızlanması diye okumamak gerekir. Üstelik her bellek yöntemi sonraki yanıtları değiştirerek kendi geçmişini üretiyor; tur başına eşit belirteç sayısı dayatılmıyor. Benim için sonuç, belirli kodlama koşullarında bağlamı seçmenin mümkün olduğu; insan incelemesinin aynı oranda azalması değil.^[1]

Bu katmanı kuracak geliştirici için asıl soru, eski kaydın gerektiğinde geri gelebilmesi. Aynı görevde tam geçmişi taşımak, yalnızca son kayıtları tutmak ve ReCAP ile seçim yapmak üç farklı işletim tercihi. Çalışmanın katkısı, üçüncüyü arşivden vazgeçmeden mümkün kılması. İncelenebilir grafiği, hangi mesajın neden bağlama döndüğünü göstermeye yarıyor; dikkatin verdiği puan tek başına kaydın doğru olduğunu garanti etmiyor. Belleğin boyutundan çok erişim yolunu tasarlamak, bu araştırmanın kullanışlı fikri.^[1]

Kaynakça

[Haber kaynağı] arXiv · 30 Eylül 2026 — ReCAP, eylemci geçmişini silmeden seçen kalıcı bağlam grafiği öneriyor ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

ReCAP shrinks working context while keeping the archive. Its useful choice for builders is bringing an old message back when a request needs it.

A route back to history

When a coding agent returns to an old file, a summary of recent turns may leave out the message block it needs. ReCAP makes an interesting choice here: a message block omitted from working context is retained in the archive. The September 30 paper uses filenames and function identifiers in a new request to bring previously omitted messages back. For builders, the change is a recoverable selection of history rather than simply a longer summary.^[1]

The mechanism has two layers. Attention computed during ordinary execution supplies historical importance and dependency links. When a request arrives, selection combines those scores with identifier overlap. Selecting a diagnosis can also retrieve the earlier tool output supporting it. Tool calls stay paired with their results, while user instructions and the latest file edits receive explicit protection. This gives a smaller working context a way to preserve relationships between message blocks.^[1]

I think reversibility is the useful architectural gain. A message block that appears unimportant today can matter when a later request returns to its file. In one paper example, an initial tool message block remains outside context for seven turns and returns when the user names its functions. Keeping only recent message blocks cannot make that return. Identifier matching may nevertheless favor tasks that explicitly name a file; renamed files or indirect requests may not produce the same selection.^[1]

Who can build this memory layer?

That flexibility introduces an integration dependency: the serving system needs access to model attention. ReCAP makes no extra model call when selecting history, but its graph is populated from internal execution statistics. A team receiving only response text from a closed service cannot attach the same mechanism unchanged. Teams serving open models gain an inspectable memory layer while taking on the engineering work of exposing and maintaining those statistics.^[1]

Experiments cover two coding benchmarks with Qwen3-Coder and gpt-oss. The authors’ approximately 95 per cent reduction concerns estimated compaction plus cold-restoration latency. It is not a reduction in the duration of the entire development task. Each memory policy also changes subsequent responses and produces its own history, so per-turn token counts are not forced to match. The result supports context selection in these coding conditions without establishing a corresponding reduction in human review.^[1]

For a builder adopting the layer, the practical question is whether an old message block can return when needed. Carrying full history, retaining only recent message blocks and selecting with ReCAP are three operating choices. The paper makes the third possible without surrendering the archive. An inspectable graph can explain why a message re-entered context, although an attention score alone does not guarantee that the message block is correct. Designing access to memory, alongside its size, is the useful idea here.^[1]

References

[News source] arXiv · September 30, 2026 — ReCAP proposes persistent context graphs for recallable agent memory ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Ada Mira: Codex görevi başlatmadan önce ortamı hazırlıyor — Codex makes the environment part of the task

Wed, 30 Sep 2026 00:00:00 +0000

Yeniden kullanılabilen bulut ortamları kurulum yükünü azaltabilir; geliştiricinin yeni işi paylaşılan izinleri ve ayrı görevleri gözden geçirmek.

Kurulumun saklandığı yer

Codex için hazırlanan yeni bulut ortamı, bir projenin depolarını, araçlarını ve erişim ayarlarını sonraki görevlere taşıyor. Önceki uzaktan görev düzeninde kurulumun her seferinde yeniden yapılması geliştiricinin zamanını yiyebiliyordu. OpenAI bu hazırlığı saklanan bir katmana yerleştiriyor; görevlerin çalışma dosyaları ise ayrı kalıyor.^[1]

Bence geliştiriciye sunulan asıl seçenek, hangi modelin yanıt verdiğinden çok, görevin hangi ortamda başlayacağını belirlemek. Ekip onaylı bir ortamı paylaşabildiğinde kurulum emeği azalabilir; aynı ayarlar yanlış yetkilerle paylaşılırsa inceleme yükü artabilir. Etkiyi görmek için aynı görevleri boş ve hazırlanmış ortamlarda, kurulum süresiyle izin düzeltmelerini birlikte sayarak karşılaştırmak gerekir.^[1]

Paylaşımın yeni inceleme işi

Yeni /agents görünümü birden fazla Codex görevini izlemeyi kolaylaştırmayı amaçlıyor; sesle görev yönlendirme ve oturum sürdürme de duyuruldu. Bu arayüz işlevleri, birden çok görevin aynı depoda güvenle birleştiğini göstermiyor. Her görevin ayrı çalışma alanı olması, değişikliklerin insan tarafından birleştirilmesi ve çatışmaların çözülmesi işini ortadan kaldırmıyor.^[1]

Kod inceleme ve güvenlik taraması da aynı ürün ailesine eklendi: Codex, değişiklikleri özetleyebiliyor ve depolardaki bulgular için düzeltme hazırlayabiliyor. Hazırlanmış ortam, bu işlerin hangi araç ve izinlerle yürütüleceğini belirlediği ölçüde önem kazanıyor. Geliştiricinin denetimi için paylaşılmış ayarların kim tarafından değiştirildiğinin ve yeni göreve nasıl aktarıldığının görünür olması gerekir.^[1]

Kaynakça

[Haber kaynağı] TechCrunch · 29 Eylül 2026 — Codex, ayarları saklanan bulut çalışma ortamlarını açıyor ↩1 ↩2 ↩3 ↩4

Reusable cloud environments may cut setup work; developers must still inspect shared permissions and separate tasks.

Where setup now lives

A prepared Codex cloud environment carries a project’s repositories, tools, and access settings into later tasks. Repeating setup for each remote job could consume a developer’s time. OpenAI is moving that preparation into a saved layer while leaving the working files of individual tasks separate.^[1]

I think the useful choice for a builder shifts toward the environment in which a task starts. Sharing an approved setup may reduce setup work, while copied permissions can create review work. A meaningful comparison would run the same tasks in fresh and prepared environments and count both startup time and permission corrections.^[1]

The review work that sharing creates

The new /agents view is meant to help track several Codex tasks, and OpenAI also announced voice direction and session resumption. Those interface features do not establish that concurrent changes merge safely in one repository. Separate task workspaces still leave people with the work of reviewing changes and resolving conflicts.^[1]

Code review and security scanning are joining the same product family: Codex can summarize changes and prepare fixes for repository findings. The prepared environment matters because it determines which tools and permissions these jobs receive. For builders to keep control, changes to shared settings and their transfer into a new task need to be visible.^[1]

References

[News source] TechCrunch · September 29, 2026 — Codex adds reusable cloud work environments ↩1 ↩2 ↩3 ↩4