The Dupoux-LeCun-Malik paper has a phrase that should make every AI company uncomfortable: "outsourced learning." Here's what they mean: current AI systems don't actually learn. Humans do the learning—curating data, designing training pipelines, monitoring performance, deciding when to retrain. The AI executes fixed patterns that humans figured out. It ships frozen. The world changes. The system breaks. Humans fix it. Repeat until everyone involved wants to quit their jobs. We identified this problem 18 months ago, not because we're smarter than anyone, but because we tried shipping a frozen system into healthcare and watched it fail in ways that cost actual money. A 400-bed hospital can easily carry 10,000 open denials at any given time. Someone has to work that list. When your "AI-powered" system starts generating more denials than it prevents, you hear about it. Loudly.
To give you an idea of what outsourced learning looks like in practice: A health system deploys an AI tool for prior authorization. The tool was trained on historical auth requests from 2022-2023. It works well initially—approval rates improve, prior auth time drops from 45 minutes to maybe 15. Then, around month four, a major payer updates their authorization requirements. New documentation standards. Different clinical criteria. Changed submission formats. (This happens constantly, which is neither here nor there, but it means any static system is living on borrowed time.) The AI doesn't know about these changes. It can't know. It was frozen in 2023. It keeps submitting authorizations the old way. Denial rates spike. The health system's revenue cycle team starts manually reviewing every submission. The AI becomes more work than it saves. Boo frickin' hoo, except it's real money and real operational chaos.
What happens next? The vendor schedules a "retraining cycle." Engineering teams gather new data. They design a training run. They validate. They deploy. Maybe 6-8 weeks later, the system catches up to where the payer was two months ago. Meanwhile, the health system has been bleeding denials. That's outsourced learning. The AI doesn't adapt. Humans do the adaptation work. The AI is just expensive middleware that occasionally produces correct outputs.
We started with a different assumption: the system must learn from what happens while it's happening. Not "schedule a retraining run." Not "wait for the next version." Learn from the outcomes of its own actions, in production, continuously. This required three architectural decisions that the paper validates but that we made independently. First: outcome capture is mandatory, not optional logging. Every workflow execution generates an outcome record—success or failure, quality score, timing metrics, resource usage. If the system did something, we know whether it worked. Without outcome data, there's nothing to learn from. Second: patterns are living, not frozen. Our pattern library isn't a static artifact from training. Patterns get created from observed guidance requests. Their confidence scores evolve based on whether they work. Effective patterns survive. Ineffective ones decay. This creates selection pressure without human intervention. We don't decide which patterns are good. Usage data does. Third: confidence thresholds adapt. The boundary between "act autonomously" and "ask for help" isn't fixed at some magic number. It moves based on accuracy. If the system's confident actions keep working, the threshold tightens—more autonomy earned. If confident actions start failing, the threshold loosens—more consultation required. The system doesn't need someone to tune its confidence. It tunes itself based on results.
The paper calls what we implemented "System B—learning from action" and "developmental progression" and "meta-control mode switching." Different vocabulary. Same concepts. The paper makes a stronger theoretical argument than we did—it grounds the approach in cognitive science, evolutionary biology, developmental neuroscience. We just noticed that frozen systems failed and built something different. But the convergence isn't accidental. When you actually try to deploy AI that works reliably in a changing environment, you discover that outsourced learning doesn't scale. You either build continuous learning, or you build continuous retraining pipelines. The latter creates a permanent dependency on human engineering teams that grows linearly with customer count and deployment complexity.
Here's what most AI cost projections miss: the humans. Outsourced learning requires data engineers to curate training data, ML engineers to design training runs, QA teams to validate before deployment, ops teams to monitor production, product teams to decide when "enough has changed" to justify retraining. That's a shedload of salary. And it scales with complexity. More customers means more data distributions means more retraining cycles means more humans. You end up with an ML team that grows linearly with customer count, which is a ridonkulous way to build a software business. Continuous learning flips the equation. The system learns from its own deployment. Human oversight shifts from "do the learning work" to "validate the learning results." You're checking, not doing. The paper calls this "autonomous learning." We call it "not hiring an ML team that grows linearly with revenue."
There's another angle the paper touches on, and it matters more than pure efficiency: audits. When a payer or regulator asks "why did your system do X?"—and they will—you need an answer. If the answer is "we trained on data from 2023 and haven't retrained since," that's a bad look. It implies your system is operating on stale knowledge, which it is. If the answer is "the system learned from the last 1,000 authorizations that this documentation format works best for this payer," that's a different conversation. It's explainable. Traceable. Auditable. The first time a major AI audit scandal hits healthcare (and it will), the companies with audit trails will survive. The companies operating frozen black boxes will explain to regulators why they deployed systems that couldn't adapt to changing requirements. I know which side of that I want to be on. Just saying.