The Org Age of AI has become one of our most popular series. And it's easy to see why. Throughout the first half of 2026, we focused on the practical side of enterprise AI adoption – the topics very few people were talking about. Some of these ideas may seem obvious in hindsight, but the reality is that people across every profession need clear roadmaps and tips to apply AI effectively in their work and businesses.

Here, we've gathered the complete collection of everything we've covered so far, along with two additional articles that perfectly complement the series and further broaden your perspective.

#1: AI Feels Powerful. So Why Is the ROI Still Missing?

In 2026, companies already have access to powerful AI models and agents. But the biggest gains won’t come from chasing the newest model alone. Much bigger profit comes from redesigning workflows around AI: encoding expert knowledge, feedback, and business rules into systems that can actually compound over time. Here are the tips to unlock the strongest returns from AI investments →

AI Workflow Redesign: Why ROI Needs Restructured Work

Most AI pilots fail because companies bolt tools onto old workflows. Here's why AI workflow redesign is the real source of enterprise value and ROI.

Turing Post • Ksenia Se

#2: The Unsexy Truth of AI Adoption: A 5-Level Maturity Framework

Many companies think they're one AI agent away from transformation. But in practice they are struggling to make their own organizations understandable to AI. Here is a practical 5-level maturity framework to adapt your companies to work with machines.

Image Credit: Turing Post

#2: The Unsexy Truth of AI Adoption: A 5-Level Maturity Framework

AI adoption fails when companies skip the middle layers. A practical 5-level maturity framework for making organizations legible to machines, with real use cases.

Turing Post • Ksenia Se

#3: How to Build an AI-Native Startup from Day One

While we first discussed how to rebuild existing organizations for AI, it's now interesting to explore how to build a startup designed for AI from the very beginning. We outline the main principles →

#3: How to Build an AI-Native Startup from Day One

What actually makes a startup AI-native — and how to build one from day one. A practical framework of 5 principles: machine-legibility, tool portability & more.

Turing Post • Ksenia Se

#4: There are no AI-native enterprises

Well, we talk about AI-native enterprises, but the uncomfortable reality is that none exist yet. The hardest part is untangling decades of hidden workflows, politics, and institutional habits that AI can't simply automate. 

#4:There are no AI-native enterprises

Why the enterprise AI problem is not a technology problem. In the series: The Org Age of AI

Turing Post • Will Schenk

#5: AI Workflow Patterns: The Real Unit of AI Adoption in 2026

As you've probably noticed, we've been talking a lot about updating workflows, not models, inside organizations. To help you avoid focusing on the wrong abstraction, we define it once again: the real unit of AI adoption is the workflow.

#5: AI Workflow Patterns: The Real Unit of AI Adoption in 2026

Seven agentic AI workflow primitives, eight production patterns, and a practical framework for deciding which workflows to automate first — with real use cases.

Turing Post • Will Schenk

#6: The Flywheel: What Happens When Workflows Run Themselves

Once you've built the system, another layer emerges – one that has only recently become a practical reality. AI can now generate, test, and refine its own work without a human checking every step. But if a workflow learns from flawed metrics, it can repeat the same mistake faster with every cycle. That's why verification has moved to the forefront.

#6: The Flywheel: What Happens When Workflows Run Themselves

AI flywheels are closed-loop workflows that generate, measure, and decide what to try next. Here’s why verification must come before autonomy

Turing Post • Will Schenk

Next, we have two practical articles that broaden your perspective on how AI can drive greater enterprise value.

1. AI 101: From Vibe Coding to Spec-Driven Development

As more companies let AI write production code in 2026, "vibe coding" is really no longer enough. Enterprise teams need concrete specifications, testing, and verification so coding agents can build software that stays reliable as projects grow. Spec-Driven Development makes this work.

Spec-Driven Development vs Vibe Coding: Tools & Guide (2026)

Why vibe coding breaks at scale — and how spec-driven development (SDD) fixes it. Covers Kiro by AWS, GitHub Spec Kit, Tessl, and when to use each approach.

Turing Post • Alyona Vert.

2. What is Hybrid AI?

Enterprise AI often fails because every task has different latency, privacy, and cost requirements. Deploying AI across thousands of employees, cloud-only quickly becomes expensive and slow. Hybrid AI lets companies run the right workload in the right place instead of sending everything to the cloud.

What is Hybrid AI?

It’s not about architectural hybrids, it’s about where to run a model. The big promise in connecting devices and clouds for the nearest future of AI.

Turing Post • Alyona Vert.

Announcing a super interesting workshop from our partners →

AI coding agents like Claude Code are transforming software development, but most security teams are still protecting against human-speed threats.

When an agent can read, write, and execute code autonomously, EDR, DLP, and static rules-based controls simply weren't built for it. The attack surface has changed. The security playbook has to change with it.

Join us on July 14 for a live webinar "Securing Claude: Playbook for Governing Coding Agents " — a practical session on how to govern AI agents without slowing down your developers.

We'll cover:

• The Risk Landscape — Real-world examples of coding agents going rogue

• The Legacy Gap — Why traditional security tools fail against autonomous AI

• Actionable Blueprints — A new reference architecture for AI security

• Live Demo — Watch Rubrik Agent Cloud govern and block unintended Claude actions in real-time

🛡️ This event is presented by the Rubrik team. We thank Rubrik for sharing their expertise and supporting Turing Post’s mission to bring clarity to the AI landscape.

AI progress in 2026 is now coming from many different directions. Some advances rethink model structure, like DeepSeek mHC and depth-addressable Transformers. Others focus on memory, fine-tuning, self-distillation, inference hardware, or the runtime pipelines. But the main theme running through everything is that AI is becoming more selective, modular, and infrastructure-aware.

This recap connects two layers of the same story. The first layer is new research ideas: conditional memory, post-RL fine-tuning, on-policy distillation, inference chips, and deeper ways to reuse Transformer representations. The second layer is the practical AI workflow: tokens, token types, embeddings, vector databases, attention, KV cache, and inference orchestration.

If you want to understand where AI systems are going, you need both: the new techniques at the frontier and the basic mechanisms that make them usable.

1. DeepSeek mHC: Breaking the Architectural Limits of Deep Learning

DeepSeek’s mHC, or Manifold-Constrained Hyper-Connections, shows a new way of thinking about AI architecture. For years, deep networks relied on residual connections to keep signals from vanishing, but that stability also limited how much information could transform across layers. Hyper-connections made routing more flexible, but less stable. mHC adds geometric constraints – doubly stochastic matrices and Sinkhorn-Knopp normalization –  to mix information without exploding or disappearing. In 2026, this matters because the next gains may come from designing newer  architectures where stability and expressivity can coexist.

Image Credit: Image Credit: mHC original paper

2. Conditional Memory and the Rise of Selective Intelligence

Conditional Memory, introduced through DeepSeek’s Engram architecture, explores a new idea: models shouldn’t have to activate all of their knowledge for every task.Models typically store everything in parameters or ever-growing context windows, but Engram lets models selectively retrieve memory through sparse lookups. One of the most interesting findings is the “U-shaped allocation law,” showing that the best systems balance memory capacity and computation rather than maximizing either one.This new memory type really matters because AI is moving toward selective intelligence with architectures that decide what to remember, what to retrieve, and where to spend compute. 

A conceptual routing schematic diagram, Turing Post

3. Beyond RL: The New Fine-Tuning Stack for LLMs

 In 2025, everyone put the RL loop front and center of post-training. And it still matters, but it remains expensive, brittle, and often too noisy. This episode maps the newer fine-tuning stack:

• Generated adapters like Doc-to-LoRA and Text-to-LoRA

• Compressed and structured LoRA variants like LoRA-Squeeze and Kron-LoRA, Mixture of Adapters

• Gradient-free Evolution Strategies

And you can mix any of this LoRA with Evolution Strategies. As model capabilities are becoming modular and can be optimized separately, fine-tuning of 2026 starts to look more like designing an adaptive ecosystem around model.

Image Credit: Turing Post

4. "On-Policy Distillation Zeitgeist"

On-policy self-distillation becoming one of the more practical post-training directions of 2026. The core idea is that strong models can learn from their own improved versions: by comparing an uninformed answer with a version that has access to a solution, a demo, or rich feedback. The article walks through OPSD, SDFT, and SDPO to show how self-distillation can refine reasoning, support continual learning, and use feedback more efficiently than standard RL loops. Self-education is one of the central focuses where models are starting to improve by analyzing what they themselves got wrong. 

Image Credit: “On-Policy Self-Distillation for Large Language Models” paper

5. The Inference Chip Wars – MatX, Taalas, and the Cracks in the GPU Era

The inference chip wars became one of the most important infrastructure stories of the first half of 2026. AI deployment has moved from training to serving billions of tokens and the competition is about cost per token, latency, power efficiency, and context handling.  Inference is fragmenting by workload, creating room for specialized hardware beyond GPUs and reshaping the economics of AI at scale. 

We found these three visions of the future especially interesting:

• NVIDIA’s rack-scale Vera Rubin platform

• MatX’s programmable LLM-first accelerator

• Taalas’ radical “model-as-hardware” approach, where a specific model is effectively baked into silicon.

We unpacked their exact workflows in this article.

Image Credit: Turing Post

6. Transformers Depth Is an Addressable Dimension

Traditionally transformer depth was something that tokens needed to pass through. But this year appeared an idea that you can search through them. This article follows two new approaches – Kimi’s Attention Residuals and ByteDance Seed’s Mixture-of-Depths Attention (MoDA) – that tackle the same issue: useful early-layer signals get diluted as deep Transformers keep adding residual updates. Attention Residuals makes the residual stream choose which earlier layers matter. MoDA lets attention heads retrieve keys and values from previous layers. As a result, depth turns into an addressable memory dimension, giving Transformers a way to reuse intermediate representations instead of letting them wash away.

Image Credit: Attention Residuals original paper

Special collection of guides on LLM workflow

1. What Is a Token (and why it runs AI)?

Tokens may sound just like the smallest building block in AI, but they shape almost everything that happens inside a model. For example, text becomes tokens, context windows are measured in tokens, and every prompt, response, and API bill depends on them. Less obvious, though, is that tokens have become AI’s economic unit: they determine cost, latency, and infrastructure efficiency. Understanding tokenization is the key to deploying and using AI effectively as well as figuring out how autoregressive LLMs are built inside.

Image Credit: Bit-level BPE original paper

2. LLM Token Types: Input, Output, Reasoning, Cached & More

When you know what are tokens, you need to know what tokens exist. Modern AI systems work with a whole “token zoo”: input and output tokens, reasoning, cached, speculative tokens, as well as retrieval, tool-use and multimodal tokens. Each consumes different amounts of compute and affects cost in different ways. In this article, we explain why agentic AI is changing token economics, with hidden overhead from tool calls, retrieval loops, and reasoning often dwarfing the visible prompt and response. In 2026, understanding token types is becoming just as important as understanding models, because AI performance is increasingly an optimization problem as much as a modeling one.

Image Credit: The Turing Post

3. What’s So Magical About Embeddings?

The next stage after tokenization is the creation of embeddings. Tokens become vectors in a shared geometric space where distance reflects meaning. I the article, we follow this process and unpack why Rotary Position Embeddings (RoPE) – which encode position through rotation rather than fixed embeddings – became the standard for handling long context. In 2026, embeddings sit at the center of modern AI, powering search, retrieval, memory, multimodal models, and the contextual understanding that makes today's systems work.

Image Credit: What are Vector Embeddings? by Qdrant

4. Agentic Vector Databases – What Is That?

This year, even core concepts like vector databases have evolved. They are becoming much more than passive retrieval stores in the agent era. Today we have agentic search, memory, and knowledge-engine layers instead of precious RAG. It’s a whole new infrastructure that lets models and agents emember, navigate, and act on knowledge over time. There are three interesting approaches:

• Chroma’s Context-1 separates search from final reasoning

• Weaviate’s Engram turns interactions into managed memory

• and Pinecone’s Nexus compiles raw data into task-specific artifacts for agents before they ask.

Image Credit: Pinecone Nexus blog post

5. Your Ultimate Guide to Attention: Mechanism, QKV, and KV Cache

Everyone needs this guide to learn or refresh how autoregressive models (the one which generate one token at a time) work. Attention remains the core computation behind modern Transformers. This article breaks down the full attention pipeline – from queries, keys, and values (QKV) to self-attention, multi-head attention, and KV cache – and explains why these mechanisms let models build rich context instead of treating tokens independently. It also covers newer ideas and other KV-efficient variants that make long-context reasoning practical. As context windows keep growing and AI agents process more information, attention optimization is becoming just as important as scaling models themselves.

Image Credit: Transformer architecture showing self-attention layers and positional encodings, Attention is All You Need

6. From Tokens to Answers: What Actually Happens During LLM Inference

Finally, we are gathering all these parts together to answer ta question: What happens between your prompt and the model’s response? We walk you through the entire runtime pipeline: tokenization → embeddings → attention and KV cache, plus retrieval, batching, memory management, and orchestration. Today inference really highly depends on orchestration as well as on the model itz As reasoning models and agents grow more complex, orchestration around the model is becoming just as important as the model itself.

Image Credit: The Turing Post

Announcing a super interesting workshop from our partners →

Claude is running in your enterprise.

It’s scheduling, drafting, analyzing, and making calls – and in most organizations, nobody has a clear answer to a very simple question: what exactly is it doing?

That’s not a Claude problem. That’s a governance problem. And it’s exactly what turns a well-intentioned AI agent into something that accesses what it shouldn’t, skips the steps it finds inconvenient, and causes damage faster than anyone can react.

We call that Chungar.

Rubrik is Customer Zero for this problem.

They are deploying Claude. Rubrik is the first organization to put Rubrik Agent Cloud to work governing a live Claude implementation – and on June 30, they are opening that experience up in a hands-on lab.

This isn’t a webinar. You will:

• Watch a Claude deployment go off-script live, 

• see Rubrik Agent Cloud catch it in real time, 

• and then fix it yourself in a proctored lab environment.

Seats are limited.

🛡️ This event is presented by the Rubrik team. We thank Rubrik for sharing their expertise and supporting Turing Post’s mission to bring clarity to the AI landscape.

AI agents became the center of the first half of 2026. We got persistent systems with memory, tools, skills, that can act across software and physical environments. This recap us a broad look at this shift through several angles – local agents such as OpenClaw and Hermes, model choices like Gemma 4, skill engineering, more advanced systems like VLA models for robotics, Web World Models, recursive self-improvement recent boom, and Responsible AI for systems that can actually do things.

Infrastructure is becoming as important as agents and models themselves. Systems of the new generation need features such as identity, memory, skills, environments, and many others. So let’s refresh what happened in the first half of 2026 – what can advanced systems safely and reliably do?

1. OpenClaw Explained + lightweight alternatives

There's really only one place to start this recap, and it’s OpenClaw. OpenClaw captures the local agent boom better than almost anything else in early 2026. It turns a personal AI assistant into file-backed infrastructure: 

• identity in SOUL.md

• scheduled reasoning in HEARTBEAT.md

• memory in Markdown

• tool execution coordinated through a central Gateway. 

Many people are no longer satisfied with simple chatbots – now they need a personal control plane that integrates with messengers like WhatsApp, Telegram, Discord, and Slack. With this new local assistants philosophy, agents started to be durable systems with memory, advanced tool use, and identity. And the best thing, of course – this infrastructure layer is taking shape through open source.

Image Credit: OpenClaw DeepWiki

2. Hermes Agent vs OpenClaw: Local AI Agents Compared

The battle for local AI agents became one of the most interesting software stories of 2026. After OpenClaw, Nous Research introduced Hermes Agent – another local agent that develops skills. Our article compares OpenClaw and Hermes Agent, because they are built around very different philosophies:

• OpenClaw focuses on user control, file-backed identity, and human-authored skills.

• Hermes strengths is self-improvement, procedural layered memory, and skills generated from experience. the more you use the agent, the more useful it becomes. the longer they run.

In general, local agents are starting to remember methods as well as facts. But the two agents confront in one particular point: should personal agents be controlled or allowed to learn?

3. Gemma 4 with OpenClaw: Architecture, Setup, and Why Developers Are Switching

Gemma 4 feels built for the local-agent moment. Google DeepMind optimized it for intelligence per parameter: smaller active compute, efficient attention, multimodality, structured outputs, function calling, and models that can actually run on devices. The article connects this directly to OpenClaw, where users want strong local agents without Claude-level API bills. The interesting tension is practical: Gemma 4 looks like the new default model to try first, but harder agentic workflows may still need tuning or fallback models. In 2026, local AI becomes less theoretical and much more usable.

Image Credit: A Visual Guide to Gemma 4 by Maarten Grootendorst

4. What Is Skill Engineering? From Prompt Optimization to Skill Optimization

Since personal agents like OpenClaw and Hermes Agent are the frontier of 2026, skill engineering is becoming a very important layer of agent optimization after prompt and context engineering. These agents rely more on reusable skills, so the main question is: “how do we train, maintain, and optimize the skills themselves?” There are three fresh methods: SkillOpt for improving one skill through validated edits, SkillOps for cleaning and maintaining whole skill libraries, and SkillMOO for finding cost-effective skill bundles for coding agents. And further there will be more of them.

Image Credit: SkillOpt original paper

5. VLA Models Explained: Architecture, Types & the Leap to VLA+

Vision-Language-Action (VLA) models are becoming the core interface for Physical AI: they connect what robots see, what humans ask, and what the robot actually does. This piece maps the landscape from Gemini Robotics and π0 to SmolVLA, Helix, ChatVLA-2, ACoT-VLA, VLA-0, and Microsoft’s new Rho-alpha. Rho-alpha is special here, because it illustrates the shift to VLA+:  models that add touch, online learning, and real-time human correction. VLAs are very important now because they influence robotics progress, moving them beyond fixed programs toward systems that can perceive, reason, adapt, and keep improving after deployment. 

Image Credit: Helix: A Vision-Language-Action Model for Generalist Humanoid Control blog post

6. Nemotron 3 and the Surprising Coalition Building New AI in the Open

Nemotron 3 is NVIDIA’s sensational development to build an open AI ecosystem around shared infrastructure. From the technology side it offers: a hybrid Transformer–Mamba architecture, LatentMoE routing, multi-token prediction, and NVFP4 training. But even more interesting is who build these parts. NVIDIA gathered a coalition including Mistral, Cursor, Perplexity, LangChain, Black Forest Labs, and others, contributing models, data, evaluations, tooling, and domain expertise Frontier AI development can be even more modular than we thought. Maybe AI ecosystems and collaboration of developers will drive the progress?

Image Credit: NVIDIA

7. What are Web World Models? 

Web World Models (WWM) offer a practical recipe for building persistent worlds for AI agents using standard web infrastructure. WWMs split the system in two parts: deterministic code handles rules, state, and “physics,” while language models add descriptions, narratives, and high-level content. Moreover, worlds can stay consistent without storing everything, using typed interfaces, hashing, and graceful fallbacks when the model is slow or unavailable. As agents need stable environments to act, remember, fail, and learn WWMs are one of the options.

Image Credit: Web World Models original paper

8. What is Recursive Self-Improvement?

A recent hot topic is Recursive Self-Improvement that moved from science-fiction thought experiment to a real research direction in 2026. Simply, it’s the process when AI builds better AI itself. The article follows three complementary paths:

• Sakana AI’s long-term vision of AI-driven research loops

• Anthropic’s use of Claude to automate coding and engineering work

• Recursive’s system for running, evaluating, and combining AI-generated experiments.

And the results are very, very interesting. Claude now writes more than 80% of Anthropic’s merged code, while Recursive discovered enough small optimizations to cut training times and improve model quality automatically.

Image Credit: Turing Post

9. How Responsible AI Changes In The Agent Era

And finally, Responsible AI became much more tangible in the agent era. When AI systems move from generating text to taking actions through tools, APIs, and workflows, safety can no longer rely on output review alone. In this article, we discuss how Microsoft and Google DeepMind are turning Responsible AI into idnfrastructure with runtime controls, policy-as-tests, human oversight with monitoring, etc. Now it is even more obvious that agents need guardrails around what they can access and do. Trust is becoming an engineering problem.

Image Credit: Turing Post

💸 How to Cut the Trust Tax of Evaluating AI Agents at Scale

Free guide from our partners

Evaluating agents with external LLMs looks affordable. Until your agent traffic grows. Fiddler’s guide breaks down how to reduce Total Cost of Ownership while eliminating risk gaps in production.

Learn how to:

