Banger guide by Anthropic. While frontier models have improved at context management, subagents still help in some cases (e.g., parallelizing research tasks with their own context windows). I still use them, but mostly for complex research work via dynamic workflows and /goal. For most agent workflows, folding subagents into the main loop via tool calls and skills makes a ton of sense (as Anthropic recommends). That's because newer models are more persistent and better at managing large contexts. Subagents might be getting in the way now, since models can handle much of what subagents were used for. I see a similar pattern with memory (another day). But you can't just get rid of subagents if you have been using them extensively. You need to run evals (cost, efficiency, etc.) and let that help you determine whether to fold them (and how) into the main agent loop. The evals should always inform your strategy. But keep in mind issues that can arise when scaling agent work, such as too many tool calls, context bloat, and unclear separation of concerns. Subagents are still very useful for that. Lastly, all of this is constantly evolving as frontier models improve. Always keep an open mind and regularly test/eval your workflows and harnesses.

Highly recommended read from Google DeepMind and colleagues. There is a lot of interest in self-evolving agents, but they're hard to get right. This work highlights how important and difficult memory and retrieval are in agents. The big question in this paper is whether self-evolving agents keep learning without forgetting. They tested ReasoningBank, GEPA, and Meta-Harness on four task streams that drift in topic, workflow, or domain, built from BIRD, BFCL, and ScienceWorld. The weights stay frozen, and the agents adapt by rewriting prompts, memory, and skills. Self-evolution improves overall scores on most streams. But more adaptation consistently means agents forget more. Methods that rewrite a shared prompt or workspace make global edits, so they interfere with unseen tasks and overwrite older knowledge when the stream shifts. Memory retrieval keeps updates more local, but it still pulls in memories from other domains and collides when similar queries need different workflows. Static benchmarks hide both problems, so test self-evolving agents on a stream that changes over time. arxiv.org/abs/2610.25858 Chat with Paper: academy.dair.ai/papers/are-s…

Banger paper from Google DeepMind on long-horizon multi-agent coding. (bookmark it) They report that, to the best of their knowledge, this is the first end-to-end autonomous completion of Minecraft by AI agents. They report that four Gemini 4 Argon agents beat Minecraft end-to-end. They defeated the Ender Dragon in 27 hours and 14 minutes with no human intervention. Each agent controlled one player through the standard Mineflayer library. No one assigned roles, wrote game logic, or scouted a seed in advance. The agents planned, wrote, and debugged every program themselves, and coordinated through in-game chat and a shared memory. Over the run, they wrote 2,783 programs and died 605 times. They split the work, shared what they learned, and recovered each other's items after deaths. If you build agents for long software or enterprise tasks, this is a useful case study. The team had to keep one plan consistent across thousands of dependent steps for more than a day. arxiv.org/abs/2610.22319 Chat with Paper: academy.dair.ai/papers/a-tea…

Banger paper from Google DeepMind on co-evolving an agent's harness and its weights. (bookmark it) If you already log your harness changes and results, those logs can become training data for the model running inside the harness. This is a nice paper from Google showing how to do this co-evolution. Specifically, they propose Evo2, a framework for weight-harness co-evolution. How it works: One policy plays two roles. As a Proposer, it writes edits to its own harness, and as a Reflector, it diagnoses what each edit changed. Those edits and their outcomes then become training data for both roles, using SFT followed by interleaved GRPO. The result: Evo2 reaches 48.3% on SWE-bench Verified and 82.1% on Polyglot, against 41.0% and 62.6% for the strongest baselines. The harness part alone moves a GPT-5-mini agent from 24.4% to 48.3% on SWE-bench Verified. The evolved harnesses also transfer to other benchmarks without further evolution. Paper: arxiv.org/abs/2610.13025 Chat with Paper: academy.dair.ai/papers/evo-2…

Recommended NVIDIA paper on memory-efficient post-training RL. A very interesting technique for scaling RL for LLMs. The main takeaway is that you can update all of a model's weights with RL and still use less memory than LoRA. At 1.5B, LoGRA averages 7.2 GiB of training memory, while rank-256 LoRA needs 13.2 GiB. Pass@4 is about the same (81.8% and 81.4%), and Pass@1 is about 2 points lower. If GPU memory is what stops you from running RL on a bigger model, this method is worth a look. LoGRA never builds a full gradient for the weight matrices it compresses. As microbatches accumulate, each weight gradient is compressed with a rank-256 random projection that is redrawn every step, and the update is rebuilt from two small matrices. Before each step, it predicts how much the policy will change and scales the step to stay within a KL budget. Average training memory per GPU drops 45.7% at 7B (31.8 to 17.3 GiB), with peak accuracy close to dense Adam (72.3% and 72.5% Pass@1). It also trains a 27B model for more than 1,100 steps on a single eight-GPU node, where dense Adam runs out of memory. Paper: arxiv.org/abs/2610.06647 Chat with Paper: academy.dair.ai/papers/logra…