TL;DR When the agents I build fail, the recovery often falls to a human. That loop gets expensive as deployments grow. I want distributed learning networks where a recovery learned by one agent can be tested and reused by others facing the same failure.

My first attempt at building a distributed learning system wasn’t for a tech company. It was for a network of food banks.

These organizations sit on the front lines of food insecurity. They collect data on community needs, seasonal demand, and supply chain bottlenecks. But privacy rules and siloed systems meant they couldn’t share it. Each food bank was an island, operating with limited visibility while the data that could help them collectively was locked away. It was a classic coordination problem.

So, we tried to solve it with federated learning. The idea was simple: allow their systems to learn from each other’s data without ever exposing the raw, private information. It was a big idea to take to non-profits and local governments. And it mostly worked. But when it failed, it failed miserably. An agent in one location would stumble on a data format it had never seen (ie. multimodal data of donations or food inventory), and the entire learning process would grind to a halt. There was no mechanism for it to learn from the error and share that solution with the rest of the network.

A Learning and Coordination Problem

The experience stuck with me. It felt less like an engineering problem and more like a learning and coordination problem.

By trade, I’m an educator. I spent years studying the concept of “productive struggle.” Learning isn’t about getting the right answer. It’s about grappling with a problem that’s just beyond your current ability. It’s that sweet spot where you’re challenged but not overwhelmed. The useful part is having to try, get feedback, and adapt.

After years of studying this in humans, I keep coming back to a related problem with AI. Many of the agents I build have no way to turn a failure into a lasting change in behavior.

We expect them to perform reliably, and when they don’t, we treat it as a bug to be patched by a human. An agent fails, an engineer gets paged, and the endless, reactive loop spins up. It’s a manual, brittle process. We’re not teaching our agents to learn; we’re just fixing their mistakes.

As companies deploy more agents, that loop creates more work for the people maintaining them.

Why Your Agents Can’t Learn (Yet)

An idea I haven’t been able to get out of my head is, “What if agents had a stand-up meeting together? What if they could reflect on their work, share what went wrong, and learn from each other’s failures?”

Agent failures often follow patterns. An API timeout, a malformed response, a hallucinated parameter. These are signals. They are learning opportunities.

A recovery learned by one agent could be useful to others facing the same failure.

But for that to happen, we need to build the infrastructure for it. Imagine a payment agent that encounters a rare Stripe API error and finds a recovery. The network could share a description of the failure and a candidate fix, with payment details removed. Another agent would still need to test that fix against its own API version, permissions, and payment state before using it.

That is the distributed learning network I want to build. A shared fix would be useful only where it passes the receiving system’s checks. The aim is to carry useful experience across agents while keeping the context and limits of each recovery visible.

How to Teach an Agent to Learn

Two ideas from the research community point the way.

Sleep-Time Compute. As a recent paper from Letta highlights, agents spend most of their time idle. We can use this “sleep time” to have them run drills, anticipate failures, and pre-compute solutions. In their benchmarks, this produced about a 5x efficiency boost. More importantly, it makes the loop proactive.

LLM Daydreaming. This takes it a step further. As described by Gwern, this is a continuous background process of exploring “what-if” scenarios. The idea is to generate candidate responses to edge cases, then test which ones are worth retaining.

The stack needs a cognitive layer that manages this continuous learning process. It would handle four key things:

  1. Persistent Model State: (ie. Team/organization wide memory) Giving agents a memory that evolves. Not just a chat history, but a deep, compounding understanding of their environment and goals.
  2. Goal Composition: A way to resolve conflicts when a sales agent’s goals clash with a finance agent’s (ie. A protocol for users to teach the system, complete with reviews and ownership, ensuring that human expertise is captured and scaled.)
  3. Verification Orchestration: Checks that test proposed recoveries before another agent uses them, with review and rollback when those checks are insufficient.
  4. Distributed Learning Protocol: The core of the system. A protocol for agents to share learned strategies and failure-recovery patterns without sharing sensitive data.

As agents get trained continuously on harder operational tasks, their policies will carry more of the objective than the prompt alone. The bottleneck then shifts from prompting one agent to managing fleets of objective-conditioned agents.

If the current trajectory holds, the next bottleneck looks like this.

  • Companies run many task-specific RL loops at once.
  • Models carry persistent state or goals beyond one session.
  • Verification becomes a major compute and operations cost.
  • Prompt engineering gives way to reward design, evaluation, and goal composition.

The useful target is an organization-specific learning system, not a generic chatbot. It adapts to local data, constraints, and failures while keeping review and ownership in the loop.

Try this. Look at your last 10 agent failures. They likely follow patterns. Now imagine if your agents could recognize those patterns, too. That’s the future we need to build.