• Evaluate every trace without sampling

• Evaluate agents in-environment with batteries-included Trust Models

• Reduce API costs at scale

Share Turing Post with one person. You will help us grow

What People Still Don’t Understand About AI Agents and Tools

During a Q&A with Kimberly Powell at the BIO AI Summit, where NVIDIA announced that they had open-sourced their BioNeMo Agent Toolkit, I heard a couple of questions from journalists who write about AI that made me see red. How much do you need to misunderstand the whole thing to ask something like that?

Then I calmed myself down and remembered: there are no dumb questions. There are signals.

And this one was a very useful signal. It showed how many people, including people who write about AI for a living, still don’t understand what agents are, what tools are, and what happens when you connect the two.

So let’s bring clarity to the world. Small mission, no pressure.

The question was basically this: if Claude refuses to help someone create a bioweapon, doesn’t a scientific toolkit now give it a deep knowledge that can help with that?

Bioweapons are a legitimate safety topic. Nobody should wave that away. But the question revealed a layer mistake. It assumed that NVIDIA had given models new dangerous scientific knowledge.

And this is a fundamental misunderstanding of what a toolkit is.

What is BioNeMo? BioNeMo Agent Toolkit is NVIDIA’s collection of scientific models, tools, and workflows that AI agents can call for life-sciences tasks. Clear enough – except it’s not.

BioNeMo is much closer to giving a scientist access to laboratory equipment than teaching them biology. Or even simpler: it is like giving someone a bicycle repair kit. A screwdriver screws and unscrews screws (try to say it out loud). A wrench tightens bolts. A pump puts air into the tire. A patch covers a puncture. Can you make a bomb from this bicycle with a screwdriver or a patch? That’s not impossible! But it requires much more than that.

A toolkit gives you specific tools for specific jobs.

That is the simplest way to understand what NVIDIA announced. BioNeMo Agent Toolkit packages life-sciences tools and models into agent-callable skills: protein folding, molecular docking, generative chemistry, genomics analysis, protein design, biomarker discovery, and related workflows.

And that means exactly that: AI agents can now call scientific instruments.

There was another question that kinda surprised me: how it was possible that OpenAI and Anthropic/Claude – both presented as models that the toolkit can use – agreed to collaborate.

Well, they don’t, they don’t need to, and that’s quite obvious when you know – again – what a toolkit is.

What makes this an agent toolkit, not just a pile of models?

Because the agent can chain the tools and models.

Example: design a protein binder

A scientist says: “Find a possible binder for this target protein.”

The agent does not magically “become a biologist.” It follows a workflow:

1. Use RFdiffusion model to design possible binder backbones.

2. Use ProteinMPNN model to propose amino-acid sequences for those backbones.

3. Use Boltz-2 or OpenFold3 models to predict whether the binder and target actually fold together.

4. Rank candidates using confidence and interface metrics.

5. Return the best candidates to the scientist with caveats.

The BioNeMo repo even includes a generative protein binder workflow that combines RFdiffusion, ProteinMPNN, and Boltz-2 / OpenFold3 for this kind of sequence: backbones → sequences → co-fold → filter. Like a set of skills an agent might require.

Why is it so important to understand?

As we plunge headfirst into this new agentic era, a basic understanding of it becomes crucially important. Because understanding this distinction changes how we view the future of AI – shifting the focus from what AI knows to what AI can do.

If we go back to biotech and BioNeMo, the difference will be this: A chatbot can explain molecular docking. If you casually ask about it. An agent with the right tool can run a docking workflow. It’s less about learning and more about building. You need to know some stuff by then. A chatbot can describe protein design. An agent with the right workflow can generate a protein backbone, propose an amino-acid sequence, predict whether it might fold, inspect the output, and bring the result back to a human scientist.

Scientist is the key word here.

And this is where many people still get lost. They keep looking at the model as if the model is the whole story. It’s not.

Which model is smarter? It’s a good question but not the most interesting. The better question now is: where does the model act?

Inside a codebase? Inside GitHub? Inside a lab? Inside a medical scanner? Inside a drug-discovery workflow? Inside a system that repeatedly measures, tests, adjusts, and improves? Once AI starts acting, the valuable layer is the loop around the model.

And science is full of loops.

Drug discovery, protein design, genomics, biomarker discovery, clinical research, medical imaging, literature review, protocol generation: these are not fields where progress usually arrives as one clean eureka moment. Much of the work is iteration. That is why having agents and tools for agents is so exciting. They can help the scientist move through the loop faster. I’m on my own loop to keep repeating that.

There was a fascinating point in the BioNeMo discussion: early dreams of AI for science imagined that models could simply consume all scientific knowledge, connect all the dots, and discoveries would just pop out. But that is not really how it worked. The real progress came when systems entered the loop: look at the literature, propose an experiment, analyze the data, then use that result to propose the next experiment.

It’s happening right now, though the majority of people still don’t realize that. That’s one of my biggest revelations from BIO AI Summit: we are at the beginning of agentic science.

And yes, it should make us excited.

Because a lot of scientists spend far too little time doing science. If agents can compress some of that engineering and operational work, they give scientists something precious back: more time in the creative scientific space. More time looking at data. More time asking the next question. More time noticing that something unexpected happened and following it. What does it give to the rest of us? The ability to cure diseases much faster. Feels like it’s even better than a new productivity tool.

This is why BioNeMo is not only a biotech story. It is part of the bigger shift I keep coming back to: the model is no longer the whole story. The loop around the model is becoming the interesting layer.

I talked about exactly this in my solo segment for O’Reilly’s This Week in AI this week: who owns the loop? In coding, in cybersecurity, in medicine, in science, the same question keeps appearing. Where does the model act? Who controls the tools? Who owns the feedback? Who decides when the loop is safe enough to run? Check it out→

If any of those thoughts resonate with you – share them across your social networks. Let’s keep the conversation going.

We are reading / watching

• Hotter Than a Hot Tub: The 45°C Breakthrough to Cool AI’s Biggest Machines by NVIDIA is a very interesting article about liquid cooling, how it can enable zero water consumption, and how waste heat from AI infrastructure could potentially be shared with residential buildings.

• How Chinese Researchers Plan to Build Self-Improving AI by Recode China AI

• Responsible AI in the Age of AI Agents

Twitter Library

News from the usual suspects ™

• Midjourney announced Midjourney Medical, a full-body underwater ultrasound scanner concept that aims to make internal imaging faster, more repeatable, and more consumer-friendly. It’s also stunningly beautiful.

• SpaceX’s news:

  • They agreed to buy Anysphere, the company behind Cursor, for $60B in stock, turning the coding-agent race into a fight over the developer workflow itself.

  • SpaceX also disclosed a compute-capacity deal with Reflection AI worth up to $6.3B, making its AI-infrastructure ambitions look much bigger than Cursor alone. In March, we interviewed Reflection’s co-founder. Worth taking a look.

• Anthropic’s news

  • They launched Claude Tag in Slack, letting Claude be summoned in group conversations to read context, break down tasks, and follow workplace threads like an AI teammate. Sad to see Andrej Karpathy as Anthropic’s new promo platform.

  • Micron signed a strategic infrastructure agreement with Anthropic to supply memory and storage products, adding memory supply to the list of bottlenecks in frontier AI scaling

• OpenAI’s news:

  • Their LifeSciBench tests models on real life-science work with 750 expert-authored tasks, 1,062 artifacts, 173 scientist contributors, and more than 19,000 rubric criteria.

  • OpenAI and Molecule.one demonstrated a near-autonomous AI chemist that improved Chan-Lam coupling, a drug-chemistry reaction for forming carbon-nitrogen bonds.

• NVIDIA’s news

  • NVIDIA introduced BioNeMo that we discussed above.

  • They also introduced new AI-for-science software at ISC, including DAQIRI and ALCHEMI NIM microservices for scientific pipelines from astronomy to chemistry and materials simulation

Survey highlight

World Action Models: A Survey by National University of Singapore

Image Credit: The original paper

This survey conceptualizes World Action Models (WAMs) as embodied predictive-action systems that integrate future forecasting directly into the action path. WAMs unify Vision-Language-Action policies with predictive world models. The authors structure the field into three primary design philosophies: Render-and-Decode, Latent-Only, and Video-Generation-Free. Finally, the taxonomy evaluates critical trade-offs balancing representational richness against compute, memory, latency, and physical plausibility. The field is moving toward generating less of the future while preserving control requirements.

Models

• Z.ai released GLM-5.2, a major Chinese open-weight coding model with a 1M-token context window and MIT license, putting open Chinese models back into the U.S. AI anxiety machine.

• Sakana AI released Fugu and Fugu Ultra, an orchestration-model family that routes tasks across a swappable pool of models behind one API.

• DreamX-World 1.0 – builds toward interactive general-purpose world models instead of passive video generators →read the paper

• Qwen-RobotWorld Technical Report – connects embodied world modeling with language-conditioned video generation for robotics →read the paper

• PAIWorld – proposes a 3D-consistent world foundation model for robotic manipulation →read the paper

• BioMatrix – expands biological foundation models across sequences, structures, and language →read the paper

• VibeThinker-3B – pushes verifiable reasoning into small language models, which matters because reasoning cannot only live in giant expensive systems →read the paper

• Sumi – develops an open diffusion language model from scratch, useful as diffusion LMs become less fringe and more serious →read the paper

Research

Trends we see looking at every paper related to AI and ML published last week:

• World models are becoming agent infrastructure, not video generators.

• Agents are learning to manage their own memory and improve themselves.

• Reasoning is shifting toward reflection, verification, and active perception.

• Robotics and foundation models are rapidly converging.

• Researchers are experimenting beyond standard transformer architectures.

• Open models are entering a new governance and capability-control phase.

World models, robotics, and physical agents

• Looped World Models – introduces iterative latent refinement as a new scaling axis for long-horizon world simulation →read the paper

• Kairos: A Native World Model Stack for Physical AI – frames world modeling as a full stack for physical agents that learn, maintain, and act →read the paper

• Current World Models Lack a Persistent State Core – identifies persistent internal state as the missing piece in current world-model systems →read the paper

• 🌟 ImageWAM – questions whether world action models really need video generation or whether image editing can capture enough dynamics →read the paper

• Geometric Action Model for Robot Policy Learning – grounds robot policy learning in geometric structure instead of plain imitation →read the paper

• Foresight – detects long-horizon robot manipulation failures using action-conditioned world-model latents →read the paper

• ENPIRE – demonstrates real-world robot policy self-improvement through agentic learning loops →read the paper

• PoLAR – factorizes latent actions to make robot policies more transferable and controllable →read the paper

Agent systems, memory, and self-improvement

• DataClaw0 – turns raw multimodal streams into task-ready data through agentic data tailoringv→read the paper

• OpenRath – gives agent systems a session-centered runtime state for replay, branching, memory, and tool evidence →read the paper

• Self-Compacting Language Model Agents – lets agents compress their own context before long-running memory becomes soup →read the paper

• 🌟 EvoEmbedding – makes retrieval representations evolve with long-context memory and agent usev→read the paper

• Connect the Dots – trains long-lifecycle agents to learn across tasks through reinforcement learning →read the paper

• OPD-Evolver – evolves agents through on-policy distillation instead of static post-training →read the paper

• CalVerT – adds calibrated verifier telemetry so agents can decide when to act, retrieve, stop, or distrust themselves →read the paper

• 🌟 Training Open Models for Agentic Phone Use – builds open agents for real phone interfaces, not just toy GUI tasks →read the paper

• FAPO – automates prompt optimization across multi-step LLM pipelines →read the paper

Reasoning, perception, and learning loops

• 🌟 Learning from Your Own Mistakes – constructs micro-reflective trajectories for self-distillation and reasoning improvement →read the paper

• 🌟 Learning from the Self-future – teaches diffusion language models from their own future trajectories →read the paper

• Zone of Proximal Policy Optimization – moves supervision from gradients into prompts through teacher-guided optimization →read the paper

• Native Active Perception as Reasoning for Omni-Modal Understanding – treats perception as an active reasoning process, not just input processing →read the paper

• S-Agent – shows how spatial tool use can elicit stronger spatial reasoning →read the paper

Architecture and efficient scaling

• Variable-Width Transformers – explores adaptive-width computation as a scaling path beyond fixed transformer blocks. →read the paper

• Grouped Query Experts – applies mixture-of-experts routing inside grouped-query attention. →read the paper

• HydraHead – studies head-level specialization and hybrid attention, useful for understanding where transformer efficiency actually comes from. →read the paper

• Tapered Language Models – questions uniform transformer width and explores models whose width changes across depth. →read the paper

• Deeper is Not Always Better – reduces alignment tax through confident layer decoding instead of always using the full model depth. →read the paper

Safety, release strategy, and conceptual direction

• Toward Open Weight Models Without Risks – proposes separating public and private capabilities inside open-weight model releases. →read the paper

• Causal Discovery in the Era of Agents – argues agents can assist causal workflows, but only if causal claims are constrained instead of hallucinated. →read the paperThat’s all for today. Thank you for reading! Please send this newsletter to colleagues if it can help them enhance their understanding of AI and stay ahead of the curve.

⬅️ FOD 156: What is the harder human-capital problem beneath token capital?

This week saw a renewed wave of interest in reinforcement learning (RL) for AI agents, especially with GRPO. So we thought it would be useful to bring together the most relevant open-source tools that anyone can use to build, train, and optimize their own agents.

TL;DR: Agent RL training frameworks help improve AI agents through trajectories, rewards, tool use, and environment interaction. Some focus on GRPO and RLHF, others on scalable rollouts, multi-turn agents, long-horizon tasks, or multi-agent workflows. The choice depends on your agent stack. →

Agent RL Training Frameworks Compared

1.OpenPipe ART (Agent Reinforcement Trainer)

An agent reinforcement trainer that trains multi-step agents through experience and environment interaction via GRPO. Your app defines the task and reward, and ART handles the RL loop: inference, trajectory scoring, GRPO optimization, checkpointing and LoRA updates.

• When to use: A good option if you want an ergonomic agent-first GRPO harness rather than a generic RLHF stack. It's useful for multi-step tasks like tool use, email search, MCP, games and reasoning workflows

• ART GitHub

2. verl-agent

An agent RL framework that is an extension of ByteDance’s veRL (Volcano Engine RL) – RL training library for post-training LLMs that supports PPO, GRPO, DAPO, RLOO and REINFORCE++ algorithms. But verl-agent is made for training multi-step LLM agents. It uses step-wise agent-environment interaction with customizable memory and per-step inputs.

• When to use: Choose this framework if you're training agents that take many actions like web browsing, tool use, search, GUI automation, or embodied tasks and when you need highly scalable long-horizon training and optimization.

• verl-agent GitHub

• veRL GitHub

3. Agent Lightning

Trains AI agents via RL without rewriting the agent itself. This tool from Microsoft works with popular agent frameworks such as LangChain, OpenAI Agents SDK, AutoGen, CrewAI, and Microsoft Agent Framework, collecting trajectories and optimizing prompts or policies through RL, SFT, and other methods.

• When to use: Good if you want to improve an existing agent with RL without rebuilding your stack. Works for both single-agent and multi-agent systems.

• Agent Lightning GitHub

4. Unsloth

A local UI for running, fine-tuning, and RL-training LLMs, VLMs, audio, and embedding models. It combines inference, dataset creation, fine-tuning, GRPO-based reinforcement learning, model export, and monitoring in a single interface while reducing training memory requirements through custom kernels and optimizations.

Unsloth is primarily a model training toolkit, but it can train agent models using RL algorithms such as GRPO and supports tool calling, long-context RL, and multimodal agents.

• When to use: It's especially useful for LoRA fine-tuning, GRPO/RL training, dataset preparation, and experimenting with models on consumer GPUs or Apple Silicon. A good choice if you want an easy way to run and train open models

• Unsloth Github

5. OpenRLHF

A high-performance RLHF (Reinforcement Learning from Human Feedback) framework built around Ray, vLLM, and DeepSpeed. It supports PPO, GRPO, REINFORCE++, RLOO, reward modeling, and both single-turn and multi-turn agent training through a unified agent-based execution pipeline.

• When to use: Good if you need a scalable RLHF or agent-training stack for large models. It's particularly useful for distributed RL training, custom reward functions, multi-turn agents, and production-scale workloads using Ray and vLLM.

• OpenRLHF Github

6. SkyRL

A modular full-stack RL framework for LLMs that combines training, inference, agent training, and RL environments in a single ecosystem. It includes components for RL training (SkyRL), long-horizon agent optimization (SkyRL-Agent), and Gymnasium-based environments (SkyRL-Gym).

• When to use: Good if you want an end-to-end stack for training and evaluating tool-using especially good for long-horizon agent RL, multi-turn workflows, SWE-Bench-style tasks, and building custom environments with Gymnasium.

• SkyRL Github

7. NVIDIA’s Polar

This one is technically a rollout system, but it’s interesting in this list because it turns existing agent harnesses into RL-ready environments without code changes. It provides rollout orchestration, trajectory construction, evaluation, and scalable distributed execution through a server-based architecture.

• When to use: Polar is useful if you already have an agent system and need scalable rollouts for RL training, especially for multi-step tasks and integration with trainers like Slime, verl, or NeMoRL.

• Polar GitHub

8. Agent-R1

Trains multi-step LLM agents, treating each agent action as a step-level MDP (Markov Decision Process) transition. It explicitly models observations, actions, tool feedback, rewards, and environment state rather than optimizing a single growing prompt.

• When to use: Good if you're training tool-using or environment-interacting agents with multi-step reasoning.

• Agent-R1 GitHub

9. RAGEN

Built around the StarPO algorithm, it optimizes full reasoning-and-action trajectories. It includes built-in environments (WebShop, SearchQA, DeepCoder, Lean, Sudoku, Sokoban) and diagnostics for analyzing agent RL failure modes like reasoning collapse and poor reward quality.

• When to use: Use it when you want to understand why RL training succeeds or fails and when you need multi-turn agent training and trajectory-level optimization.

• RAGEN GitHub

10. Marti

A multi-agent RL training framework which supports graph-based agent workflows – debate, chain-of-agents, and mixture-of-agents, combining centralized coordination with distributed policy training across multiple agents.

• When to use: Good for tree-search-based RL, agent reasoning, code generation, debate-style workflows, and heterogeneous agent teams.

• Marti GitHub

Don’t forget to check out our in-depth guides on reinforcement learning and GRPO to pick up with the basics and advanced approaches. You may find it helpful!

• Reinforcement Learning: The Ultimate Guide to Past, Present, and Future

• GRPO Explained: Group Relative Policy Optimization

FAQ

What is an agent RL training framework?

An agent RL training framework is a tool for improving AI agents with reinforcement learning. It usually collects trajectories, scores actions or outcomes with rewards, and updates the model, policy, prompt, LoRA adapter, or agent behavior based on task performance.

When should you use agent RL instead of supervised fine-tuning?

Use agent RL when the task depends on multi-step behavior, tool calls, environment feedback, or final outcomes that are easier to reward than imitate. Supervised fine-tuning is better when you already have high-quality examples of the exact behavior you want.

What is the difference between RLHF and agent RL?

RLHF usually aligns model responses with human preferences, often in single-turn or dialogue settings. Agent RL trains behavior across multi-step trajectories, where the model may call tools, observe results, update memory, retry actions, and optimize for task success over time.

Which agent RL framework should you choose?

Choose ART or Unsloth for accessible GRPO-style experimentation, verl-agent or OpenRLHF for scalable training, Agent Lightning if you already use an agent framework, Polar for rollouts, RAGEN for diagnostics, SkyRL for full-stack environments, and Marti for multi-agent workflows.

Why do agent RL frameworks matter?

They matter because agents are no longer just chatbots. They browse, code, search, use tools, control environments, and collaborate with other agents. Training these systems requires feedback from complete trajectories, not only isolated prompt-response pairs.

For a long time, Responsible AI sounded like something from a theory field, important but safely distant from the actual race. Almost boring. But now with agents that act, write code, touch tools, and cross organizational boundaries, Responsible AI becomes part of infrastructure. And much more exciting. It is about who gets access, where the system is allowed to act, how policies become tests, and how humans stay responsible when machines move faster than our old review processes. And here is another important shift: this work cannot be done in isolation. One company, or even one country, can create its own rules for safety and alignment, but agents will live in a connected world. So Responsible AI has to become a shared effort, and we need to talk about it more to encourage all players to build that safety net together.

