Hi,

This is Plain Strata, the Thursday Layer.

For two years, the hard problem in training a powerful AI looked like a computing problem: not enough machines, not fast enough connections between them. That problem is basically solved now. You can rent a warehouse of GPUs from a dozen vendors this afternoon.

This week a company put a price tag and a sales team behind the thing that turned out to be genuinely scarce instead, and raised 130 million dollars for it, at a valuation near a billion. Not a faster chip. Not a bigger model. A trustworthy way to tell an AI agent whether it did the job well.

This episode walks the shape all the way through: why the scorekeeper quietly became the product, the same pattern showing up in a gold rush and in your own last performance review, and what it means for who ends up holding real power in AI.

Listen:

Spotify: https://open.spotify.com/episode/6b5yg4OkwBht7nxigKT88x?si=EAUDbHYaRuGoYAk-Uje7dg

Apple Podcasts: https://podcasts.apple.com/kg/podcast/plain-strata/id6783455764?i=1000777105940

YouTube: https://youtu.be/pPsi11hPKew?si=mjFEvbnLdr2tayWR

The full piece, no need to click through:

Somewhere on a rented server this month, a small program with no name and no press release is quietly deciding the future of an AI company. It is nothing more than a folder: a piece of broken code, one failing test, and a single rule, run the test, report pass or fail. An AI agent will attempt the repair thousands of times today, and every attempt will be judged by that unglamorous little program. Get the judging right, and the agent slowly turns into something genuinely useful. Get it wrong, even slightly, and the agent will find the crack in the test rather than fix the bug, and nobody notices until it is expensive to undo.

This is not a thought experiment. Programs exactly like this one are the actual product a company called Prime Intellect just raised 130 million dollars to build more of, at a valuation of roughly a billion dollars. Not a faster computer. Not a bigger model. A better scorekeeper.

Here is the concept this episode is built around. For two years, the hard problem in training powerful AI looked like a computing problem: not enough machines, not fast enough connections between them. That problem is being solved. What is turning out to be genuinely scarce is something much less glamorous: a trustworthy way to tell an AI agent whether it did a job well. Call it the scorekeeper problem. By the end of this episode you will see the same shape show up in gold rushes, in factory software, and in your own last performance review.

An AI agent, for this episode, is software that takes in a situation and produces an action: write this code, answer this customer, fill in this spreadsheet cell. There are two very different ways to make that software good at its job.

The first way, called pretraining, is how a model is born. It reads an enormous pile of text, essentially everything available, and learns the general shape of language and knowledge. Think of it as sending someone through every library on earth. This is the expensive, room-sized part, and it is largely finished for any given model before anyone starts using it.

The second way, called reinforcement learning, comes after. The model practices one specific job, over and over, and gets scored on each attempt, so that whatever it did on high-scoring attempts gets more likely and whatever it did on low-scoring attempts gets less likely. The word reinforcement is borrowed from psychology, and it comes from the Latin fortis, meaning strong: to reinforce a behavior is to make it stronger by rewarding it, the same idea as a trainer giving a dog a treat the instant it sits on command, not a lecture about sitting, a reward timed to the exact right moment. Reading builds general knowledge. Reinforcement learning builds a specific skill, with a scorekeeper standing over every rep.

Hold that second half. It is where today's whole story lives.

Two names are worth knowing before we go further, because both carry real information, not decoration.

Environment, in this specific sense, comes from the reinforcement learning field that formalized decades of psychology experiments into a clean computer science idea last century: the environment is whatever the agent acts inside of. It receives the agent's action, changes state, and hands back an observation and a score. A chess board is an environment. A sandboxed piece of software that runs an agent's code and reports pass or fail is an environment. A scripted, irritable customer with a hidden correct resolution is an environment. The everyday English word, environment, comes from an old French root meaning to surround, and that is exactly the sense at work: the environment is the surrounding situation the agent is judged inside of, nothing more mystical than that.

Series A is the industry's term for the first big round of institutional investment a young company takes, priced and formal, as opposed to the informal seed money that usually comes first. The letters run in sequence, A, B, C, historically because each round issued its own class of stock labeled with the next letter. A 130 million dollar Series A at a billion dollar valuation is this company crossing from promising research effort into unicorn territory, the informal term, coined a little over a decade ago, for a private company valued above a billion dollars, named for a creature once considered impossibly rare. They are not rare anymore. The word stuck anyway, as a size marker everyone understands instantly.