In this article, we’ll look at why Responsible AI changed now, what it meant before agents, why Microsoft is turning Responsible AI into developer infrastructure, why Google DeepMind’s latest announcement treats agent safety as a security problem, and what all of this means for the next phase of AI systems.

What’s in today’s episode?

• Why Responsible AI matters more in the age of AI agents

• So, what is Responsible AI actually trying to do?

• Before agents, what was Responsible AI built around?

• First, stop pretending trust is universal

• Who is responsible when everyone is involved?

• Microsoft’s Responsible AI approach: from policy to runtime

• Google DeepMind’s AI control roadmap: alignment is not enough

• Where does the human go when work moves at machine speed?

• What should not be delegated to agents?

• Is Responsible AI a silver bullet?

• What does Responsible AI unlock?

• Concluding thoughts: What does Responsible AI unlock?

Why Responsible AI matters more in the age of AI agents

When AI was mostly a chat interface, the model generated an answer and the human decided what to do with it. There was still risk, especially in high-stakes contexts, but there was also a built-in pause. It was manageable: a person could read the output, compare it with other sources, reject it, edit it, or ignore it. Many people did not do that carefully enough, but the interaction still had a forgiving shape.

Agents that act on your behalf change that shape. Once an AI system can call tools, cross into files, operate through APIs, and perform multi-step workflows, the output may become action. That is a fundamental difference.

Sarah Bird, Chief Product Officer of Responsible AI at Microsoft, who I chatted with recently, described this shift through pace and workflow. She says that the first thing that changed is the speed of capability jumps. “Every month or a couple months, we’re seeing kind of a major leap in capability,” she told me. That is exciting because it opens new applications, but it also means that Responsible AI has to keep developing tools for new surfaces of risk. The example most on her mind was agentic coding, because it touches the software development lifecycle that much of Responsible AI practice was built around. If agents write code and agents review code, then a traditional human review step that takes three days can feel absurd in a workflow where the work itself took two hours. The need for validation remains, but the old placement of validation starts to break.

This is the moment Responsible AI became a question of control around action.

Google DeepMind’s latest announcement points in the same direction from another angle. On June 18, 2026, DeepMind published “Securing the future of AI agents,” introducing an AI Control Roadmap for internal agents. In that blog, Google explicitly says this approach goes beyond traditional model alignment by adding system-level security, so there is still assurance even when alignment is imperfect. In plain language: do not assume that a well-trained model will always understand the goal, preserve the right boundary, resist manipulation, or behave safely once it has access to tools and permissions. Build as if the agent may go wrong.

That is the new phase. Responsible AI should consider the whole system to act safely. And it’s brutally hard.

Recently, I chat with Sarah Bird who is CPO of Responsible AI at Microsoft. It was insightful (don’t worry, there is no corporate fluff) and if you are interested in the topic, I encourage you to check our this interview →

The article below has a wider perspective including recent news from Google →

So, what is Responsible AI actually trying to do?

At its simplest, Responsible AI is the attempt to make AI systems useful without making them reckless, unfair, opaque, unsafe, or impossible to hold accountable. But that is a definition from an ideal world, and the actual field is messier. Increasingly, Responsible AI has to borrow from AI ethics, safety, security, governance, human rights, product design, law, risk management, philosophy, and ordinary software engineering. It is not a single discipline. It is a collision zone.

The older vocabulary was built around principles: fairness, reliability, safety, privacy, security, inclusiveness, transparency, and accountability. They gave companies, researchers, and regulators a way to name the harms that AI systems could create or amplify. Then came attempts to operationalize them through risk assessments, launch reviews, documentation, red-teaming, model cards, evals, incident response, and regulation.

NIST’s AI Risk Management Framework, released in January 2023, framed this movement in terms of managing risks for organizations that design, develop, deploy, or use AI systems, and it was intended to promote trustworthy and responsible AI development and use. The EU AI Act, which entered into force on August 1, 2024, made the regulatory version more concrete through a risk-based framework for developers and deployers of AI systems in Europe.

Those frameworks are necessary, but in the agentic era they begin to show their limits. Principles define the goal, regulations define the obligations, reviews check whether a system appears ready. But none of these, by themselves, can interrupt a bad tool call, notice that an agent is overreaching, or prevent a workflow from crossing a boundary it should not cross.

Responsible AI is moving from principles and output review to agent controls, runtime monitoring, and system-level accountability.

So the field is becoming more technical. The goal is no longer only to state responsible behavior, now you have to make that behavior testable, enforceable, observable, and adjustable.

That was my little revelation: Responsible AI, which had always sounded more like a slogan to me, suddenly stopped being abstract. It became a stack, a layer of infrastructure.

Before agents, what was Responsible AI built around?

Before agents, much of Responsible AI was built around the assumption that humans and software moved at human and software speeds. A product team planned a feature, engineers built it, reviewers assessed it, safety teams tested it, lawyers and policy teams weighed in, and the system moved through some version of a launch process. The process was imperfect, but it had a cadence.

Generative AI already strained that cadence because model behavior was probabilistic and hard to inspect. Agents strain it further because they do not only generate outputs; they create workflows. An agent can call a tool, receive a result, update its plan, call another tool, and continue the chain. Each step may look reasonable in isolation while the whole sequence drifts away from the intended goal.

In our conversation, Sarah said that at one level, the Responsible AI work has not changed. Teams are still testing, still building guardrails, still thinking about human oversight, still trying to understand risk. At another level, everything has changed because the software development lifecycle itself is being rewritten by AI. Her team now spends more time than expected on automated risk detection and scanning, using coding tools and code-understanding tools to inspect systems directly instead of asking engineers to fill out forms describing what is happening.

That last part matters. Forms were always a weak interface between governance and reality. The code knows more. The traces know more. Tool calls know more. Runtime behavior knows more. If Responsible AI needs to operate at machine speed, it has to read the machine, not only the questionnaire.

Sarah described Responsible AI work as co-innovation across many domains: model training, post-training, low-latency systems, large-scale engineering, applied science, linguistics, legal, and policy. “You can’t just say, oh, we’ll throw technology at this problem and solve it, or we’ll just make a policy and that solves the problem,” she said. That is the whole point. Responsible AI can no longer be the policy department waiting outside the engineering room. It has to be inside the system design.

First, stop pretending trust is universal

The most important moment in my conversation with Sarah came when I asked the question that bothered me: is it even possible to make AI responsible?

She immediately corrected the frame. “It’s actually not about making AI responsible,” she said. “Ultimately humans should be responsible.” The work, in her view, is about making AI trustworthy, and even that word needs care. “You don’t just make an AI system generically trustworthy,” she said. You might trust a system to generate a paragraph that you will edit, but you might not trust it to make clinical healthcare decisions. Trust depends on how the system was built, where it is used, what role the human plays, and whether the tool is actually fit for purpose.

This sounds obvious until you look at how people actually use AI. A benchmark score or a brand name often becomes a vague permission slip. The model feels smart, so the user trusts it. The interface looks polished, so the organization assumes it is safe. The tool works in a demo, so someone quietly moves it into a workflow where the stakes are higher than the demo ever admitted.

Responsible AI has to break that spell. The serious question is not “Can I trust AI?” but “Can I trust this system, for this task, with this access, in this context, under these consequences?”

And context includes you too: your expertise, your attention, your incentives, and yes, even the level of alcohol in your blood at that moment. Basically, the same questions you should ask before using a chainsaw. It is a power tool. So is AI. The fact that it can help you build faster does not mean you should pick it up casually, distracted, overconfident, or without understanding what it can cut.

That is why “fit for purpose” is not a boring compliance phrase. It is the practical core of trust. A model can be useful for drafting and unsafe for diagnosis. It can be appropriate for rapid prototyping and inappropriate for silent production deployment. It can be fine with public information and wrong for confidential enterprise data. It can suggest an action without being allowed to execute it.

Sarah made this point when talking about ordinary users. People need to understand whether a tool is appropriate for the job, what guarantees the provider gives, and whether those guarantees match the data and context. A consumer tool that uses data to train future models may be useful for some personal experiments and completely inappropriate for enterprise data. Another tool may provide stronger privacy guarantees and be appropriate for a different setting.

This is also why the instinct to “just fix it in the model” is tempting, but incomplete. General-purpose models are valuable precisely because the same capability may be legitimate in one context and dangerous in another. Sarah gave a telling example: her own team generates harmful content to train monitoring systems and guardrails, which means that a capability many people would prefer to remove entirely can also be necessary for defensive and safety work.

This is where Responsible AI becomes a stack rather than a slogan.

Who is responsible when everyone is involved?

Well, everyone has a role, but not the same role. Sorry, if that is less emotionally satisfying than blaming one company, one model, one user, or one regulator, but it is closer to how AI systems actually reach the world.

The model provider may be responsible for testing whether the model introduces novel dangerous capabilities. The platform provider may need to provide usable controls. The application developer has the specific context to test whether an AI system works safely in a banking app, a healthcare product, an education tool, or a coding workflow. The deploying organization has to decide whether the system is appropriate for its data, people, and stakes. The user still has responsibility for understanding what kind of tool they are using, especially around privacy, verification, and over-delegation. Regulators codify what society is not willing to leave to private judgment.

This stack is not neat, and it will be contested. But it is the only realistic alternative to the fantasy that responsibility can be solved at one layer. If you fix only the model, you miss the application context. If you fix only the application, you inherit model-level risks. If you rely only on regulation, you move too slowly for the current pace of system design. If you rely only on users, you turn every person into an unpaid safety engineer.

And another problem: Agents will not stay inside one company’s neat little garden. They will cross apps, workflows, platforms, and organizations. Google DeepMind made the same point in its June multi-agent safety call: millions of agents from different builders may soon communicate, negotiate, and transact across digital environments. Safety cannot depend on one vendor’s internal policy.

If agents become the new interface between organizations, trust has to travel with them. That’s has much less attention than AGI talk, but that’s exactly what will decide whether agentic systems work in the real economy.

Let’s see what are two giants offer as their solution (or part of it) →

← Previous: GitHub’s Mario Rodriguez on AI Coding Agents, Copilot, and the Future of Developers 

When we started seeing Recursive Self-Improvement (RSI) show up more often, it felt familiar: like the early days of reasoning models, test-time scaling, and the reinforcement learning wave, when an old idea suddenly became the next research frontier.

This time, the direction is AI that builds AI.

So what is Recursive Self-Improvement?

At its core, it is the idea that AI can participate in its own development. Instead of only helping researchers write code or analyze results, the system becomes part of the research loop itself: proposing ideas, running experiments, evaluating outcomes, generating training data, improving components, and helping design the next iteration.

This does not make researchers irrelevant. If anything, it changes their role. As AI takes over more of the research loop, humans increasingly focus on setting goals, validating results, and governing the self-improvement process. Instead of spending time on every experiment and implementation detail, researchers can spend more time deciding which directions are worth pursuing and which results can be trusted.

But let’s ask more realistic questions: How much of the AI development loop can AI eventually handle on its own, and which parts should stay under human control?

Today we are at the very early stage of RSI. And the most outstanding steps just came from Anthropic, Recursive, and long-lasting Sakana AI’s idea to create better loops instead of wasting more compute.

Let’s discuss what they have brought and what AI can actually automate today.

In today’s episode:

• The echo of Von Neumann

• So what is recursive self-improvement, and how does it work?

• The difference between self-improving agents and RSI

• Sakana AI and the foundation for RSI

• Anthropic’s achievements in coding automation

• Recursive’s automated AI research system

• Conclusion: Where the first steps in RSI lead us

• Sources and further reading

The echo of I.J. Good and Von Neumann

As we often do, let's look backward to see where the idea is heading. Recursive self-improvement is not an invention of modern AI labs, and its clearest ancestor is not the one usually named.

The instinct is to reach for John von Neumann, who in the 1940s sketched a theory of self-reproducing automata: machines that could construct copies of themselves. His real contribution was subtler than replication. He identified a threshold of complexity below which a machine's offspring must come out simpler than its parent, and above which a machine could, in principle, build something at least as complex as itself. That threshold is the substrate the entire conversation still rests on. But Von Neumann was asking whether a machine could reproduce, not whether it could improve.

The improvement question belongs to Irving John Good. In 1965, in Speculations Concerning the First Ultraintelligent Machine, Good defined an ultraintelligent machine as one that could surpass every intellectual activity of any person – including the activity of designing machines. From there the conclusion is almost mechanical: such a machine could design a better machine, which could design a better one still, the runaway he named the intelligence explosion. Good called the first such machine the last invention humanity would ever need to make, on the condition that it stayed under our control.

RSI brings this old idea into today’s AI development loop. A model writes code that improves training infrastructure. An agent proposes experiments that improve post-training. A research system tests model changes, remembers what worked, and chooses the next branch. We are not (yet!) watching AI independently design a stronger successor from scratch. But we are already seeing the first pieces of the improvement loop move from human hands into machine hands.

So what is recursive self-improvement, and how does it work?

Before AI became part of everyday work for developers, researchers, and business teams, building software systems mostly meant writing the code, documentation, tests, and infrastructure by hand. Then AI tools became useful enough to help with small parts of these workflows, especially coding. By the end of 2025, agent capabilities had moved further: agents could edit files, work through larger tasks, use tools, and handle more steps without constant human instruction.

Today, agents can plan and execute longer tasks, improve their own outputs, and in some cases delegate work to other agents. Systems such as OpenClaw and Hermes point in this direction. But the broader ambition is bigger than workflow automation. The industry is moving toward AI systems that can help build and train future AI systems

And that seems almost impossible without, that’s right, recursive self-improvement: an AI system capable of designing and developing its own successor. Or, in the phrase that may scare a layperson: AI that builds AI.

But lay aside the doomism. RSI opens the door to a new phase of AI-powered research, one that could fundamentally accelerate progress in science and technology.

Research is a loop: propose an idea → implement it → run the experiment → validate the result → learn from it → and choose what to try next. 

Then repeat, repeat and repeat. Through numerous attempts only a couple or just one variant would really work. Or none. RSI system’s task is to automate these stages.

In an ideal version, RSI systems would operate as automated research assistants inside a closed-loop experimentation pipeline. But realistically, this is still an early-stage direction. RSI is only beginning to enter different parts of the AI development loop, and most of what exists today is post-training or workflow-level rather than foundation-model-level. The term can suggest AI systems inventing entirely new neural network architectures on their own, but current work is usually closer to automated ML engineering and automated AI research.

And there is one more clarification to make…

The difference between self-Improving agents and RSI

Before RSI became the focus of attention, researchers spent years building and exploring self-improving agents. Are these two concepts the same, since they both revolve around "self-improvement"? Actually, no.

The key technical distinction is that today’s “self-improving” agents mostly improve their workflows – prompts, tools, memory, code, and task execution – while true recursive self-improvement would improve the model-building process itself: data, architectures, training methods, evaluation, and deployment of a stronger successor.

The recursive aspect appears when the outputs of one generation of AI systems are used to create the next generation with less and less human involvement. There is the degree of recursion:

• Current systems are usually: Human → AI research assistant

• A stronger RSI system becomes: Human → AI researcher → improved AI researcher

• And the strongest form would be: AI researcher → improved AI researcher → even better AI researcher

From this perspective we can see that RSI is not a binary capability but a spectrum, and today's systems are only automating parts of the loop rather than the entire loop.

Now we’ll walk you through several most outstanding RSI variants. Read along, because you want to know about them and be ahead. From now on, RSI is on an acceleration path.

If you prefer videos, we also talk about RSI in this episode of Attention Span

What Is Token Capital? Satya Nadella's Concept Explained

The funny thing about this age of AI is that there are barely any stars who graduated from old software into this new AI world.

This thought came to me when I was reading Satya Nadella’s recent post that, at the moment of writing, had been seen by 56 million people. It’s a crucially important post, but maybe not for what’s visible on the surface. Though even that is important. It has many layers, and they may be seen better from afar.

Satya talks about token capital and human capital. Token capital is the AI capability a firm builds and owns: its models, agents, traces, evals, workflow memory, internal loops. Human capital is the judgment, taste, relationships, context, and pattern recognition of its people. His whole argument is that the two should compound, that humans grow more valuable, not less, as the machines do.

And here you can see Satya the Warrior, who can crush your skull if he needs to (in a battle, of course), suddenly sit down on a stone and turn into The Thinker. He is at the edge.

Satya Nadella as a Warrior and as The Thinker

His company is enormous, dominant, the default choice for almost every enterprise on the planet. It has Azure, Office, GitHub, the OpenAI relationship, distribution that most companies can only dream about. And still, his core warriors, maybe even the whole company, are too stiff for the shape of this moment.

That opens up the current problem: human capital is really important, but seniority no longer translates cleanly into success. If you are a star at Microsoft, inside that particular corporate structure, you are limited by so many things. Incentives. Committees. Procurement logic. Internal kingdoms. The need to sound correct before you know what is true. In a sense, human capital becomes his burden, because it wastes token capital in the wrong way.

Who made the best current models? Bold, uncorporate people, both in the US and China. And if you think about Gemini, it’s Demis, who is Ender Wiggin, playing and fighting Google’s corporate game, and Jeff Dean, who, like Chuck Norris, just looks at the model until it starts converging. They succeed not because of Google but almost in spite of it. (If you read the book The Infinity Machine, you know how long it took to merge Google Brain and DeepMind, how much brain power it wasted).

Notice what these names have in common. They are not ladder creatures. They did not become useful because they mastered the internal language of quarterly planning. They are researchers, obsessives, game players, quants, builders. Liang Wenfeng ran a hedge fund before DeepSeek. Hassabis built games and studied the brain before he taught machines to play and imagine. They came in sideways. The corporate ladder did not make them; in many places it would have sanded them down.

That is the layer underneath Satya’s post. He says human and token capital compound, and he is right. But he is too polite, or too strategic, to say which human capital. Because the kind a big company manufactures best, the senior, reliable, politically fluent veteran who knows how to move a proposal through six committees, is almost exactly the kind that can waste token capital. That person optimizes the org chart, not the loss curve.

And the kind that actually moves the frontier, irreverent, allergic to permission, willing to be loudly wrong in public, is the kind a structure like Microsoft selects against and, eventually, pushes out.

So this is my question, for corporate America: under what conditions can they hold those people without domesticating or exhausting them, Or does the age of AI reward a shape that looks less like a company and more like a band, a lab, a small huddle of fanatics pointed at one problem with infinite compute behind them?

The answer is uncomfortable because Corporate America employs more than 70 million people inside large firms alone: firms with 500 or more employees account for roughly 54% of U.S. private-sector employment. The firms with the most human capital by the old scoreboard, the most veterans, the deepest benches, the proudest org charts, may be badly positioned, because every one of those assets is also a reason not to move.

And there is another thing that I didn’t see people talking about: senior human capital is often too slow, while junior human capital is not yet deep enough. So the firm gets trapped between slow knowledge and fast ignorance.

Satya knows this. That is why he is sitting on the stone. He is not admiring his human capital. He is staring at the possibility that his greatest asset and his heaviest anchor are the same people. And if that is true, the work of the next decade is not simply accumulating human capital or token capital. It is building a structure porous enough to let uncorporate people stay uncorporate while giving them corporate-scale compute, data, distribution, and responsibility.

To keep the Demises and the Jeff Deans from being either crushed or domesticated.

The companies that learn to be that porous will own the age. The ones that keep promoting their best ladder-climbers will keep wondering why their token capital runs in circles. It might be a beginning of change for the whole corporate world. The layoffs we see are part of that.

That’s what I want to leave you with: in the age of intelligence, the scarcest capital is neither the human nor the machine. It is the structure brave enough to hold both without flattening either.

If any of those thoughts resonate with you – share them across your social networks. Let’s keep the conversation going.

We are reading / watching

• Vivek's article is an excellent example of something written with heavy AI assistance and is an absolute must-read. how to be good at research

• First Steps Toward Automated AI Research by Recursive Superintelligence

• When AI builds itself by Anthropic

and our reaction to this development in RSI

Twitter Library

Best Open-Source Vector Databases for LLMs (2026)

Milvus, Qdrant, Weaviate, Chroma, LanceDB, Faiss, pgvector, Vespa, and adjacent retrieval tools for RAG, semantic search, LLM applications, and agentic AI systems.

Turing Post • Alyona Vert.

News from the usual suspects ™

• OpenAI joined the AI IPO conveyor belt. On Jun 8, it confidentially filed for a US IPO, with a possible valuation target of up to $1 trillion and a debut that could come as early as September, though OpenAI says timing is not decided.

• xAI and SpaceX turned AI capital formation into rocket theater. SpaceX’s IPO expanded to $85.7 billion after underwriters exercised the greenshoe option, setting a new public-market benchmark for AI-adjacent infrastructure plays. At the same time, xAI faced a lawsuit from a former engineer alleging retaliation after he raised Grok safety concerns.

• Anthropic compressed an entire model-governance season into one week. On Jun 9, it released Claude Fable 5, a public Mythos-class model with high-risk cyber and bio safeguards, while keeping full Mythos 5 access for vetted Project Glasswing users. By Jun 13-15, the US government had pushed Anthropic to restrict or disable Fable/Mythos access for foreign nationals over national-security concerns, and more than 50 cyber leaders urged Washington to lift the curbs, arguing that defenders were being hurt too.

• NVIDIA and Amazon also backed Neura Robotics in a raise of up to $1.4 billion, another loud signal that physical AI and humanoids are no longer side quests.

• Amazon showed both sides of the agent economy. It secured a $17.5 billion loan facility as AI capex keeps ballooning, while a US appeals court weighed whether Perplexity’s Comet agent could violate anti-hacking law by navigating Amazon customer accounts and placing orders. That is the legal edge of agents: when software takes action, the line between user, agent, and platform gets very expensive.

• Arcee AI moved deeper into the Hugging Face stack. The two companies announced a multi-million-dollar partnership making Hugging Face the home for Arcee’s public and private models, datasets, and agent traces, using Hugging Face Buckets as private storage. That’s strategically interesting: agent traces are becoming assets, and model hubs are becoming operational infrastructure.

• Under the radar, workplace-agent research kept moving fast. WorkBench Revisited reported a jump from GPT-4’s 43% task-completion rate and 26% unintended harmful-action rate in 2024 to Claude Opus 4.8’s 89% completion and 2.5% harmful-action rate in June 2026. Agents are getting less slapstick. Not harmless, but less slapstick

Research highlight

Twitter tweet

Models

• Cohere launched North Mini Code, its first open-source model for developers. It is a 30B-parameter MoE with 3B active parameters, Apache 2.0 weights, 256K context, and a focus on code generation, terminal work, code review, and agentic software-engineering workflows.

• Embodied-R1.5: Evolving Physical Intelligence via Embodied Foundation Models – extends reasoning-style training ideas into embodied agents.

• LabVLA: Grounding Vision-Language-Action Models in Scientific Laboratories – adapts embodied systems to laboratory environments.

• Light-WAM: Efficient World Action Models with State-Fusion Action Decoding – makes world-action models substantially more efficient.

• ARM: An AutoRegressive Large Multimodal Model with Unified Discrete Representations – unifies modalities through a shared discrete representation space.

Research

Trends we see looking at every paper related to AI and ML published last week:

• Agent infrastructure

• Environment engineering

• Memory as architecture

• World models as reasoning tools

• Verification bottleneck

• Self-improving agents

Autonomous research, self-improving agents, and agent infrastructure

• Toward Generalist Autonomous Research via Hypothesis-Tree Refinement – structures research as an iterative hypothesis-building process that accumulates evidence and lessons across attempts.

• EurekAgent: Agent Environment Engineering is All You Need For Autonomous Scientific Discovery – argues that better environments, tools, and feedback loops may matter more than better agents themselves.

• Role-Agent: Bootstrapping LLM Agents via Dual-Role Evolution – trains agents by letting models alternately play the role of agent and environment.

• EvoTrainer: Co-Evolving LLM Policies and Training Harnesses for Autonomous Agentic Reinforcement Learning – co-evolves the agent and its training process rather than optimizing only the policy.

• 🌟 HarnessBridge: Learnable Bidirectional Controller for LLM Agent Harness – turns the harness itself into a trainable component that mediates interactions between agents and environments.

• 🌟 Retrospective Harness Optimization – improves agents by learning from successful and unsuccessful trajectory histories.

• EEVEE: Towards Test-time Prompt Learning in the Real World for Self-Improving Agents – adapts prompting strategies during deployment using experience gathered from previous runs.

• 🌟 Bayesian-Agent: Posterior-Guided Skill Evolution for LLM Agent Harnesses – guides skill evolution using uncertainty estimates instead of simple trial-and-error updates.

Deep research, search, and long-horizon reasoning

• SearchSwarm: Towards Delegation Intelligence in Agentic LLMs for Long-Horizon Deep Research – explores how agents can distribute research tasks across specialized sub-agents.

• 🌟 FORT-Searcher: Synthesizing Shortcut-Resistant Search Tasks for Training Deep Search Agents – creates harder search environments that discourage superficial retrieval strategies.

• InterleaveThinker: Reinforcing Agentic Interleaved Generation – alternates reasoning and action more tightly to improve multi-step problem solving.

Memory, long context, and continual information management

• 🌟 MiniMax Sparse Attention – redesigns attention to make extremely long context windows practical.

• 🌟 FlashMemory-DeepSeek-V4: Lightning Index Ultra-Long Context via Lookahead Sparse Attention – predicts future retrieval needs before decoding begins.

• End-to-End Context Compression at Scale – compresses long context into compact representations that remain useful for downstream reasoning.

• Echo-Memory: A Controlled Study of Memory in Action World Models – investigates how memory contributes to action prediction and planning.

• Attention Amnesia in Hybrid LLMs – identifies a surprising tradeoff where chain-of-thought tuning can damage long-range recall.

• One Token per Multimodal Evidence – compresses multimodal memories into extremely compact latent representations.

World models, embodied intelligence, and spatial reasoning

• 🌟 Latent Spatial Memory for Video World Models – stores persistent spatial memory directly in latent space.

• World Pilot: Steering Vision-Language-Action Models with World-Action Priors – injects predictive world knowledge into robotic action generation.

• World Model Self-Distillation – trains world models to improve themselves through self-generated supervision.

• MoVerse: Real-Time Video World Modeling with Panoramic Gaussian Scaffold – pushes world modeling toward real-time operation.

• 🌟 SpatialClaw: Rethinking Action Interface for Agentic Spatial Reasoning – replaces fixed action spaces with code-like interactions for spatial tasks.

Reinforcement learning, verification, and reasoning optimization

• 🌟 MaxProof: Scaling Mathematical Proof with Generative-Verifier RL and Population-Level Test-Time Scaling – combines generation, verification, and refinement loops for theorem proving.

• Beyond Scalar Rewards by Internalizing Reasoning into Score Distributions – replaces single reward signals with richer evaluation distributions.

• 🌟Rethinking the Divergence Regularization in LLM RL – revisits one of the core stabilization mechanisms used in RL training.

• N-GRPO: Embedding-Level Neighbor Mixing for Enhanced Policy Optimization – improves exploration by operating in representation space.

• TRACE: A Unified Rollout Budget Allocation Framework for Efficient Agentic Reinforcement Learning – allocates compute dynamically across trajectories during training.

• Demystifying Hidden-State Recurrence: Switchable Latent Reasoning with On-Policy Reinforcement Learning – explores recurrent latent reasoning as an alternative scaling direction.

Model architecture and scaling

• 🌟 Redesign Mixture-of-Experts Routers with Manifold Power Iteration – improves how MoE models decide which experts to activate.

• On Subquadratic Architectures: From Applications to Principles – synthesizes emerging approaches for breaking quadratic scaling bottlenecks.

• HYDRA-X: Native Unified Multimodal Models with Holistic Visual Tokenizers – proposes a more unified multimodal architecture.

That’s all for today. Thank you for reading! Please send this newsletter to colleagues if it can help them enhance their understanding of AI and stay ahead of the curve.

⬅️ FOD 155: Continual Learning in LLMs: Why AI Models Need Sleep

This article is part of our The Org Age of AI series, It is co-written by Will Schenk (TheFocus.AI) and Ksenia Se. Previous episodes: #1: AI Feels Powerful. So Why Is the ROI Still Missing?, #2: The Unsexy Truth of AI Adoption, #3: How to Build an AI-Native Startup from Day One, #4: There Are No AI-Native Enterprises Yet, #5: AI Workflow Patterns: The Real Unit of AI Adoption in 2026

If you need an unbiased view on your transition to becoming AI-native, you can schedule a 1-on-1 consultation with Will here. Will Schenk is a co-founder of TheFocus.AI, where he works directly with companies navigating these transitions.

What's in today's episode:

• The ladder: pipeline vs workflow vs AI flywheel

• You are already running flywheels

• The labs are spinning the biggest flywheel

• Why this reaches you on a schedule you don't control

• The review bottleneck in closed-loop AI workflows

• Three kinds of infrastructure that don't exist yet

• The flywheel runs both ways

• Which loops to close first

• The new divide: machine-speed verification

The ladder: pipeline, workflow, flywheel

In Episode #5 we drew a line between two things. A pipeline is a fixed sequence of steps  –  a cron job, a script, plumbing. Whatever branching it has is logical and mechanical, it does nothing based upon what we'd call human judgment. A workflow is a repeating sequence of decisions and actions with points along the way where a human exercises judgment. Strip the judgment out and a workflow collapses back into a pipeline. We ended on an observation that as a workflow matures, the human migrates from the middle to the edges. They set the parameters at the start and review the exceptions at the end. The middle belongs to the agent.

Imagine now that your organization has many workflows, each one having absorbed a slice of human judgment. What's the next level? What happens when you link them together, point them at a goal, and let them run?

That linked, goal-seeking system is a flywheel. It is a collection of workflows wired so the output of one becomes the input of the next, turning continuously toward an objective you defined once. A closed loop is the smallest flywheel  –  one workflow feeding itself. Link several and the flywheel gets bigger, but the machine is the same, so we'll use loop and flywheel interchangeably from here.

But what separates a flywheel from a pipeline? A pipeline repeats; a flywheel steers. And the steering wheel is measurement. The system acts, measures the result of its own action, and uses that measurement to decide the next action. Also, a flywheel has three beats, not one: generate, measure, decide what to try next  –  then generate again.

There are two ways to close that loop: one right and one wrong.

The first is to remove the human checkpoint and hope. This is how most "we deployed autonomous agents" stories begin, and how most of the embarrassing ones end. This is the wrong way.

The second is to replace the human checkpoint with a verifier  –  something that can tell a good output from a bad one without a person reading it. A test suite. A schema validation. A reconciliation against known totals. A performance metric. The human judgment does not disappear; it gets encoded once, into the verifier, instead of being exercised by hand on every run.

That distinction is the whole episode. Loops do not close because someone decides to trust the model. They close where verification has been made cheap, fast, and objective. Everywhere else, the human stays.

And notice where the human goes. A workflow moved them from the middle to the edges. A flywheel moves them up a level again  –  off the work, off the coordination between workflows, and onto the verifier itself. The judgment stays with humans.

You are already running flywheels

If this sounds futuristic, look at how software gets written this year. A modern coding agent does not just write code  –  it runs an experiment: write code, run the tests, read the failures, rewrite, run the tests again. Nobody reviews iteration three of seven. The human reviews the final diff, and increasingly, for low-stakes changes, not even that. Anthropic says the majority of its own code is now written by Claude Code. OpenAI reported in February that GPT-5.3-Codex was instrumental in building itself  –  debugging its own training runs and analyzing its own evaluation results. Generate, measure, decide, repeat. That is the shape.

And it is not a coding-only shape. Picture an ad-optimization flywheel. One workflow generates the creative  –  headline, copy, image. A second pulls performance from the ad console  –  impressions, click-through, conversions. A third reads that performance and decides the next experiment: kill the loser, scale the winner, try a new angle. Wire the three together and you have a flywheel that runs marketing experiments around the clock, with no human between iterations. The reason it can run is the same reason coding could: the ad console is a verifier. Performance is measured, not vibed. The measurement closes the loop.

Why did coding close first? Because software spent forty years building the verification infrastructure that closed loops require. Compilers reject malformed programs. Type systems catch whole categories of mistakes. Test suites encode "what good looks like" in executable form. CI runs all of it automatically on every change. When LLMs arrived, the verifier was already sitting there, waiting. Advertising has a weaker version of the same gift  –  performance numbers are objective, if noisy. The strength of the verifier is what decides whether a loop can close at all.

This is the Factory AI principle from Episode #5, now operating at full strength: the ease of training an agent on a task is proportional to how verifiable the task is. Coding was the most verifiable knowledge work on earth, so the loop closed there first.

Now run the logic over your own organization. Which of your workflows has a test suite? Which has anything resembling one? For most companies the honest answer is that the workflows have humans. The human is the verification layer  –  and the coordination layer, the thing deciding which workflow runs next and whether the whole effort is working. Which means the human is the reason the flywheel cannot spin. Remove them, and you reveal a debt nobody scoped.

The labs are closing the biggest loop of all

The most consequential closed loop being built right now is AI research itself.

The progression over the past year has been incredible. The AI Scientist project, reported in Nature in March, automates the research cycle end to end: it generates ideas, runs experiments, writes up results, and reviews its own papers. A startup literally named Recursive published results this week from a system that proposes a research idea, implements it, runs the experiment, validates the result, and uses what it learned to choose the next experiment – running many threads over long horizons, with explicit machinery to catch reward hacking before treating a gain as real. Anthropic published a piece this month titled "When AI builds itself," stating plainly that a growing share of its AI development is delegated to AI systems, and that taken far enough, the trend points toward systems that design their own successors. Jack Clark has put a number on it: roughly 60% probability of a system that can train a more powerful successor without human involvement by the end of 2028. Dean Ball's article “On Recursive Self-Improvement” from February argues that frontier labs are automating large fractions of their research operations, and that their effective workforces of agents will grow from thousands toward hundreds of thousands within a year or two.

Well, let’s not get crazy! Labs have incentives to describe their own momentum in the strongest possible terms. And they might come their earlier than others. But the organizational argument still holds. You do not really need superintelligence for the closed loop to work. You only need what is already happening: work loops closing in domains where verification is strong, plus one observation about how capability travels.

Why this reaches you on a schedule you don't control

← Previous: AI Workflow Patterns: The Real Unit of AI Adoption in 2026Next in the series. Next: We will discuss verification in detail.

Today you are probably using (or at least tried) personal AI agents like OpenClaw and Hermes Agent for your everyday workflow. They have already built a loyal following, including Jensen Huang, and their popularity is only growing. Part of what makes these agents work is reusable skills: instruction packages that define how an agent uses tools, structures workflows, makes decisions, and solves recurring tasks. Skills have become the operational core of agent behavior.

But the requirements are shifting. Improving agent performance used to come down to prompt and context engineering. That's no longer enough — skills now carry an additional layer of context and knowledge, which raises a natural question: how do you optimize the skills themselves?

Today, most skills are written by humans, generated once by an LLM, or refined through trial and error. (Hermes gestures toward something better, improving skills during use, but the broader practice remains ad hoc.) Recently, several methods have emerged to make skill self-improvement systematic: one trains individual skills, one manages the whole skill library, and one optimizes skills specifically for software engineering.

We'll break down exactly how each works, step by step, so you can apply the ideas to your own agentic workflows. Skill engineering is still early, and most people are not paying attention to it yet. We are. Let’s dive in!

In today’s episode:

• From prompt engineering to skill engineering

• Skill engineering for AI agents: what is it?

• SkillOpt: training one reusable agent skill

• Maintaining skill libraries with SkillOps

• SkillMOO: optimizing skill bundles for software engineering agents

• Conclusion: the lessons for skill engineering

• Sources and further reading

Prompt Engineering vs Context Engineering vs Skill Engineering

Let’s start from the main concepts and descriptions. Engineering in this topic means how we design the whole operating environment around the agent. And there are three layers that we can work with.

Prompt engineering

Prompt engineering is the most familiar one. It means writing a good instruction for a specific request. You tell the model what you want, maybe give it a role, constraints, examples, formatting rules, and success criteria. For example: “Summarize this paper in simple language, focus on the method, and give me five main takeaways.”

The main feature: prompt engineering is usually local and moment-specific, because it helps the model perform one task better right now.

However, a great instruction can’t compensate for missing context. A prompt can be perfectly written, but if the model does not have the right documents, tools, memory, or task state, it will still fail. That brings us to the second layer.

Context engineering

Context engineering is about assembling the right environment around the model at runtime. It includes the system message, tool descriptions, retrieved documents, memory, examples, current task state, previous actions, constraints, permissions, and sometimes even the model’s budget for tokens, time, or tool calls.

In other words, it is a creation of basic context that a model or an agent should know and have access to when it acts or responses. And this context is what you should need to optimize, because:

• Different agents need different context, like a coding agent needs the relevant files, tests, issue description, repo structure, and a research agent needs papers, citations, hypotheses, notes and experiment results.

• Too little context makes the agent guess, while too much context makes it distracted or expensive.

• Stale context makes an agent confidently wrong, and noisy retrieved context can push it toward irrelevant decisions.

  If last year was the year of prompt engineering, 2025–2026 is the year of context engineering — and its implications for agentic coding systems run deep. See how practitioners at the AI Engineer Summit applied these principles in practice: State of AI Coding: Context, Trust, and Subagents.

And the newest layer is →

What Is Skill Engineering for AI Agents?

This part requires creating reusable capability packages that an agent can discover, apply, improve, version, and transfer across tasks. In simple terms, a skill is a mini-procedure: it tells the agent not only what to do, but how to do it again.

That makes skills feel closer to software artifacts than disposable prompts. A prompt is usually written for one situation. A skill is meant to survive across situations. It can be tested, maintained, shared across agents, and updated as the workflow changes.

This becomes especially important as agents turn into longer-running systems. The more often an agent repeats a workflow, the more valuable it becomes to give that workflow a stable shape. A library of skills can make agent behavior more consistent, more inspectable, and easier to improve over time.

But there is another side to this. If skills become part of the agent stack, they also become a new surface for errors, misuse, and attacks.

That is the point we’ll focus on next.

SkillOpt: training one reusable agent skill

Among all efforts aimed at improving agents’ skills, there is one recent research from Microsoft that really stands out. They proposed SkillOpt which is “a systematic controllable text-space optimizer for agent skills.” SkillOpt treats the skill document itself as something that can be trained. It creates a pipeline “agents → skills → self-improving workflows”. The core twist is →

→ Continual Learning Is Back, and It’s About to Put Models to Sleep

By coincidence, last week was all about models and their precious sleep. On May 25, a paper from Carnegie Mellon and the University of Maryland asked: Do Language Models Need Sleep? On June 2, a paper from Google-affiliated researchers answered almost directly: Language Models Need Sleep. This funny timing we can use as a signal: continual learning is back at the center of AI research, now under a different set of pressures.

Continual learning in AI is not a new problem. In classical machine learning, it usually meant training a model on a sequence of tasks without destroying what it had already learned. A model learns task B, then suddenly becomes worse at task A. This is catastrophic forgetting, and the field spent years trying to reduce it through replay, freezing, regularization, routing, and other methods.

LLMs changed the shape of the problem. Today, the question is broader: how can AI systems stay current, specialize to domains and users, learn from experience, and improve after deployment without breaking what they already know? Brutally hard.

A 2026 survey, Continual Learning in Large Language Models, gives a good map of the current field. It divides LLM continual learning into continual pre-training, continual fine-tuning, and continual alignment. It means that a model may need to absorb new general knowledge, adapt to a specific domain or task, or adjust its behavior without losing the alignment that made it useful. The survey’s conclusion states that current methods work in limited settings, but we still do not have smooth learning across tasks and time.

But what is it about sleep?

Of course, models do not literally need sleep. What they need is an offline phase for consolidation. Constant live updating is risky, while doing nothing leaves models stale. There needs to be a phase between seeing something and changing from it. This is what the sleep metaphor is trying to capture: offline processing, when the model is not simply answering the next prompt, but organizing recent experience before deciding what should persist.

The CMU/Maryland paper looks at this from the inference side. Long context is expensive because the KV cache grows as the model attends to more tokens. Some hybrid architectures compress older context into fast weights, but the paper shows that compression alone is not enough. If the model has to reason about information it can no longer directly attend to, it needs more computation before that context is cleared. Their proposed sleep phase gives the model offline recurrent passes over recent context, and the biggest gains appear on tasks that require deeper reasoning. That is the important part: memory is not only storage, it is processing.

The Google-affiliated paper moves closer to continual learning. It starts from a simple limitation: LLMs can adapt inside a context window, but that knowledge usually disappears when the session ends. Its Sleep paradigm proposes two steps. First, “Knowledge Seeding” consolidates short-term knowledge into more stable parameters. Then “Dreaming” uses model-generated synthetic data to rehearse what was recently learned. Biological terms aside, what it means is that durable learning should be separated from live interaction.