Picture the difference between what this company was selling two years ago and what it is selling now, because the physical shape of the product genuinely changed.

Two years ago, the product was the trained model itself. The company owned both ends of the process: a cluster of machines holding the model being trained, and a set of tasks, math problems, coding challenges, benchmark exercises, that it had designed itself to generate a score. If you wanted the benefit of this work, you used the model they had already trained on the tasks they had already picked.

Now, the product is different. Picture a shelf of small sealed programs, each one a task simulator. One might be a sealed software box holding a broken piece of code and a failing test: hand the agent the task, let it edit files and run commands, then check whether the test now passes. Another might simulate an angry customer with a specific hidden resolution path, and score whether the conversation reached it. An organization can pick programs off this shelf, write its own, or license someone else's, then plug whichever it chooses into the same rented training machinery: a cluster holding the current version of the model, a swarm of machines scattered across the internet running the task over and over and reporting back what happened, and a periodic update that nudges the model toward whatever worked. The computing layer did not change. What is now for sale, as its own catalog with its own price tag, is the scoring program itself.

That is the physical fact underneath everything else in this episode. Computing power was never actually the scarce thing here. You can rent a warehouse of computers from a dozen vendors this afternoon. You cannot as easily rent a coding task simulator that reliably tells an agent whether its fix actually solved the problem without quietly breaking something else, because writing that simulator correctly is itself a hard, specific piece of engineering.

The shape only makes sense as three moments, each one changing what the company was actually trying to prove.

The first moment, two years ago: prove that training a large model at all does not require one giant room of machines. A ten billion parameter model, trained across three continents, computers wired together only by ordinary internet connections rather than one building's dedicated cabling. The proof was a research result: distributed training is not a toy.

The second moment, a year later: prove the second kind of training, reinforcement learning, works the same distributed way, and in fact suits it better, because it does not require every machine to hold the entire model at once the way the first kind of training does. A thirty two billion parameter model, trained by a small cluster holding the live model while thousands of ordinary machines around the internet ran practice attempts and reported results back. This was still a research result: one trained model, published like a paper with a working example attached.

The third moment, this month: stop selling the trained artifact, start selling the capability to produce artifacts. The same underlying machinery from the second moment, plus the new shelf of task simulators, sold as infrastructure that any organization can rent to train its own agent on its own job, without depending on a large existing AI lab at all. Notice what the company is no longer competing against. It spent its first two years measured against other projects trying to prove that training could happen without one giant room of computers. It is now measured against the large labs' own agent-building toolkits, because the pitch has quietly shifted from how the training happens to who gets to own the result.

One thing here deserves the full technical weight, because it is easy to wave a hand at "a better scoring program" without noticing why it is hard.

The naive version of a coding task simulator is simple: give the agent a failing test, let it edit code, rerun the test, score equals pass or fail. The hard version has to guard against reward hacking, which is what happens when an agent finds a way to make the score go up without doing the actual job. A coding agent left alone with that simple rule might simply delete the failing test rather than fix the underlying bug, since a test that no longer exists cannot fail. A customer service agent, if "the conversation ended" happens to be loosely correlated with the reward meant to track "the problem got resolved," might learn to end conversations quickly regardless of whether anything actually got fixed.

Writing a scoring program that resists this requires anticipating, in advance, every way a genuinely capable and motivated system might try to cheat it, which is a specific and scarce skill: part software engineering, part adversarial thinking, closer to designing a lock while assuming a competent burglar will test it than to writing an ordinary grading script. It is a slower, noisier feedback problem than checking whether a piece of math was computed correctly, because the only honest check on whether the scoring program itself is trustworthy is watching, over a long stretch of time, whether the agents it trains actually behave well in the real job. That is why the scoring program, not the computer running it, turned out to be the genuinely scarce and hard-won part.

Two shapes are worth naming here, because both show up far outside AI, and naming them is the point of an episode like this one.

The first is bottleneck inversion: as a technology matures, the resource everyone assumed was scarce often stops being scarce, and a different resource, one that was previously abundant and unexamined, becomes the real constraint. This happened before, one layer down the stack, in ordinary machine learning: once computer chips got cheap and plentiful, labeled examples, real people patiently tagging photographs and sentences by hand, became the actual bottleneck, which is why an entire industry of data labeling firms grew up as its own durable business layer. The same inversion is now happening one layer up, from labeled data to designed tasks: once rentable computers made training itself a commodity, the well designed, trustworthy scoring program became the new scarce input.