This separation may be the useful architecture for continual learning. Without it, the choices are too crude. Either the model stays mostly static and relies on retrieval, or it updates too directly and risks drift. Sleep gives researchers a third frame: the system interacts, collects experience, processes it offline, and only then decides what should remain temporary, what should become memory, and what is allowed to affect future behavior.

This is especially important for agents, because their experience is richer than a document stream. It includes tool calls, failed attempts, user corrections, environmental feedback, and repeated workflows. Recent agent-learning work points in the same direction. A roadmap on lifelong learning for LLM agents frames the problem through perception, memory, and action. Another June 2026 paper, Rethinking Continual Experience Internalization for Self-Evolving LLM Agents, shows why this is still fragile: repeated learning cycles can collapse instead of compound when experience is internalized poorly.

I also want to mention OpenAI’s June 4 memory update for ChatGPT called Dreaming. Its “dreaming” system synthesizes user memory in the background to improve freshness, continuity, and relevance across conversations. This is system-side memory, not proof that parametric continual learning is solved. But still, it shows the same pressure appearing in production: memory cannot remain a static list of notes forever.

What we see is that the field needs to move beyond the idea of continuous updating. What feels new this week is the search for a controlled phase between experience and change. Sleep becomes interesting as a boundary: a moment when the system can decide what deserves to persist, what should stay temporary, and what should be discarded. We anticipate a few breakthroughs in continual learning coming this year.

If any of those thoughts resonate with you – share them across your social networks. Let’s keep the conversation going.

Twitter Library

Reasoning RL in 2026: GRPO, DPO, RLVR, Agentic PO & Beyond

GRPO, DPO, RLVR, DAPO, GSPO, ARPO, VPO – 2026 reasoning RL methods in one place. A reference guide for training reasoning models with RL.

Turing Post • Alyona Vert.

We are reading / watching

• When AI builds itself by Anthropic

• Paving the way for agents in biology by Anthropic

Twitter tweet

News from the usual suspects ™

• Axiom pushed formal verification beyond pure math into economics. It announced EconLib, a Lean-based library for economic theory, starting with a formalization of Robert Aumann’s “agreeing to disagree” theorem. AxiomProver didn’t just verify the proof; it surfaced an implicit assumption in the underlying logic, then also proved the Monderer-Samet p-belief version. The project aims to become a Mathlib-style foundation for game theory, Nash equilibria, auction theory, information economics, and prediction-market logic – read the paper, see the code

• Sakana AI made recursive self-improvement its explicit research agenda. It launched the Sakana AI RSI Lab in Tokyo, a dedicated group focused on using AI to redesign the AI development process itself. The lab brings together Sakana’s recent line of work on AI-generated optimization algorithms, self-rewriting agents, program evolution, self-learning reinforcement agents, adversarial coevolution, and The AI Scientist.

• OpenAI pushed Codex beyond software engineering with role-specific plugins, Sites, and annotations for analysts, marketers, designers, sales teams, investors, and bankers. It also upgraded GPT-Rosalind for life sciences workflows and began rolling out Dreaming, a more scalable memory system for ChatGPT.

• Anthropic published a cyber-threat analysis showing how AI-enabled attackers are moving deeper into the attack chain and exposing gaps in existing security frameworks like MITRE ATT&CK →read the report

• NVIDIA turned South Korea into the week’s AI infrastructure stage. It announced deals with SK Hynix, SK Telecom, Naver, Doosan, LG, and Hyundai around memory supply, AI factories, robotics, data centers, autonomous mobility, and AI-powered manufacturing. Separately, Naver said it will build gigawatt-scale AI factories using NVIDIA technology, while LG is working with NVIDIA on humanoid robots and future data centers.

• Meta entered the enterprise-agent race with Meta Business Agent, expanding AI agents across WhatsApp, Messenger, and Instagram for customer support, sales, bookings, and business operations. But the week also exposed friction: its Muse Spark API was reportedly delayed, and Meta removed face-recognition code from its smart-glasses companion app after WIRED scrutiny.

• Apple finally gave WWDC an AI answer: Siri AI, a more conversational, contextual, systemwide assistant designed to work across apps while relying on on-device processing and Private Cloud Compute where possible. Reports also point to Google’s Gemini as part of the new Siri architecture.

• Washington moved frontier model release closer to national-security process. The White House signed an AI cybersecurity and frontier-model order asking leading AI developers to voluntarily submit covered models for government cybersecurity review before release, then followed with a national-security AI push focused on faster adoption, updated autonomous-weapons guidance, and multi-vendor AI use inside government.

Research highlight

Economy of Minds: Emerging Multi-Agent Intelligence with Economic Interactions

Researchers from Harvard, MIT, 2077AI, and Kempner Institute built an LLM agent “economy” where agents bid in auctions, pay each other, gain wealth from rewards, mutate if successful, and go bankrupt if ineffective. Starting with weak agents, it improved MATH from 15.9% to 57.0%, finance from 45.0% to 60.0%, science best-run accuracy from 5.0% to 20.0%, accelerator EDP from 80.2 to 39.3, and Cloudcast cost from 930 to 657.

(also a good read from 1995, Toward a Model of Mind as a Laissez-Faire Economy of Idiots by Eric B. Baum)

Open-sourced Models

• Xiaomi MiMo + TileRT pushes a 1-trillion-parameter model past 1,000 tokens per second on commodity GPUs. The key claim is inference speed on a 1T parameter model at commodity hardware levels — if real and reproducible, it changes the economics of what can be deployed without cloud dependency. Worth watching for replication.

• Gemma 4 12B (Google DeepMind): Runs on a laptop — the 12B parameter model brings Google's Gemma family to a size that can run locally on consumer hardware. For agent workflows that need to run on-device rather than cloud-dependent, this is a meaningful step forward in the accessibility of capable models.

Research

Trends we see looking at every paper related to AI and ML published last week:

• personalization instead of one-model-fits-all

• agents instead of chatbots

• world models instead of pure language scaling

• evaluation becoming training

• automated research

• memory and self-improvement

• reasoning efficiency

Agent reliability, memory, and self-improvement

• Where Do Deep-Research Agents Go Wrong? Span-Level Error Localization in Agent Trajectories – Localizes failures inside long agent trajectories, making agent debugging much more actionable.

• 🌟 Harness-1: Reinforcement Learning for Search Agents with State-Externalizing Harnesses – Makes search agents more controllable by moving state outside the model.

• 🌟 Rethinking Continual Experience Internalization for Self-Evolving LLM Agents – Reframes how agents should absorb experience over time.

Search, retrieval, and long-context reasoning

• 🌟 GrepSeek: Training Search Agents for Direct Corpus Interaction – Trains agents to investigate corpora directly instead of outsourcing thinking to retrieval.

• Critic-R: Improving Agentic Search using Instruction-tuned Retrievers with Natural Language Introspective Feedback – Adds feedback loops to retrieval, making search agents less blind and more self-correcting.

• OCC-RAG: Optimal Cognitive Core for Faithful Question Answering – Pushes RAG toward faithful reasoning rather than prettier retrieval wrappers.

World models, physical AI, and embodied reasoning

• World Models Meet Language Models: On the Complementarity of Concrete and Abstract Reasoning – Connects world models with language models for reasoning that needs both simulation and abstraction.

• Where to Look: Can Foundation Models Reach a Target Viewpoint Through Active Exploration? – Studies active exploration as a real capability for embodied agents.

• 🌟 WALL-WM: Carving World Action Modeling at the Event Joints – Models action around event boundaries, a useful step toward structured world understanding.

Model adaptation, efficiency, and scalable personalization

• 🌟 On the Scaling of PEFT: Towards Million Personal Models of Trillion Parameters – Reopens personalization at serious scale through parameter-efficient adaptation.

• 🌟 Code2LoRA: Hypernetwork-Generated Adapters for Code Language Models under Software Evolution – Generates adapters for code models as software changes.

• 🌟 KVarN: Variance-Normalized KV-Cache Quantization Mitigates Error Accumulation in Reasoning Tasks – Reduces reasoning degradation from KV-cache quantization.

• Compress-Distill: Reasoning Trace Compression for Efficient Knowledge Distillation – Compresses reasoning traces so distillation becomes cheaper and more practical.

RL, distillation, and reward design

• Trust Region On-Policy Distillation – Stabilizes behavior transfer during on-policy distillation.

• 🌟 Reproducing, Analyzing, and Detecting Reward Hacking in Rubric-Based Reinforcement Learning – Studies reward hacking in rubric-based RL, which matters because rubrics are becoming agent-training duct tape.

• 🌟 Self-Distilled Policy Gradient – Uses self-distillation to make policy optimization more stable.

Automation, research agents, and agent security

• 🌟 OpenWebRL: Demystifying Online Multi-turn Reinforcement Learning for Visual Web Agents – Brings RL into live multi-turn web interaction for visual agents.

• HarnessForge: Joint Harness and Policy Evolution for Adaptive Agent Systems – Evolves the agent harness and policy together instead of treating infrastructure as fixed.

• 🌟MLEvolve: A Self-Evolving Framework for Automated Machine Learning Algorithm Discovery – Points toward agents that search for new ML algorithms rather than only tune existing ones.

That’s all for today. Thank you for reading! Please send this newsletter to colleagues if it can help them enhance their understanding of AI and stay ahead of the curve.

⬅ FOD 154: Enterprise AI Middlemen: Who Survives the Agent Era?

In 2026, reinforcement learning (RL) is a whole industry, with a huge variety of methods created to help AI models stay on track and reason correctly. The new landscape is mainly shaped by GRPO (Group Relative Policy Optimization), RLVR (reinforcement learning with verifiable rewards), critic-free optimization, DPO (Direct Preference Optimization) variants, agentic policy optimization, and test-time diversity methods.

This guide maps the classic baselines and the newest 2026 methods for training models that reason, verify, search, self-correct, and improve with every optimization step.

TL;DR: Modern reasoning RL is shifting from expensive PPO-style pipelines toward cheaper, critic-free, group-relative, and preference-based methods. GRPO, DPO, DAPO, GSPO, ARPO, VPO, and newer DPO variants define the 2026 toolkit for reinforcement learning, agentic training, and reasoning optimization.

Now to the list!

Core RL Baselines: GRPO, DPO, REINFORCE++

GRPO

The foundation of the wave of RLVR and reasoning RL: critic-free, group-relative advantage that is cheaper than the classic PPO (Proximal Policy Optimization). By 2026, it is the central reference point. GRPO (Group Relative Policy Optimization) is a method where responses are compared within a group, without a separate value critic, which helps reduce compute costs. → Read more

DPO

DPO (Direct Preference Optimization) is already a classic “RLHF without full RL” method, because it uses human preference data but avoids the separate reward model. DPO trains the model directly on preference pairs – chosen vs. rejected pair of responses to the same prompt. It updates the model so the chosen response becomes more likely, while keeping the model close to the original supervised fine-tuned model. Now DPO is the main offline preference optimization reference point, because it is simple, stable, and also cheaper than PPO-style RLHF. → Read more

REINFORCE++

It matters as a “simple is strong again” method: it’s critic-free policy optimization that updates the model based on the reward for the full generated response, reinforcing more successful trajectories through a normalized advantage. It’s often placed next to GRPO and RLOO as a simple RLVR/RLHF baseline without PPO-level complexity. → Read more

GRPO Variants in 2026: DAPO, GSPO, DHPO and More

DAPO

One of the main GRPO-successor methods. It fixes several practical issues with GRPO: DAPO (Dynamic sAmpling Policy Optimization) keeps the GRPO-style group comparison workflow, but makes training more stable by separating clipping behavior, filtering and sampling more informative prompts, and tuning several rollout-level details. DAPO scores 50 on AIME 2024 with Qwen2.5-32B, along with an open-source large-scale RL system.→ Read more

Dr. GRPO

It matters as “GRPO done right” and a fix for token efficiency: Dr. GRPO fixes GRPO’s length-related bias by correcting how advantages and normalization are computed across tokens and responses. It normalizes using a fixed maximum or completion length, so shorter answers don’t get artificially larger updates, and longer reasoning traces are not unfairly penalized. → Read more

GSPO

A very important shift to sequence-level likelihood ratios. GSPO (Group Sequence Policy Optimization) computes the importance ratio over the whole generated sequence, then clips and optimizes this sequence-level ratio so the update aligns more directly with the final response-level reward. It is especially stable for Mixture-of-Experts RL training. → Read more

DHPO

A very fresh 2026 method: DHPO (Dynamic Hybrid Policy Optimization) combines GRPO’s token-level ratios to guide local corrections and GSPO’s sequence-level importance ratio to keep the whole-response optimization aligned with the final reward. In the end, GRPO gives you fine-grained credit assignment, GSPO better matches sequence-level rewards, and DHPO tries to get the best of both. → Read more

EP-GRPO

A fresh GRPO variant. It targets some of GRPO’s credit assignment failures: uniform token-level granularity, wrong polarity on reasoning steps, and zero-variance collapse. EP-GRPO (Entropy-Progress Aligned GRPO) tracks entropy changes across reasoning steps and uses this “progress” signal to reweight token advantages, so updates focus more on tokens that actually move the solution forward instead of treating every token equally. → Read more

TR-GRPO

One more GRPO-variant, that regulates token contributions. TR-GRPO (Token-Regulated GRPO) assigns different weights to tokens based on their estimated contribution to the final reward. This reduces noisy or unhelpful token updates while preserving stronger learning signals for important reasoning/action tokens. → Read more

DPPO

It is a fresh efficiency-focused method for group-based PO. DPPO (Dynamic Pruning Policy Optimization) makes GRPO-style training faster through dynamic pruning. It prunes low-value or redundant rollouts during group-based training, then uses importance-sampling correction so the faster update still estimates the original GRPO-style gradient without bias.. → Read more

Agentic & Test-Time Methods: ARPO, VPO

ARPO

Very important for agentic and tool-use models. ARPO (Agentic Reinforced Policy Optimization) proposes an RL algorithm designed specifically for multi-turn LLM agents. ARPO samples and optimizes at the agent-step level – across intermediate tool calls, observations, and decisions – and the model learns which actions improve the whole multi-turn trajectory instead of only rewarding the final answer. → Read more

VPO

This is one of the most interesting new VPO methods. VPO (Vector Policy Optimization) trains the model to produce diverse solution sets under different reward vectors, which is important for test-time search, best@k, and pass@k. → Read more

On X, we daily surface the AI research that matters and explain the ideas behind it. Follow us to be on track with the latest advancements!

Twitter tweet

Preference Optimization Methods: DPO Variants

InSPO

InSPO (Intrinsic Self-reflective Preference Optimization) is conceptually interesting: it brings self-reflection directly into preference optimization by conditioning the policy not only on the context, but also on an alternative response. It is a plug-and-play enhancement for DPO-family algorithms. → Read more

TI-DPO

TI-DPO (Token-Importance Guided DPO) is one of the most notable DPO variants. DPO is too coarse-grained because not all tokens matter equally. So TI-DPO introduces token-importance weights and a triplet loss, to let the model can focus more on the parts of the response that actually drive the preference. → Read more

RAPPO

A good fresh DPO variant that uses order-aware preference learning – “keep the best, forget the rest”. RAPPO (Reliable Alignment for Preference PO) ranks multiple candidate responses by preference order, keeps the strongest one as the main positive signal, and downweights or discards weaker alternatives. → Read more

FAQ

What is GRPO in reinforcement learning?

GRPO, or Group Relative Policy Optimization, is a critic-free reinforcement learning method where multiple responses to the same prompt are compared within a group. Instead of training a separate value model, GRPO uses group-relative rewards to estimate advantage, making reasoning RL and RLVR cheaper than PPO-style training.

What is RLVR?

RLVR means reinforcement learning with verifiable rewards. It trains models on tasks where answers can be checked automatically, such as math, coding, logic, or structured reasoning problems. Instead of relying only on human preference labels, RLVR uses rule-based or programmatic verification to reward correct reasoning outcomes.

GRPO vs PPO: what is the difference?

PPO usually relies on a value critic to estimate advantages during reinforcement learning. GRPO removes the separate critic and compares responses within a sampled group instead. This makes GRPO simpler and often cheaper for large language model reasoning training, especially when rewards are verifiable.

What are GRPO, DPO, RLVR, DAPO, GSPO, ARPO, and VPO used for?

GRPO is used for cheaper critic-free reasoning RL; DPO for offline preference alignment; RLVR for tasks with verifiable answers like math or coding; DAPO for more stable GRPO-style training; GSPO for sequence-level rewards; ARPO for multi-turn agents and tool use; and VPO for diverse test-time search.

Why do RLVR methods matter for reasoning models?

RLVR methods matter because they help models improve on tasks with objectively checkable answers. They are central to training stronger reasoning models for math, coding, tool use, and multi-step problem solving, where the model needs not only to sound plausible but to reach a correct result.

Most developer tools were built for human-to-human collaboration. In this interview, Mario Rodriguez, Chief Product Officer at GitHub, explains how AI coding agents and GitHub Copilot are pushing GitHub toward a new agent-native engineering system: from macro-delegation and agent-generated PRs to Copilot, AX, and the future of developers. Most developer tools were built for human-to-human collaboration.

Mario Rodriguez, Chief Product Officer at GitHub, explains the inflection point that hit in December 2025: models finally got good enough that you could "macro-delegate" to agents without constantly correcting them. 

What happened to GitHub then? Record acceleration across commits, PRs, Actions, and security scans – and a fundamental rethink of what GitHub even is.

In this interview, we discuss:

• Why December 2025 changed AI coding agents

• GitHub’s scale challenge as agent-generated activity grows

• Macro-delegation vs micro-delegation

• UI → UX → AX, or agent experience

• Copilot, canvases, and human-agent collaboration

• Usage-based billing and token discipline

• Agent-generated PRs and production quality

• Why Copilot remains co-pilot, not pilot

We also talk about the redefinition of "developer," why creation (not efficiency) drives human progress, and how GitHub plans to serve both the first-time builder and the Picasso-level craftsman on the same continuum. Watch it!

We prepared a transcript for reference, but the full experience is in the video. And as always: like and comment. It helps us grow on YouTube and bring you more insights.

What Is Macro-Delegation in AI Coding?

Macro-delegation in AI coding means giving an AI coding agent a bigger goal instead of babysitting every tiny step. You describe to Copilot or another agent what outcome you want, let it figure out the implementation, then review, steer, and polish the result. In Mario Rodriguez’s framing, this only started to really work once models got good enough to produce solid code without needing constant correction.

Now to the interview!

Ksenia:
Hi, Mario, and welcome to Inference Show by Turing Post. Thank you for joining me.

Mario:
Thanks for having me. It’s a beautiful day outside. Yesterday was a little cloudy, but today the sun came out, so I’m really happy.

Ksenia:
It is a beautiful day. But let’s get to GitHub.

According to Similarweb, GitHub has over 630 million monthly visitors. That’s an enormous surface area for development and experimentation.

So since late 2025, when agent workflows really started working, what changed at GitHub? What did you notice?

Mario:
It’s interesting. Around December, one of the key things we noticed was that model capabilities took a real jump.

Before that, if you were going to do what I call a kind of macro-delegation to an agent, you constantly had to correct it. You’d say, “No, you took this path – you shouldn’t have taken that path,” or “You did this other thing – you should have done that instead.” It was a little bit like dealing with a toddler: “No, no, don’t go that way. Do this instead. Be safe over here.”

What changed in that December timeframe was that you could actually say, “Go ahead and play – it’s safe,” and you would get an output with very high quality.

In my opinion, that unlocked two things.

First, in the developer workflow, people could macro-delegate significantly more and then micro-steer only when they needed to. And that micro-steering didn’t feel frustrating. It didn’t feel like, “Oh my God, I just wasted a bunch of tokens, and now I have to explain everything you did wrong.” Instead, it felt more like, “Okay, you did that – now let me work with you in a loop to make it better.” It became an iterative creation process rather than a correction process.

Second, as agents started running more autonomously in automation, they could go longer. And that meant you could give them better and better tasks. In other words, the ROI of the task went up.

Then, as the industry caught up – people came back from break in January, got settled after the holidays – both things started happening at once. More individual developers started using these newer models with stronger agent capabilities, and more automation started happening too.

And if you think about GitHub, we span the whole development lifecycle. It’s not just the repo and getting code into the repo. We also have issues. We also have pull requests. We also have Actions to build things. We also have security. And they all intersect and build on each other.

So if you get more commits, you’ll probably get more PRs. If you get more PRs, you’ll get more Action runs. If you get more Action runs, you’ll need more security scans. Everything compounds.

We’ve published some of these numbers. I think in March alone we saw 17 million PRs from agents. We can get into more stats if you want, but everything really shot off from there. You probably heard Jensen mention that in the keynote too – we’re all feeling this overall acceleration.

What changed is that more and more people are coming into the platform at a faster rate, partly because the floor of entry is now lower – or at least lower than it used to be. We can talk about that more later.

From a human perspective, that’s exciting. Because as more people create commits, more people create PRs, and more Actions run, all of our services are seeing record acceleration. To use made-up numbers, if we were expecting 5% growth, suddenly we’re seeing 3x that.

And that’s amazing. It really proves that we’re starting to see real value from these agentic workflows – which is why we’re all here.

What Scale Looks Like at GitHub

Ksenia:
What are the main problems with traffic at that scale?

Mario:
I wouldn’t call it a problem. I’d call it a set of engineering challenges that come with operating at that scale.

Some of them are the obvious ones. If you have more load, you need more machines to take that load. That means more servers. One of the key things we’re doing right now is shedding more load into Azure, because we’ve basically hit the limits of how much we can grow in one of our data centers. By moving more repo load and PR load into the public cloud, we can keep expanding.

That helps because if growth goes 3x, 5x, or even 10x, we can still serve it, and we’re no longer constrained by a single region.

Then there’s the broader infrastructure question. You have to talk to providers outside your immediate stack. There was one case where network infrastructure on the West Coast started getting saturated. We don’t own that infrastructure, so we had to work with those providers and tell them they needed to plan for a lot more traffic. There’s a lot of developer activity on the West Coast, so we have to collaborate across the ecosystem to make sure all of it can handle the load.

Then you get the classic scaling effects: at this level, even a tiny issue can have a lot of ripple effects. So you have to invest much more in the fundamentals of good engineering – caching, new storage approaches, different ways of acquiring and serving data. It’s very involved engineering work. But it’s also really rewarding.

A New GitHub: Lower Floors, Higher Ceilings

Ksenia:
Do you reimagine the role of GitHub now that you basically have two different audiences?

Mario:
Yeah, I’ve been thinking a lot about that. I was speaking with John Maeda, our head of design at GitHub, over the weekend, and we were exploring what’s really happening and how GitHub needs to evolve.

He shared this design analogy they had at MIT: low floors, high ceilings. I loved it, because I think that’s exactly what’s happening now.

What coding with AI is doing is lowering the floor of entry into software creation. AI – and these models in particular – like to code. That means many more people now have access to tools for creation that were previously out of reach.

And if you think about GDP growth, it happens because humans create things. Not just because we become more efficient. Progress happens when someone creates something that someone else values. That’s how human progress moves forward: creation through tools.

Right now, we’re lowering the floor. And I think we’re just at the beginning. The 630 million number you mentioned – I think what comes next will be much larger still.

Sometimes I think about Mozart. There were probably ten other Mozarts in the world at the same time, but maybe they never had access to a piano. What’s happening now is that we can reach so many more people. Yes, some of us are sitting in front of a laptop – and that’s already a privileged position in the world – but through mobile, through AI models, through GitHub, we can lower the floor of entry for creation. And I think that means we’ll see significantly more innovation in the world.

The second thing is that while we lower the floor, we also raise the ceiling. Professional developers – people who are already highly skilled – are going to be able to create better and better things. They’ll be able to push the frontier forward.

That matters too. Innovation doesn’t only come from newcomers. It also comes from experts at the frontier of the craft. Einstein didn’t start by developing relativity. He built on a lot of prior physics. He became a craftsman before he made that leap.

So you lower the floor, get more people in, more of them become professionals or craftsmen, and then you raise the ceiling of what they can accomplish.

You called it two different audiences. I think of it more as a continuum.

The mission of GitHub is advancing human progress through developer collaboration. Maybe now we should say developer and agent collaboration. That’s what I obsess over every day: how do we lower the floor, and how do we raise the ceiling? And yes, that may require a new GitHub.

What Is AX (Agent Experience) in Software Development?

Ksenia:
That’s very interesting. If you can share more – did that conversation lead anywhere concrete?

Mario:
Yes. John has this visual where there’s a user, and then a bunch of barriers, and the user has to jump through each one. Every barrier is a UI click, or some sort of processing step.

We were talking about what a new GitHub looks like from a design perspective. And to me, a new GitHub is one that has an agentic experience.

A lot of our core primitives today are based on human-to-human collaboration. Now we need to extend those primitives into human-and-agent collaboration. But the primitives themselves won’t be enough. The API layer will need to evolve to become agent-centric. And the UX layer will need to evolve too.

We announced the Copilot app, and I’m really excited about it because it introduces this idea of canvases. I think canvases are the beginning of AX – agent experience.

You have a UI, but that UI is bidirectional with the agent. The UI exposes tools, the agent can read them, and it can affect the UI. That means I can simply tell the agent what I want, and it can do what it needs to do. I don’t have to jump through 50 poorly designed screens if the agent already knows the right API to call.

But the beautiful thing is that it also works in reverse. I can interact with the UI and affect the agent. I can click a button that says “summarize,” and the agent receives that and returns something useful.

So instead of the old model – where you only talked to the agent and waited for something to come back – now creation becomes bidirectional. You have a canvas where, like an artist, you’re shaping something in real time, and the agent is helping you shape it.

That’s what I think the new GitHub will be about: a bidirectional, agentic experience.

And the beauty of that is that it works on both ends of the spectrum. It lowers the floor because people can just chat with the agent and get things done without 20,000 clicks. But it also raises the ceiling, because if you’re highly skilled – like Picasso in your own medium – you can operate deeply in the canvas, and then ask the agent to help exactly where you want. You get both, without leaving GitHub.

So yes, a lot of that conversation was really about moving from UI to UX to AX, and how that could meaningfully improve the experience.

Who Becomes a Developer in the Age of AI Agents?

Ksenia:
That sounds very creative. Which leads to my next question: who does a developer become now? A creator? A person who clicks a button, accepts, sends the PR? What is the role?

Mario:
Funny enough, I already consider you a developer. You’ve probably already interacted with agents, and those agents have probably written code for you to achieve the intent you had. So in my definition, you’re already a developer.

If we want to generalize, we could just say builder. But I do think the definition of developer is reshaping itself. A developer increasingly becomes any creator or builder who, through AI and through platforms like GitHub and Copilot, can turn intent into an outcome.

And I’m pretty excited about that, because it means many more people in the world can become creators.

Ksenia:
My concern is that you still need to manage these systems – basically be a leader – and not that many people can be leaders.

Mario:
Interesting. I don’t really see it that way.

Let’s say I know how to cook, but I’m not a Michelin chef. That doesn’t stop me from making an omelet. I don’t wake up and think, “Well, I’m not going to open a Michelin-starred restaurant, so I guess I shouldn’t cook.”

I think the same logic applies here. Creation doesn’t require you to become some grand orchestrator of 50 parallel systems. In fact, I think the industry has leaned too hard into that narrative, and for the good of society, I think we should shift away from it.

To me, this isn’t mainly about parallelization.

What matters is creation: what are you making, where are you exercising judgment, where are you shaping something meaningful?

A better analogy might be a self-driving car. You’re not manually controlling all the sensors. The system is doing that for you. What matters is where you want to go. That’s how I think GitHub should work too.

Young Developers and the New Skill Set

Ksenia:
I’m thinking about younger people. More young users will come to GitHub, and they’re worried about their future. If they want to become developers, how should they think about their skill set?

Mario:
For me, it comes back to that canvas and the agent working together. That combination can make you a builder, a creator, a developer.

Then you can choose where you want to go deeper. Maybe you want to become really good at Rust – then we should help you do that. Maybe you want to become very good at building websites. Or backend services in Go. We should help you there too.

But even in those examples, the core thing is still creation.

We need to shift the narrative toward creation, because that’s what actually drives GDP and human progress. GitHub doesn’t create GDP. GitHub enables people to create it. That’s what matters.

So yes – you’re a builder, you’re a developer, and our job is to help you do more of that.

Ksenia:
You mentioned delegation. A lot of talks were about delegation. How comfortable are you with it, and where is the balance?

Mario:
Yeah, I do a fair amount of macro-delegation now. And yes, in some sense I’m parallelizing some of those things. But honestly, I usually only have about three things going at once. I can’t deal with fifty things happening at the same time.

There are some automation-heavy tasks that I micro-delegate a lot. But when it comes to creation, I usually only keep one to three things in flight.

The analogy I like is a 3D printer. You spend a lot of time creating the CAD drawing, and then you hand it over to the printer. It prints it. At the end, you do quality control. You tweak it. You improve it.

That’s how I think about micro-delegation. I spend more time creating the CAD drawing – and then I give it to the agent, or to Copilot, and say, “Okay, now go turn this into the printed thing.” It uses the tokens; it does the work; then I quality-control it and keep refining.

So I spend much more time steering the drawing than the printing. That’s where I want to be involved.

GitHub Copilot Pricing in 2026: Usage-Based Billing Explained

Ksenia:
Copilot moved to usage-based billing on June 1. Agent sessions consume a lot of tokens, and many people weren’t very happy about it. What should cost teach developers about how to think about coding now? Is this the end of token-maxing?

Mario:
There’s definitely a lot of “maxing” going on.

One of the key things we’re trying to do is help people create across a wide range of use cases more intelligently. That’s why we have the auto setting. It does semantic routing. So if you ask, “What’s the weather in San Francisco?” we really shouldn’t send that to the biggest frontier model. That’s just not the right tool.

Instead, we can route it to a smaller model. We also just launched MAI Code One Flash, and I’m really excited about that because it packs a lot of power into a much smaller model. That makes it great for simpler development tasks.

Then we have larger frontier models – Opus, GPT, and so on – that we route to when the task really requires that level of intelligence.

The other thing we launched is Chronicle, which I think is really important. Chronicle saves your sessions into the cloud, and then lets you query them. So you can ask for things like: “Help me reduce cost,” or “Help me improve my workflow,” or “What am I doing inefficiently?”

I did this yesterday myself. It told me what I was doing wrong from a cost perspective. Even I get lazy sometimes – maybe I should have switched models and didn’t, or I should have managed context better. Chronicle can point that out.

That’s going to matter not just for individual developers, but also for enterprise FinOps. The industry needs to get to a place where predictability is key. That’s a hill all of us need to climb together.

AGI, Creation, and Staying Focused

Ksenia:
What is your understanding of AGI? What is it for you?

Mario:
Honestly, I don’t think I have a great answer for that. If I had to say something quickly, I’d say I don’t think it’s one huge event. I think it’s more of a continuum. You move through time, and at some point you cross a threshold.

It’s kind of like computing. There wasn’t one singular day where it suddenly became computing. It evolved, and then you realized you had crossed into something new.

But I’m not the right person to define AGI. What I care more about is: what can we do with this amazing technology to empower people to create? How do we lower the floor? How do we raise the ceiling? That’s where I spend my time.

Agent-Generated Pull Requests: Quality, Review & Production Code

Ksenia:
I have another question about collaboration between agents and humans – specifically pull requests. Have you learned anything from agent-generated PRs? Are they different?

Mario:
Yes, definitely. Let me use an analogy.

Imagine giving a six-year-old a recipe for a cake. The cake is probably not going to turn out very well. If I make the same cake, it’ll probably be decent. And over time, my daughter, through repetition, will get better and better at making it.

That’s what I notice most. With the power of an agent, what matters is what you’re creating, and how good the human is at guiding that creation. As the person gets better and better, the output gets better too.

Now, there are really two worlds here.

One world is: I’m working on my own app, I’m prototyping, I’m exploring. In that world, it’s okay to write some sloppy code and come back later to improve the architecture. We do that all the time. If I’m a PM and I want to create a prototype, do I need every part of it to be production-grade? No. I’m just trying to get something from my head onto the canvas so I can iterate on it. That’s totally fine.

But then there’s professional software development. That’s a different world. There, you absolutely have to care about quality, maintainability, security, and all the things that make professional software trustworthy. You do not want your bank app built carelessly. You do not want your autonomous car making decisions without security and judgment.

So the key is understanding the difference between exploration and production.

Will AI Coding Agents Replace Developers?

Ksenia:
Will there be a moment when the human is no longer necessary?

Mario:
We named it Copilot for a reason – not pilot.

We believed from the very beginning that the human would stay at the center. That hasn’t changed since 2021, when we first started having these conversations.

I’m still very bullish that creation will always include the human in the loop. The exact shape of that loop will keep evolving, just like it has with self-driving cars. But I think it will still be there.

And some people also love the feeling of direct creation. There are people who love driving a Porsche because they feel the road, they feel the turn, they know when to downshift, when to press the accelerator, when the tires regain traction. Developers feel something similar when they’re building something and really connected to the flow of it.

We want that feeling to remain part of the ceiling – part of what people can still do and enjoy.

Books, Physics, and Agatha Christie

Ksenia:
That’s very inspiring. My last question is always about a book. What book influenced you? It can be from your childhood or more recent.

Mario:
I don’t know if it’s one single book.

I’ve read basically every Agatha Christie book – including the shorter ones. So if there’s an author who really inspired me, it would probably be her. I was very into mystery.

To answer your question a little differently: physics has also been very influential in my life. My father studied physics, and that shaped me a lot. I studied electrical engineering, and if I weren’t doing this, I’d probably be designing circuits. I really love that side of engineering too.

So for recreation: Agatha Christie. For shaping my career and how I think: physics.

Ksenia:
You like solving mysteries.

Mario:
There you go. That’s true. I hadn’t thought of it that way.

Ksenia:
Physics and Agatha Christie. I’ll use that somewhere else.

Well, thank you so much. It was a pleasure.

Mario:
Thank you as well. Thanks for having me.

This interview has been edited and condensed for clarity.

← Previous Interview: Hugging Face’s Clem Delangue: Stop Comparing Engines to Cars / Related interview: When Will We Fully Trust AI to Lead? →

AI agent workflows are still trapped in chat history. In this guest post, Raymond Weitekamp explains how OpenProse – it’s open sourced! – turns successful Claude Code and Codex sessions into reusable, reviewable programs written in logical English. Read along!

I thought that I was getting really good at using Claude Code. I wrote my own custom skills and CLIs. I set up my OpenClaw to learn from its past mistakes. I configured my destructive command guard. I was using teams of agents to bring my ideas to life quickly, but I couldn’t help but feel that now my job had become babysitting.

One day my team of agents built me a fully-featured SaaS application. The next day Claude Code accidentally emptied the entire contents of my Solana wallet.

Today’s agents are mismanaged geniuses. The rate-limiting factor in my daily collaboration with Claude Code and Codex is not a model capability issue – it is a trust issue.

I don’t need the agents to be any “smarter”, I need them to be more reliable, which is why I was so excited to discover OpenProse at the beginning of the year. I felt hopeful that with this new “agent language”, I might be able to finally find a more repeatable way to get excellent work from AI. Perhaps this is the end of babysitting…finally now I can realize the true leverage that I know is possible with these mismanaged geniuses!

From the editor: OpenProse is a natural-language programming system for AI agent workflows. It lets developers describe multi-step work in logical English, turn that description into a .prose.md program, and run it through coding agents such as Claude Code or Codex. The goal is to make agent work reusable, reviewable, versioned, and inspectable instead of trapped in chat history.

The idea of specifying an entire multi-agent workflow in plain English was extremely enticing. If OpenProse works, it could become the “git for agent workflows”: a way to preserve, version, review, and reuse knowledge, instead of losing it in chat history.

Now imagine if your best-ever Claude Code session could become a reusable asset. In this article, I will show you exactly how to achieve that. 

What OpenProse is (not)

OpenProse is not an agent harness. You can run it in your favorite coding agent – whether that’s Claude Code, Codex, Hermes, or pi.

OpenProse is not a framework either. Everyone and their mother has an agent framework that they want you to adopt. In my personal experience, the useful half-life of these agent frameworks is typically shorter than the time it will take you to figure out how to use them for your project.

Technically, OpenProse is a programming language. But unlike all other programming languages I’ve ever heard of, it is not actually compiled by the computer. It is “compiled” by the coding agent.

To give you a little bit of a sense of how that works, you can think of it as one very large and very weird prompt.

OpenProse is packaged as an agent skill, which makes it easy to get started with:

npx skills add openprose/prose

At the same time, it is much more comprehensive than most skills, as it is forcing the agent to “become the virtual machine”. In other words, the OpenProse skill is incepting your coding agent into behaving like a compiler.

At the end of this article we’ll go much deeper under the hood of OpenProse, and you can skip ahead to the end if you really feel the itch, but for the purposes of understanding how we can use OpenProse to create reliable agentic workflows, the key idea is this:

OpenProse is logical natural language that both humans and large language models can understand – a shared contract to express and execute what needs to get done and how to do it.

Logical English is enough to get started

Don’t get intimidated by “the language” aspect of OpenProse. All you need to get started is to be able to express your workflow in logical English. The prose write command will handle the rest.

The prose write function takes your logical English as an argument. It outputs a .prose.md file that you can review and edit, which gets handed to your favorite coding agent, who runs the program with prose run.

Under the hood, prose write is actually its own .prose.md program, which will develop comprehensive OpenProse programs and test that they are valid before finishing. This can be a really great way to get a feel for the syntax and learn what is possible. In the same way that I would advise you to read your Claude Code or Codex “plans” before having a team of sub-agents race to implement them, it is probably a good idea to read the output <name>.prose.md file before running it, even if all of the details don’t make sense to you.

The other nice thing about the fact that OpenProse is “compiled” inside the LLM is that the agent can correct for any technically incorrect syntax. So if you want to start writing your own by hand, you don’t need to get too hung up on the syntactic accuracy to get a sense of how your programs will run.

If you want to stop reading and start doing:

• Add the skill: npx skills add openprose/prose

• Star the repo: openprose/prose on GitHub

• Need help? Ask the team at OpenProse.ai

You have hidden agent workflows on your computer

Do you have some really good Claude Code or Codex sessions? Turn them into reusable and repeatable programs that your agents can run!

Some of the most infuriating experiences I’ve had in the past year are when an agent will just absolutely nail something, everything is going perfectly, and then I will go into a new session assuming this very high standard of quality, only to be disappointed and frustrated that I can’t reproduce the magic of that golden session.

So I wrote session-to-prose, which turns a Claude Code, Codex, or Pi JSONL session log into a reusable OpenProse *.prose.md program. It does not merely summarize the session. It extracts the reusable workflow: phases, contracts, decision gates, loops, parallel work, strategies, errors, and validation evidence.

Even if you don’t know it, you are probably sitting on a goldmine of “implicit workflows”, buried in your session logs. The data is already there – OpenProse gives you the format to crystallize it into something you can run again on demand.

Explicitly declare skills as dependencies

Agent skills are amazing, and many workflows simply do not make sense without them. But at the same time, skills got some things wrong. Geoffrey Huntley argues that the content of skills should be deterministically allocated, not up to the agent to decide. In the standard implementation, skills are surfaced via progressive disclosure, which means the coding agent has to “find” the skill on its own – and it may not. When skills aren’t declared up front, your workflow’s success becomes a coin flip on whether the agent thought to reach for the right one.

I was recently using Claude Code to help a friend reformat an academic article from one journal format (which had rejected it) to another journal format for resubmission. Claude Code didn’t do a perfect job of actually reformatting everything, but the thing that blew this person’s mind was that Claude Code made comments and edits credited to Claude Code inside the .docx file itself.

Their immediate response was: “Well, how did you do that?”

I had to explain that Claude Code has a .docx skill. So this is just a very simple example of a workflow where you’re going to get completely different results with and without that skill. And if one of the stages of your multi-agent workflow is to have an agent edit a word document, then you absolutely need to declare that that skill is loaded before that sub-agent runs.

This is also a good place to explicitly call out that OpenProse is a powerful way to coordinate with multiple agents – because the different sub-agents can have different skills. As a fun and arguably extreme example, I made auto-pocock. This is a fully headless OpenProse program that runs a deterministic sequence of Matt Pocock’s engineering skills, all based from one input: a description of the feature you want built.

How and when we use skills is critical. Jude Gao at Vercel recently demonstrated that a carefully curated skill can actually be worse than a simple index of the documentation. OpenProse can give us the best of both worlds - use the skills that are trusted, with only the subagents that need them, in exactly the part of the workflow where they are called for.