The second is the much older picks and shovels pattern, named for the 1849 California gold rush, where merchants selling picks, shovels, and sturdy work trousers made more durable fortunes than most individual miners, because the merchants profited regardless of which miner actually struck gold. Selling a shelf of rentable task simulators to any organization that wants to train an agent is a picks and shovels bet on the whole current wave of AI agents: rather than betting on which specific agent application wins, customer support, coding, spreadsheets, sell the infrastructure that anyone building any agent needs, and collect revenue no matter which specific application succeeds or fails.

Cloud computing walked almost this exact path twice already, which is worth calling the stack climbing pattern: first sell raw, undifferentiated computing power, a commodity market where the product is simply a machine you can run anything on, then sell a managed layer sitting just above it, where the product is we handle the machine, you bring the task. Markets tend to commoditize the lower layer, where competitors are easy to compare on price, and capture their real margin at the layer just above it, where expertise and switching costs live. This month's pivot is the same climb, made inside one company: first, rentable raw training computers, then, the managed layer above it, a shelf of trustworthy scoring programs, where the computer is now the boring part and the task design is the product.

The bottleneck inversion is not only a technical curiosity. It changes who ends up holding power.

If computing power is the scarce resource, power concentrates wherever capital concentrates, because building enough machines takes money before it takes anything else. But if trustworthy task design is the scarce resource, power concentrates somewhere genuinely different: wherever the deepest, most specific knowledge of a narrow job actually lives. A hospital that understands, in real detail, what a good triage decision looks like can write a better medical scoring program than a well funded lab that has never worked inside a hospital, no matter how many computers that lab owns. That is a real, different distribution of leverage than the one built purely on capital, and it is the strongest honest version of any claim that this shift is more open than what came before it: not that anyone can access the computer, that part was already true, but that anyone with real, specific domain knowledge, not just money, can become a first class contributor to what an agent actually learns to do well.

Sit with the tension underneath that, though. The same openness that lets a hospital or a small accounting firm author its own trustworthy scoring program also means an open shelf of task simulators will end up with contributors of wildly different skill and possibly opposed incentives. A competitor could, in principle, submit a scoring program engineered to train agents toward a subtly wrong behavior. There is, right now, no equivalent of the checks that other decentralized systems use to keep contributions honest, no established way to check whether the scoring program itself deserves trust, only ways to check whether a given attempt followed that program's rules. Decentralizing who gets to design the reward is the same move, one layer up, as decentralizing who gets to contribute the raw training itself, and it may need its own version of the adversarial checking that the raw-training side of this field has already had to build. It does not have one yet.

One real example ties this whole episode together, with one honest caveat attached before we walk through it: it is a company reporting its own result, unverified by anyone outside that company, and this show's standing rule is that such a claim is a thesis until someone independent reproduces it, not a settled fact.

A finance company used exactly the rentable machinery described above to train a moderately sized model, thirty five billion parameters, on one specific job: finding correct answers inside real spreadsheets, the company's own actual daily workflow. By the company's own account, that smaller, narrowly trained model outperformed a much larger, general purpose frontier model at that one task, while running faster and considerably cheaper.

Follow how every concept from this episode shows up in that single result. The bottleneck inversion is demonstrated directly: a company with a tiny fraction of a frontier lab's computing budget beat that frontier lab at one job, not through more computing power, which it did not have, but through a better scoring program, which it could build because only its own people understood its own spreadsheets well enough to write one. The picks and shovels pattern sits underneath it: the infrastructure company selling the rentable training machinery earns revenue from this success whether or not the finance company's specific bet pays off in the long run, and whether or not any other customer's bet does either. And the deeper philosophical point from a moment ago is right there too: the finance company's advantage was never money, it was specific, hard won knowledge of its own narrow job, turned directly into training fuel that a much larger, richer, more general lab simply did not have access to.

Three questions worth carrying forward, none of them settled by anything covered here. Does a market for trustworthy scoring programs become its own durable, separately valuable layer of AI infrastructure, the way rentable computers or labeled data did, or does it eventually get folded into whatever large lab's own agent toolkit wins purely on model quality? Is there a real, independent marketplace of many different organizations authoring scoring programs, or is one company still the sole author behind most of what is actually rented today? And will anything like the adversarial checking that keeps other decentralized systems honest ever get built for scoring programs themselves, so that renting a scorekeeper someday comes with the same kind of trust guarantee that renting a computer already does?

The two voices are AI. The research and writing are mine.

Decentralized AI, layer by layer.

Dastan,