Skills are capabilities. Prose programs are contracts for when those capabilities should run.

Under the hood of OpenProse

OK, I promised we’d go deeper, and if you’ve read this far you’ve earned it. This is the part where I try to explain how “a programming language compiled by a coding agent” actually works without hand-waving.

The one idea to hold onto is the one I keep circling back to: the coding agent itself is the compiler. There is no OpenProse server sitting between you and Claude Code, intercepting tool calls and orchestrating them from the outside. The agent reads the contract and becomes the virtual machine. Everything else – the file layout, the receipts – is just scaffolding that makes that role visible and keeps it from evaporating when the session closes. OpenProse runs with the agent, not around it.

The contract is the program

A Prose program is a Markdown file (*.prose.md) that declares a service in logical English. The two sections that matter most are ### Requires (the inputs the service needs before it can start) and ### Ensures (what must be true when it’s done). Around those you can declare ### Services it depends on, ### Strategies for how to exercise judgment, and an optional ### Execution block when you care about the order things happen in.

If you’ve ever written a function signature and a docstring and wished the agent would just honor them, that’s the feeling. Requires and Ensures are the contract. The agent is on the hook to satisfy them, and – this is the part that matters for trust – it has to leave evidence that it did.

Sessions, sub-agents, and the wall between them

Every service runs in its own isolated sub-agent session. This is the multi-agent part, and the isolation is the whole point: scratch work, half-formed reasoning, and dead-end files stay inside that session. The only thing that crosses back out is what you declared in ### Ensures, copied across an explicit binding. So a sub-agent can make a mess in private, and the workflow only inherits the clean, named artifact it promised. That boundary is what keeps a five-stage program from turning into one giant polluted context window.

When you need real control: ProseScript and real tools

Declarative contracts get you surprisingly far, but sometimes you need to say “do this, then that, retry three times, and loop until the reviewer approves.” That’s what ProseScript is – an imperative layer inside the ### Execution block for explicit ordering, conditionals, loops, and retries.

And when you need genuinely deterministic behavior, you don’t ask the model to be deterministic – you declare a real tool. A ### Tools block lets a service depend on an actual executable on your PATH (cli:jq, a script of your own) or an MCP server. I tried this: a service that declared cli:jq, run against a malformed JSON blob, really did shell out to jq – a genuine exit-5 parse error, caught at the right column. The determinism came from jq, not from the model imitating jq. But here is the seam, and it matters: having a real tool wired in does not guarantee the agent calls it at the right moment. The determinism lives in the script; the decision to invoke it does not. I’ll come back to this in the limitations, because it’s the single most important caveat in the whole piece.

Receipts and state: where the trust actually comes from

This is the part that, for me, is the actual answer to the babysitting problem.

The design is that every run leaves a receipt under runs/{run-id}/ – the inputs, the outputs, the logs, the artifacts each service produced. An audit trail, so that when the agent claims it’s done I don’t have to take its word for it; I can read what it actually did. “Done” stops being a vibe and starts becoming something you can inspect.

Longer-lived goals – the standing responsibilities that have to stay true over time, not just answer once – keep their memory in state/ between runs.

The full filesystem layout is src/ (what you author), dist/ (the compiled manifest the runtime reads), runs/ (receipts), state/ (durable cross-run memory), deps/ (pinned dependencies), and a prose.lock. If that looks suspiciously like a normal software project – source, build output, lockfile – that’s the point. It’s meant to live in git and be reviewed like anything else you’d review.

Why it can run anywhere

Because the agent is the compiler, the same .prose.md source runs on any harness that can play the part – Claude Code, Codex, OpenCode, Hermes, Pi (with sub-agents extension), whatever you trust. OpenProse calls this being “Prose Complete”, most coding agents that we’ve tested are “complete enough” to be useful, as long as they have a filesystem, shell and sub-agents. The upshot: your workflows get better as the models get better, without you rewriting anything. You wrote down the contract once; every future model that can satisfy it gets to.

How it compares

• vs. DSPy. In many ways, it shares similar goals to DSPy: create a layer of abstraction that enables you to author programs instead of writing prompts. However, the implementation couldn’t be more opposite. Where DSPy erects extremely strict scaffolding around the LLM calls, OpenProse asserts the entire language contract inside of the LLM.

• vs. LangChain and CrewAI. I’ll just say it plainly: I am personally allergic to agent frameworks. Before it was agents it was RAG, and the pattern is always the same – you go deep enough to actually understand the framework, you hit the one thing it won’t do, and now you’re either monkeypatching it into a fork or rolling your own anyway. As a serious AI engineer I need control over the context and all the execution details, and generic frameworks abstract exactly those away. The reason OpenProse doesn’t trip my allergy is that it isn’t asking me to move into anything. The work still runs through the coding agent I already use; OpenProse just puts a contract around the workflow. That’s a different category from “adopt our orchestration layer and live there.”

Caveats and limitations

I’d rather you trust the honest version of this than the hype version, so here are the real edges:

• The LLM is still non-deterministic. This is the big one. OpenProse can make a workflow far more explicit, inspectable, and repeatable – but it does not turn a language model into deterministic infrastructure. If you have genuinely mission-critical code that must run the same way every time, that code belongs in ordinary scripts and tests, orchestrated and verified outside OpenProse. You can declare a real tool and call out to tested, deterministic code, but as I said above, you are then trusting the agent to invoke it at the right point. The power of OpenProse – the thing that lets it not be a framework – comes precisely from the fact that the coding agent itself is the compiler. That is the magic and the trade-off in the same sentence.

• A contract only encodes the judgment you put into it. A bad Prose program will faithfully and repeatably do the wrong thing. The operator still has to know what good looks like.

• There is overhead. Not every prompt deserves to become a program. Reserve this for the workflows that are actually worth making repeatable.

• The host matters, especially the model. What can actually run depends on the affordances of your coding agent – filesystem access, the ability to spawn isolated subagent sessions, environment-variable handling. Most importantly - only the best frontier models can currently do a good job running prose programs. That will shift eventually, but as of today we recommend using the latest and greatest models and agent harnesses to run OpenProse.

Now Author Your First Outcome

As I shared before, the bottleneck is not intelligence. The bottleneck is trust and reliability. 

I am still babysitting my agents. But I am also slowly starting to write the next page for how I want to collaborate with agents, not in prompts, but in prose.

I hope that this gives you a sense of what is possible with OpenProse! Here are some very easy ways to get started:

• Add the skill: npx skills add openprose/prose

• Star the repo: openprose/prose on GitHub

• Need help deploying agents? Ask the team at OpenProse.ai

This guest post was written by Raymond Weitekamp. We thank OpenProse for supporting Turing Post’s mission to bring clarity to the AI landscape. We encourage you to try it – it’s open source.

Excerpt from today’s editorial: AI may eventually reduce the need for bulky enterprise software middlemen. But before that happens, Snowflake, Microsoft, Databricks, and others are fighting to become the trusted layer between raw AI capability and real company work.

🎫 From our partners: Explore AI & Cloud Innovation at AWS Summit NYC

Join AWS Summit NYC on June 17 to explore the latest in AI, cloud infrastructure, and modernization. At this free event, you’ll gain practical insights from leading voices like Dr. Swami Sivasubramanian, and gain access to over 200+ expert-led sessions through hands-on workshops and live demos.

Register NOW to secure your spot

→ This week was heavy with announcements. I was invited to two conferences at once – Snowflake Summit and Microsoft Build in San Francisco. And I went to both conferences because enterprise AI is where the industry is trying to make AI useful at scale. And the sentiment you read in a room full of analysts, while watching leaders push their agenda, defend their choices, and occasionally look uncomfortable, gives you much more than a machine-gun burst of news.

Let’s see what’s going on.

For two years we watched the AI story through models, benchmarks, chatbots, coding assistants, and consumer adoption. But the harder economic question is now moving inside companies. What happens when AI becomes easy enough for people to use directly? What if we don’t need a bulky and heavy middleman?

These were the questions I had in mind when I went to Snowflake Summit. Snowflake is a data-governance giant from the cloud-warehouse era, and now it has to prove it stays essential in the agentic one. The market liked the story – shares jumped more than 33% after earnings, FY2027 product-revenue guidance went up to $5.84B from $5.66B, the company signed a five-year $6B AWS deal, and market cap sits around $90B – but the strategic pressure is obvious. Databricks pushes from one side (some calls them “a bully in the room”), Microsoft tries to own the agentic interface from another, hyperscalers sit underneath everyone, and OpenAI and Anthropic, partners and customers on paper, are turning into the real competitors.

So I wanted the survival techniques. Does AI hurt enterprise software by making products replaceable, or does it make that software more valuable, because every agent still needs governed data, permissions, identity, memory, and trusted context? The usual debate stops at that binary, but I think that binary is the wrong place to stop.

Microsoft Build made the question larger. Satya Nadella’s message from the stage was that agents are everywhere – inside work, development, the operating system, local devices, cloud, enterprise knowledge. But the most useful thinking line came from a smaller Kevin Scott (Microsoft CTO) talk at a private event around Build:

• capability is moving faster than deployment

• activity doesn’t convert into value directly

• models can do more than organizations can absorb

• software can accelerate faster than companies can reorganize themselves

• autonomy doesn’t equal trust

Yup, I thought, exactly that. But these are symptoms.

Here is what the lag actually creates. Enterprises are full of legacy systems, fragile pipelines, compliance constraints, security reviews, human habits, and workflows that only make sense because someone has been repairing them by hand for years. Agents get more capable by the month; organizations do not move at model speed. So we get a strange interval, where AI threatens intermediaries in the long run while enterprise complexity keeps them useful in the short one. Snowflake, Microsoft, Databricks, Salesforce, ServiceNow are all fighting inside it, and from what I heard in the hallways, there is real uncertainty in there, almost panic, and a lot of running in too many directions at once. I also feel hey might be brittle because of their own internal complexity. Agents might need different organisation.

The comforting reading of that interval – agents threaten us later, complexity protects us now – treats the moat as a function of time. I think it's a function of cost. As per-token cost falls, the raw work middleware used to charge for, querying and generating and connecting and transforming, drifts toward free. What stays expensive is trust: knowing an agent acted on the right data, with the right permissions, on behalf of the right person, with a record of why. When everything cheap gets cheaper, the scarce thing is governed proximity to intent.

Which means the middleman doesn't disappear in the direct-use world; it changes shape. It stops being an application – capability packaged into rigid software and sold back through layers of interface – and becomes a substrate, the trust and permission layer that sits at the moment a stated intention turns into a permitted action. The agent era doesn't need less governance. It needs more, located somewhere new.

But it’s a different type of governance.

This is the test Snowflake should be judged by. Not whether it governs data – it does, and that was the moat of the last era – but how it governs it, and whether it moves up to the intent layer or stays a managed warehouse with AI bolted on top; whether it reduces the distance between what a person wants and useful work getting done, or adds one more governed layer between the user and the outcome.

And tokenmaxxing might be even dangerous here. Independently from each other, Sridhar Ramaswamy, Snowflake's gentle CEO, and Kevin Scott were making the same point: activity, or tokenmaxxing, is not value, and more agents, more context, more tokens, more integrations, more automation can all produce motion without progress. I think this is the dilemma we will be sorting through this year, both at the behemoth and startup levels.

The middleman doesn't die in this story. It moves – closer to where intention becomes work, and further from the warehouse.

If any of those thoughts resonate with you – share them across your social networks. Let’s keep the conversation going.

Topic 2: Also, NVIDIA made tons of announcements in Taipei (see News from the Usual Suspects below). We played with and covered one of the most interesting: Cosmos 3, its omnimodal world model family.

Twitter Library

20 Advanced RAG Types to Know in 2026

20 cutting-edge RAG approaches in 2026: Agentic RAG, MiA-RAG, HGMem, Graph-O1, Bidirectional RAG, multimodal, multilingual, structured and security RAG systems.

Turing Post • Alyona Vert.

News from the usual suspects ™

• Snowflake raised guidance, signed a $6B AWS agreement, expanded its partnership with Anthropic, and introduced renamed CoCo and Snowflake Intelligence / CoWork. Together, they show Snowflake trying to move from storing data to helping people and agents act on it. My question: do companies need this new layer, or is it another unnecessary AI coding interface.

• Microsoft used Build to unveil Project Solara (very interesting but still mostly under development), Scout (basically your chief of stuff), and the Surface RTX Spark Dev Box, signaling a future where agents run directly on Windows devices rather than exclusively in the cloud. They also introduced an large family of MAI models, including the first reasoning one.

• Anthropic filed confidential IPO paperwork, raised $65B at a $965B valuation, and expanded its security-focused Project Glasswing, which has already helped find more than 10,000 critical vulnerabilities.

• OpenAI claimed one of its models independently disproved a longstanding geometry conjecture, rolled out more enterprise agent deployments through Codex, and published a new Frontier Governance Framework as AI regulation starts taking shape.

• NVIDIA dominated Computex with a vision that goes far beyond GPUs:

  • RTX Spark brings agentic AI to Windows PCs with up to 1 PFLOP of AI performance and 128GB unified memory.

  • DGX Station puts a trillion-parameter AI supercomputer on an engineer's desk.

  • New humanoid robot blueprint, robotaxi, AI factory, and digital twin announcements reinforced Jensen Huang's central thesis: AI needs infrastructure, not just models.

• Meta scaled back plans to collect employee mouse and keyboard activity for AI training after internal backlash, highlighting a growing tension between agent development and workplace privacy.

• The U.S. government announced plans to invite frontier AI labs to voluntarily submit advanced models for cybersecurity testing before public release.

• Apple remains the biggest question mark ahead of WWDC next week, where expectations are building around the next phase of Apple Intelligence and Siri.

Research highlight

Twitter tweet

Models

• xAI Grok Build 0.1 (released May 20–29, 2026): Fastest coding-focused model from xAI, optimized for agentic workflows, multi-file edits, tool use, and terminal-native development. 256K context, supports text + image inputs. Now public beta on xAI API.

• Anthropic Claude Opus 4.8 (late May 2026 rollout): Major upgrade to the Opus line focused on coding accuracy, long-running task reliability, objective progress reporting, and reduced defect rates in complex reasoning/workflows. Same pricing tier as 4.7.

• MiniMax M3 (announced May 31, 2026): First open-weights model claiming frontier-level coding & agentic performance (59.0% SWE-Bench Pro, 66.0% Terminal Bench 2.1, 34.8% SWE-fficiency, 28.8% KernelBench Hard, 74.2% MCP Atlas). Features MiniMax Sparse Attention for up to 1M token context, native multimodality from day one (text + vision). API live now with 50% off promo for first 7 days (≤512K context). Full weights + tech report expected in ~10 days.

• Microsoft MAI family (announced on June 2):

  • MAI-Thinking-1: Microsoft’s first reasoning model. 35B active parameters, 128K context. Strong on complex multi-step instructions, long-context reasoning, and code generation. Matches Opus 4.6 on SWE-Bench Pro; preferred over Sonnet 4.61 in blind human tests. Low token cost, high efficiency. Private preview on Foundry.

  • MAI-Image-2.5 (and flash variant): Microsoft’s first native text-to-image and image-to-image models. Surpasses Nano Banana Pro on ELO. Rolling out in PowerPoint, OneDrive, and Foundry.

  • MAI-Transcribe-1.5: SOTA accuracy across 43 languages (streaming soon).

  • MAI-Voice-2 (and flash variant): Expanded to 15+ additional languages with new voice options.

  • MAI-Code-1: Ultra-efficient inference coding model, tuned for GitHub; now in Copilot and VS Code.

• NVIDIA

  • Cosmos 3 – a unique omnimodal world model – that we covered here

  • Nemotron 3 Ultra (available starting June 4, 2026): NVIDIA’s largest and best open model to date, specifically designed for long-running, complex autonomous agent workloads (deep reasoning, code generation, extensive research). Claims 5× faster inference and up to 30% lower cost for agentic tasks vs. other open models in class.

  • Alpamayo 2 Super: Open 32B-parameter reasoning VLA (vision-language-action) model focused on the full driving stack for safer Level 4 autonomous development. Emphasizes reasoning, planning, and acting.

  • Gamma-World (γ-World) (announced May 27, 2026): It scales interactive simulation beyond single- or two-player settings. Introduces Simplex Rotary Agent Encoding and Sparse Hub Attention for independently controllable, permutation-symmetric agents. Enables real-time (24 FPS) coherent multi-agent video rollouts with strong zero-shot generalization to more agents.

• Qwen3.7-Plus (announced June 1, 2026 by Alibaba): Multimodal agent foundation model that unifies vision + language into a single versatile agent.

Research

Trends we see looking at every paper related to AI and ML published last week:

AI research agents and deep research

• AutoResearchClaw – Moves autonomous research from a linear pipeline toward iterative systems with debate, self-healing execution, human intervention, and cross-run learning →read the paper

• QUEST – Trains open deep-research agents with fully synthetic tasks, making synthetic task generation look like a serious path for scaling research agents →read the paper

• 🌟 ScientistOne – Pushes autonomous research toward verifiability by requiring claims to trace back to evidence, which directly addresses hallucinated citations, unreproducible scores, and method-code mismatch →read the paper

Agent operating systems: harnesses, skills, and coordination

• 🌟 SkillOpt – Treats agent skills as trainable external state, with controlled edits, validation gates, and transfer across models and execution harnesses →read the paper

• 🌟 MUSE-Autoskill – Builds a full lifecycle for agent skills: creation, memory, management, evaluation, refinement, reuse, and cross-agent transfer →read the paper

• Foundation Protocol – Proposes coordination infrastructure for large populations of agents, with identity, provenance, multi-party organization, metering, receipts, settlement, and governance as first-class concerns →read the paper

Memory, context, retrieval, and persistence

• ACC – Converts agent trajectories into long-context training data, using tool responses and environment observations as supervision for distant evidence integration →read the paper

• WorldKV – Makes persistent world memory cheaper for interactive video world models by retrieving and compressing KV-cache chunks instead of keeping everything in full attention →read the paper

• 🌟 Do Language Models Need Sleep? – Introduces offline recurrence as a consolidation phase, giving models a way to process long-horizon memory outside the active inference window →read the paper

• 🌟 OmniRetrieval – Unifies retrieval across text, relational tables, knowledge graphs, and property graphs without flattening every source into one generic representation →read the paper

• Personalize-then-Store – Moves agent memory toward user-specific storage policies, asking which interactions are worth saving for each person rather than applying one universal rule →read the paper

Training for reasoning, diversity, and test-time search

• DelTA – Improves RLVR by assigning token-level credit more discriminatively, so training can amplify the tokens that actually separate successful from failed reasoning →read the paper

• 🌟 Vector Policy Optimization – Trains models to produce diverse solution sets for test-time search, instead of collapsing toward similar answers optimized for one scalar reward →read the paper

Architectures, world models, and physical AI

• HRM-Text – Tests whether hierarchical recurrent architectures can deliver stronger sample efficiency than standard Transformer scaling recipes →read the paper

• 🌟Gamma-World – Extends world models from single-agent or two-player settings toward scalable multi-agent interactive simulation →read the paper

• Qwen-VLA – Unifies manipulation, navigation, and trajectory prediction inside one vision-language-action model across tasks, environments, and robot embodiments →read the paper

Verifiable environments for computer-use agents

• OpenComputer – Creates verifiable software worlds for desktop agents, using app-specific state verifiers, auditable trajectories, and partial-credit rewards →read the paper

• MobileGym – Provides a highly parallel, verifiable mobile-GUI simulation platform, making smartphone-agent training more scalable and measurable →read the paper

• CUA-Gym – Scales verifiable RL environments for computer-use agents by generating task instructions, environment states, and reward functions together →read the paper

That’s all for today. Thank you for reading! Please send this newsletter to colleagues if it can help them enhance their understanding of AI and stay ahead of the curve.

⬅️ FOD 153 Agentic coding in search – What it even means?

➡️ FOD 155 Continual Learning in LLMs: Why AI Models Need Sleep

There’s probably nothing more inspiring than using AI in the field that brings the greatest benefit to humanity and the world as a whole ‒ science and research. And right now, we’re seeing a sharp leap in the rise of new AI systems acting as co-scientists.

No, this doesn’t reduce the value of scientists, engineers, or researchers ‒ these systems help people generate and analyze results much faster, accelerating progress in biology, chemistry, physics, medicine, and beyond. Massive amounts of tedious analysis, hypothesis testing, and experimentation that used to take many years, can now be done in days, sometimes even hours.

So today, we’ll look at some of the most interesting AI co-scientist systems.

TL;DR: Use DeepMind’s Co-Scientist and Robin for biology and drug discovery, AxiomProver and AI Co-Mathematician for theorem proving and mathematical research, ERA and AI CFD Scientist for autonomous scientific simulations, and systems like The AI Scientist or AutoResearchClaw for fully automated end-to-end research workflows.

Some of them are biology co-scientists discovering drugs and engineering proteins. Some are AI mathematicians solving proofs and conjectures. Others generate scientific simulations and experiments, and there are also systems that automate the entire research pipeline, even including paper writing. Further, you’ll also find 6 open-source co-scientists.

/

The Most Notable Co-Scientists

1. Google DeepMind’s Co-Scientist

This is one of the defining AI systems of 2026 that can reduce large-scale biological data analysis from months to days. Built on Gemini as a multi-agent research architecture, it generates, debates, ranks, and evolves scientific hypotheses through iterative “idea tournaments” inspired by AlphaGo. The system is already being used for fibrosis, ALS, antimicrobial resistance, cellular aging, infectious diseases, and plant immunity research ‒ including identifying a fibrosis drug candidate that blocked 91% of a scarring-linked response in lab tests.

Co-Scientist is the core research engine behind Google’s broader Gemini for Science initiative: the “Hypothesis Generation” tool is explicitly built on Co-Scientist. Google positions it as part of a larger ecosystem alongside AlphaEvolve (for computational experiments) and NotebookLM-based Literature Insights.

• Co-Scientist: blog post 

• Gemini for Science: blog post

2. OpenAI model and a famous conjecture in geometry

OpenAI’s new reasoning model (it’s name is not mentioned) has just solved a math problem that had stumped researchers since 1946 ‒ one of Paul Erdős most famous geometry puzzles: if you place n points on a plane, how many pairs can sit exactly one unit apart? For nearly 80 years, mathematicians believed square-grid-like patterns were basically optimal.

The AI proved that they weren’t. A general-purpose reasoning model (not a math-specialized system) discovered a completely new construction that creates far more unit-distance pairs than anyone expected. It used deep ideas from algebraic number theory that experts never thought connected to this geometry problem. Mathematicians verified the proof and called it a milestone for AI-driven mathematics.

• Open’s blog post

• The proof from the model: Research Paper

3. FutureHouse’s Robin

This multi-agent system autonomously generates and experimentally validates a therapeutic hypothesis for a real lab workflow: reads papers, generates hypotheses, proposes experiments, analyzes lab data, and iterates on results in a loop.

Researchers tested it on dry macular degeneration ‒ a major cause of blindness. Robin proposed that improving retinal cell “cleanup” (phagocytosis) could help treat the disease, then identified ripasudil (a glaucoma drug) as a candidate. Lab tests confirmed the real effect of ripasudil.

Robin also analyzed RNA-seq data itself and discovered a possible new target, ABCA1.

• Robin Research paper

4. AxiomProver by Axiom Math

AxiomProver is an AI mathematician that writes fully machine-verified mathematical proofs in Lean. In 2026, it autonomously solved all 12 problems of the Putnam exam, one of the hardest undergraduate math competitions in the world, with 8 solved within the official contest time. It handles calculus, combinatorics, geometry, and number theory problems, and sometimes discovered proof strategies humans didn’t expect, including geometric arguments and brute-force formal reasoning.

• AxiomProver: Axiom Math’s blog post

5. AI co-mathematician

Here is another research partner from Google DeepMind but for mathematicians. It uses multiple AI agents based on Gemini that work in parallel, almost like a research team in a collaborated workspace. One agent might search literature, another explores examples, while others try proving or disproving ideas. Researchers can guide the process interactively.

Mathematicians used it to solve open problems, discover new research directions, and find overlooked papers. It also scored a record 48% on one of the hardest math benchmark ‒ FrontierMath Tier 4.

• AI co-mathematician Research paper

Watch this video to get a full picture of how AI is transforming science and why it feels so important now →

Open-Source Co-Scientists

1. ERA (Empirical Research Assistance)

This AI system by a group of researchers from top universities like MIT, Harvard, McGill University and Google researchers generates scientific simulation code for complex research problems, helping scientists build computational experiments and large-scale simulations much faster. ERA continuously writes, tests, scores, and improves scientific software through trial and error using AlphaZero-style tree search. It can combine ideas from papers, textbooks, and existing methods to invent new hybrid approaches.

The most notable results:

• ERA created 40 biology methods that outperformed top human approaches for single-cell data analysis.

• It generated 14 COVID forecasting models that beat the CDC ensemble.

• It also reached expert-level performance in geospatial analysis, neuroscience, and time-series forecasting.

• ERA: Research paper

• GitHub: ERA GitHub

• Google Research’s ERA blog post

• Experiments

2. Axiom Math’s Axplorer

This AI system solves extremely hard math optimization problems, where there are trillions of possible solutions. It works in a loop: an AI model learns patterns from good solutions, generates new candidate solutions, and then a local search algorithm fixes and improves them. Over time, the system gets better at proposing promising candidates.

The team has already used it on difficult combinatorics problems like square-free graphs and isosceles-free point sets. In one case, Axplorer found an optimal graph solution in 2.5 hours on a single GPU, using about 100× fewer attempts than earlier methods.

• Axplorer: blog post

• GitHub: Axplorer GitHub

3. DISCO by FutureHouse

This multimodal generative model co-designs entirely new proteins and enzymes from scratch. You give it a target molecule or desired chemistry, and it invents both the protein sequence and the 3D structure simultaneously.

DISCO’s concept may sound too similar to DeepMind’s AlphaFold, but AlphaFold’s idea is different: it predicts how an existing protein folds into a 3D structure. AlphaFold is mainly a prediction modeling system, while DISCO is a generative design system.

• DISCO: blog post

• GitHub: DISCO GitHub

• DISCO: Research Paper

4. kUPS from CuspAI

CuspAI introduced kUPS, an open-source molecular simulation engine for AI-driven chemistry and materials science. kUPS unifies molecular dynamics, Monte Carlo simulations, geometry optimization, and ML-based force fields inside one GPU-native Python/JAX framework. It’s designed around composable “propagators” ‒ different simulation techniques and ML models can plug together easily. The system also supports batching thousands of simulations in parallel on GPUs. kUPS tool gives 49× faster simulations than standard chemistry tools.

• kUPS: blog post

• GitHub: kUPS GitHub

• GitHub: Tojax GitHub ‒ a small library from CuspAI that converts PyTorch models into JAX functions and allows to run them inside JAX-based simulation systems

5. AI CFD Scientist with a physics-aware verification loop

This “AI scientist” is built specifically for computational fluid dynamics (CFD) ‒ the kind of simulations engineers use to study airflow, turbulence, jets, aerodynamics, combustion, and fluid motion. CFD is much harder than normal AI research automation, because a simulation can technically “work” while still being physically wrong. So the biggest breakthrough here is that the system includes a physics-aware verification loop: it renders flow simulations and uses a vision-language model (VLM) to check whether the physics looks realistic. If flow patterns are wrong, the AI rejects the run and fixes or reruns the simulation.

After 44 iterative experiments, AI CFD Scientist discovered a new correction for the Spalart–Allmaras turbulence model that improved wall-friction prediction accuracy by 7.89%.

• AI CFD Scientist: Research Paper

• GitHub: AI CFD Scientist GitHub

6. The AI Scientist from Sakana AI

We can’t not to mention Sakana AI’s AI Scientist, even though it was developed in 2024. It automates the full machine learning research workflow: generating ideas, searching literature, writing code, running experiments, analyzing results, and drafting complete research papers. One of its biggest milestones was producing the first fully AI-generated paper to pass a real human peer-review process at an ICLR workshop. AI Scientist-v2 also introduced agentic tree search, parallel experiment execution, and VLM-based figure checking to improve experiments and paper quality. The project also showed a clear “scaling law”: stronger foundation models consistently produced higher-quality scientific papers.

• The AI Scientist: blog post

• The AI Scientist-v2: Research Paper

• GitHub: The AI Scientist-v2 GitHub

7. AutoResearchClaw

This AI co-scientist automates the full research loop: generating hypotheses, running experiments, fixing failed code, analyzing results, and writing papers. It uses multiple debating agents, can “self-heal” broken experiments, and stores lessons from past runs. It also verifies citations and checks that every reported metric comes from real experiment logs to reduce hallucinations and fake results.

• AutoResearchClaw: Research Paper

• GitHub: AutoResearchClaw GitHub

FAQ

What are AI co-scientists?

AI co-scientists are autonomous or semi-autonomous AI systems designed to assist with scientific discovery. Unlike standard chatbots, they can generate hypotheses, analyze papers, run experiments, write code, evaluate results, and sometimes even produce research papers.

What kinds of AI co-scientists exist?

Some systems specialize in biology and drug discovery, others focus on mathematics, scientific simulations, physics, or materials science. Newer systems increasingly combine multiple agents into autonomous research teams.

Which AI co-scientists are focused on biology?

Google DeepMind’s Co-Scientist, FutureHouse’s Robin, and DISCO are among the strongest biology-focused systems. They work on drug discovery, protein engineering, disease research, and therapeutic hypothesis generation.

Which AI systems specialize in mathematics?

AxiomProver, AI Co-Mathematician, Axplorer, and OpenAI’s reasoning systems focus on theorem proving, formal verification, optimization, and solving difficult mathematical problems.

What are scientific simulation agents?

Systems like ERA, kUPS, and AI CFD Scientist autonomously generate scientific simulation code, run computational experiments, optimize models, and verify results across fields like biology, fluid dynamics, chemistry, and forecasting.

What is a fully autonomous AI scientist?

Systems like The AI Scientist and AutoResearchClaw automate nearly the full research workflow: literature review, idea generation, experimentation, debugging, analysis, verification, and paper writing.

Are there open-source AI co-scientists?

Yes. Projects like The AI Scientist, Axplorer, DISCO, ERA, kUPS, AI CFD Scientist, and AutoResearchClaw are open-source and allow researchers to inspect, modify, and extend their scientific workflows.

Why are AI co-scientists becoming important now?

The rise of reasoning models, long-context memory, multi-agent systems, and tool-using AI agents has made it possible for AI systems to handle long-horizon scientific workflows that previously required large human research teams.

Further reading

If you're just getting started with ML and AI, check out our curated list of Top 10 GitHub repos for AI & ML practitioners— collections of courses, guides, and projects to build your foundations.

If you’ve found this article valuable, subscribe for free to our newsletter.

We post helpful lists and bite-sized explanations daily on our X/Twitter. Let’s connect.

https://x.com/TheTuringPost

Most agent architectures are secretly stateless. In this guest post, Addy Osmani, Director at Google Cloud, and Shubham Saboo, Senior AI Product Manager at Google Cloud, discuss what it takes to build ones that aren’t.

Developers spend weeks perfecting prompt engineering, tool calling, and response latency. None of it matters when your agent needs to stay alive for five days.

The workflows that actually matter in production — processing thousands of insurance claims, running week-long sales sequences, reconciling financial data across systems — don't fit inside a single conversation turn. They take days, not seconds. And the moment you try to build them, you run into a wall that most tutorials skip over: most agent architectures reconstruct context from scratch on every interaction. They lose the reasoning chain, the soft signals, and the confidence gradients that made the agent's previous decisions make sense.

This is the production gap. Demos close it with short, clean tasks. Real systems don't get that luxury.

At Google Cloud Next '26, we announced that Agent Runtime now supports long-running agents that maintain state for up to seven days. What follows are five design patterns — drawn from what we've seen actually work in production — for building agents that survive contact with reality.

Pattern 1: Checkpoint-and-Resume

The most common failure mode in multi-day workflows is context loss. An agent processes 200 documents over four hours, then hits an error on document 201. Without checkpointing, you restart from scratch.

The fix is conceptually simple but architecturally important: treat your agent like a long-running server process, not a request handler. The same way you'd build a data pipeline that processes millions of records — checkpoint progress, handle partial failures, ensure idempotency.

from google.adk import Agent, ToolContext

class DocumentProcessor(Agent):
    """Processes large document sets with checkpoint-and-resume."""

    async def process_batch(self, docs: list, ctx: ToolContext):
        checkpoint = self.load_checkpoint()
        start_idx = checkpoint.get("last_processed", 0)

        for i, doc in enumerate(docs[start_idx:], start=start_idx):
            result = await self.classify_and_extract(doc)
            self.results.append(result)

            # Checkpoint every 50 documents
            if (i + 1) % 50 == 0:
                self.save_checkpoint({
                    "last_processed": i + 1,
                    "partial_results": self.results,
                    "timestamp": datetime.now().isoformat()
                })

        return self.compile_final_report()

Notice the checkpoint granularity. Not after every document (wasteful). Not only at the end (risky). Fifty documents per batch balances durability against overhead. Your specific number depends on how expensive each unit of work is.

Pattern 2: Delegated Approval (Human-in-the-Loop, Done Right)

Every agent framework advertises human-in-the-loop. But in practice, most implementations amount to: serialize state to JSON, send a webhook, hope someone checks it.

The problems compound fast. JSON serialization loses implicit reasoning context. Notifications compete with dozens of other alerts. When the human responds hours later, the agent has to deserialize, re-establish context, and hope nothing changed in the interim.

Long-running agents handle this differently. When the agent hits an approval gate, it pauses in place. The full execution state stays intact: reasoning chain, working memory, tool call history, pending action. The agent consumes zero compute while waiting. Sub-second cold starts mean zero latency penalty when it resumes.

The critical detail is the time accounting. If an agent pauses for human review at hour 8 and the reviewer responds at hour 32, those 24 hours are dead time for the agent but productive time for the human. The agent doesn't drift, degrade, or need re-priming. It picks up exactly where it left off.

At scale — if you're managing twenty concurrent long-running agents — you need a unified inbox that categorizes what needs attention. Not Slack channels. Not email threads. A structured queue: "Needs your input," "Errors," "Completed."

Pattern 3: Memory-Layered Context (and Why You Have to Govern It)

A seven-day agent needs more than session state. It needs to remember things from previous sessions, organizational context that no single conversation could contain, and user preferences from weeks ago.

This is where the architecture gets interesting — and where most teams underestimate the risk.

Think of long-term memory as analogous to a knowledge base: it accumulates everything the agent has learned across interactions, organized by topic. Working memory, by contrast, provides low-latency access to specific, high-accuracy details needed right now. The two layers work together, but they have to be kept distinct.

Here's the problem most developers don't anticipate until production: memory drift.

Your agent's behavior isn't shaped only by its code and prompts. It's shaped by accumulated experience. If an agent "learns" from a few atypical interactions that a procedural shortcut is acceptable, it may start applying that shortcut broadly. And if multiple agents read and write to shared memory pools, data leakage between distinct workflows becomes a real risk — the kind that's hard to detect and harder to explain to a compliance team.

This is where the governance layer becomes non-negotiable. You can't let agents write to a shared memory store unchecked. You need to govern them the same way you govern microservices. Concretely, this means three things:

Agent identity. Every agent needs a cryptographic identity that determines exactly which memory banks and tools it's authorized to access. Think IAM, but for agents.

Centralized registry. When you have dozens of long-running agents, you need a single source of truth for which agents are active, what version of the prompt and code they're running, and what their current execution state is.

Policy enforcement at the boundary. A governance layer sitting between the agent and its memory should evaluate every access request against organizational policies. If an agent tries to commit PII to long-term memory, that transaction should be blocked before it happens — not audited after.

The question to ask yourself isn't just "what are my agents doing?" It's "what are my agents remembering, and how is that changing their behavior over time?"

Pattern 4: Ambient Processing

Not every long-running agent interacts with humans. Some are ambient. They watch for events, process data streams, and take action in the background without any user prompting.

A real-world mesh looks something like the diagram above. A content moderation agent consumes new uploads from Pub/Sub and routes flagged content to human review. A data quality agent watches BigQuery for new rows, detects anomalies, and delegates remediation to a data engineering specialist via A2A. A customer event agent ingests support tickets and classifies them in real time — routing billing questions, technical issues, and VIP cases to dedicated downstream agents. None of these agents wait to be asked. They run continuously, reacting to the event stream.

The architectural decision that matters most here ties back to Pattern 3: don't hardcode policies into the agent.

Define them in your governance layer and let the agent enforce them at runtime. When policies change, you update once and every ambient agent in the fleet picks up the new rules immediately. This separation matters because ambient agents run unsupervised for long stretches. If you hardcode policies, every policy change requires redeploying every agent. If you externalize policies, you update once and the fleet adapts — without downtime, without redeployment, without the risk that one agent is running an outdated version of your compliance rules.

Pattern 5: Fleet orchestration

The final pattern is about managing multiple long-running agents as a coordinated fleet. In production, you rarely have a single agent working alone. You have a coordinator agent that delegates sub-tasks to specialist agents, each running independently for different durations.

Consider a sales prospecting sequence. A coordinator breaks the work into components: research, scoring, sequencing, outreach, and follow-up. Each of those is a specialist agent running on its own timeline, with its own identity, its own tool permissions, and its own entry in the registry.

The coordinator maintains global state and handles handoffs between specialists. This is the same coordinator/worker pattern used in distributed systems for decades. What's new is that it can be defined declaratively through graph-based workflows, where the structure of the coordination logic is enforced by the framework rather than expressed in a system prompt that an LLM might decide to shortcut.

The operational advantage of treating each specialist as an independent unit is that you can update them independently. If your scoring logic needs improvement, you deploy the new version, monitor its performance, and promote it only when the results hold up. A bad deployment in one specialist never cascades to the others.

A2A and MCP: The Interoperability Layer

One thing the five patterns above don't fully address: most organizations won't build every agent they need from scratch. The real leverage comes from agents built by different teams — sometimes in different languages, sometimes at different companies — being able to discover and collaborate with each other.

Two open protocols are emerging as the connective tissue here. A2A (Agent-to-Agent) standardizes how agents communicate with other agents. MCP (Model Context Protocol) standardizes how agents communicate with tools and data sources. Together, they mean that a Python-based coordinator can delegate to a Go-based specialist, which can delegate to a Java-based compliance checker, without any of those teams needing to negotiate custom integration formats.

Every A2A-compatible agent publishes a card at a well-known URL describing its capabilities, authentication requirements, and rate limits. Think of it as an OpenAPI spec designed for agent-to-agent interaction rather than client-server communication. A central registry amplifies this: other agents across your organization can discover capabilities without knowing specific URLs. The registry becomes the service mesh for your agent ecosystem.

The diagram above shows what this looks like in practice. A coordinator agent doesn't need to know the URL of the financial analysis agent, or that it's written in Python, or how its auth works. It queries the registry, finds the card, and connects. When the document processing team ships a new version of their Java agent, they update the card. Every coordinator in the organization gets the upgrade automatically.

MCP handles the other side: connecting agents to databases, enterprise systems, and APIs through a single protocol. Without it, every data connection requires its own custom integration code. With it, a Stripe connector looks the same to your agent as a BigQuery connector — the protocol is the interface, and the backend is interchangeable.

The governance story matters here too. Each organization maintains its own governance boundaries. Your policy enforcement layer controls what data your agents can share with a partner agent, what actions they're permitted to take based on the partner's responses, and what information they're allowed to request. Cross-organization collaboration happens through the protocol; each side enforces its own security model independently.

The multi-language, cross-team version of this plays out exactly as you'd expect. A customer onboarding workflow might involve a Python coordinator, a Go identity-verification agent owned by the security team, a Java credit-assessment agent owned by risk, a Go account-provisioning agent owned by platform, and a TypeScript communication agent owned by marketing — each team iterating independently, none of them blocked by the others.

Choosing the Right Pattern

These patterns compose. A compliance system might use Checkpoint-and-Resume for document processing, Delegated Approval for review gates, Memory-Layered Context for cross-session knowledge, and Fleet Orchestration to coordinate specialists.

The key diagnostic question: what is the longest uninterrupted unit of work your agent needs to perform?

If it's minutes, you probably don't need long-running agents. If it's hours or days, these patterns are where you start — and the governance and interoperability layers become load-bearing, not optional.

The companies building isolated, stateless agents today will be refactoring in twelve months. The ones building with persistence, governance, and interoperability in mind will be compounding their advantage every day.

*This guest post was written by Addy Osmani, Director, Google Cloud and Shubham Saboo, Senior AI Product Manager, Google Cloud. We thank Google Cloud for their support of Turing Post’s mission to bring clarity to the AI landscape.