--- title: AI agents are still in the line-shaft era description: Around 1900, one steam engine drove every machine in a factory through shafts and belts. Justin Schroeder says AI work runs the same way today, with one big model behind every task. His answer is small agents with one job each, and factory history says they spread only once there is a standard. date: 2026-11-14 tags: AI agents, domain-specific agents, agent standards, evals, history of technology --- "We are sort of in the line shaft era of agents." That is how Justin Schroeder describes AI work today. Around 1900, a factory had one big steam engine. Rotating shafts carried its power through the walls, and a belt ran down from the shaft to every machine. Today, he says, we put one big model in the middle and tie every task back to it. His answer is domain-specific agents: small agents, each built for one or two tasks. The comparison goes further than a nice picture. Factories got the electric motor, and for decades they kept the same layout. What finally changed them was a plug: one voltage and one frequency, so anyone could buy a motor and put it at a machine. Agents have no plug yet. That part of the talk is about where we stand right now. Schroeder runs Standard Agents, a small company that wants to write that standard. He opens with a warning: the talk contains forecasts, and forecasts age badly. His first slides are French postcards from 1899 that imagined life in the year 2000. The series, called *En l'an 2000*, has firemen with wings, a bus pulled by a whale and a school of the future. Some missed, some came eerily close. Keep them in mind for the end. ## One engine, a belt to every machine A line shaft is a long rotating bar that carries power from one engine to many machines. In the factory photos Schroeder shows, the shafts run along the ceilings and under the floors. Each workstation has a belt that climbs to the shaft. Stop the engine and every machine stops. The belts caught clothes and hands. It was wasteful and dangerous, and it worked. His point is that AI work has the same shape. One large model sits in the middle. Skills (packaged instructions a model can load) and MCP servers (a standard way to plug a tool into a model) are the shafts. Every task, from email to code, gets a belt back to that model. Skills and MCP are not bad, he says. They are simply how work gets done today. What he wants instead is what factories got later: every workstation with its own power.

A factory in 1900, AI work now

The same shape, a century apart

Factory, around 1900AI work, today

PowerOne steam engine in the basementOne large model in the middle

DistributionLine shafts in the walls and floorsSkills and MCP servers

Each workstationA belt up to the shaftEach task tied back to the model

The riskBelts and shafts everywhereOne agent that can reach everything

The comparison is Schroeder's. The rows are mine, from his slides and words.
## An agent is the software around the model Ask a room what an agent is, Schroeder says, and every answer is different. His own is short: deterministic software that uses the non-deterministic results of a model to reach a goal. That is also what people call a harness, and he thinks the two words now mean the same thing. Building one looks easy. You call the model, it asks for a tool, you run the tool and feed the result back. That loop fits in a few lines. Making it reliable is the hard part: keeping the loop alive across slow calls, swapping model providers, and picking up a run that failed halfway. He builds the agent up in layers, from the model to the rules. The top layer matters most for a business. A coding agent like Codex may take as many steps as it likes. A company that wants one process done does not want that. For them, an agent that keeps running is a bug.

What Schroeder counts as an agent

The model is one layer, the rules sit on top

  1. Agent rulesHow many steps it may take, and when it must stop.
  2. HooksCode that runs at fixed points, every time.
  3. ToolsFunctions, small prompts for side tasks, and sub-agents.
  4. System promptWho the agent is and what it is for.
  5. The modelThe base everything else stands on.

Often a file system and code execution come with it.

Redrawn from the layers he builds up in the talk.
## A heating company doesn't want one agent for everything The common advice, Schroeder says, is not to build agents at all. Build MCP servers, give every employee a chat assistant, and let the big model do the rest. Yet across ordinary American businesses, everybody builds agents. Even teams that ship MCP servers often have an agent behind each call. He sees three reasons. - **Integration.** Businesses want the work wired deep into how they already operate. - **Trust.** They don't trust one model that can touch everything to do only what it should. - **Efficacy.** They don't care how the work is done. They want it done right, every time. His example is a heating and air conditioning company. It runs on dozens of small processes: local campaigns for when the air conditioning breaks, lead capture, customer onboarding, sales forecasts. Each process is a line with a start and an end. Together, they are the business. That company has no interest in one agent that takes over all of it, even one that works. The processes already work, so handing them all over is too much risk. What it will buy is one process done perfectly. Take fleet maintenance. A truck breaks down and someone reports it. Someone sets the priority and books a repair. The records get updated, and the truck goes back on the road. That line, and only that line, is the agent's job.

One process at a heating company

The agent's whole job is one line, start to end

  1. ReportA truck has a problem, and the issue is logged.
  2. AssessSomeone sets the priority.
  3. ScheduleA repair is booked.
  4. UpdateThe records are changed.
  5. ReturnThe truck goes back to the fleet.

One start, one end. Nothing else is the agent's business.

From the talk's example of a heating and air conditioning company.
## A Gmail agent can't go check Twitter Trust is easiest to see with email. Schroeder compares two setups. The first is a general assistant with a Gmail skill. It got some instructions on Gmail, and you hope it does the right thing. The second is a Gmail agent. It knows the whole Gmail API and has no other tools. Now ask each one, while it writes an email, to go check Twitter. The Gmail agent says no. It can't, because it has no tool for that. The general assistant says yes, and might do much more. His own exaggeration: it reads that some popular tools were hacked and shuts down production "as a preventive measure" while it checks your mail. "It's a little bit of hyperbole," he says, "but not that much." So he draws many small agents: a Gmail agent, a Figma agent, a Google Sheets agent. One orchestrator hands them the work, possibly over MCP. He points to a talk on the inside of one popular agent, which hands its subtasks to tiny agents of its own. None of this is a new idea, he adds. Engineers have long known the principle of least privilege (give each part only the access it needs) and separation of concerns. His picture for it is Apollo 11 launch day. A few astronauts flew to the Moon, and behind them stood a whole team of experts, each in one field. I wrote about the same limit from the other side in [An agent can carry your request, not your authority](/notes/agents-carry-requests-not-authority.html). A tool the agent doesn't have is a rule it can't break.

The same request, two setups

The agent with one tool can only do one thing

A Gmail skillA general assistant
  • Some instructions on how to use Gmail
  • Every other tool still in reach
  • You hope it does the right thing
A Gmail agentOne job
  • Knows the whole Gmail API
  • Has no other tools
  • "Check Twitter?" It can't.
From the talk's Gmail example. The red marks the risk he describes, not a measured failure.
## A weak model can win a narrow job Efficacy is the third reason, and it starts with a problem: you can't trust public benchmarks. Schroeder shows leaderboards where a cheap model beats a top one. He quotes a post that says the people hurt most by benchmarks are those too busy to try the models themselves. That is exactly the heating company. He calls it the streetlight effect. A man who lost his keys searches under the streetlight, because that's where he can see, not because he lost them there. Public scores are the streetlight. The answer is somewhere else: an eval of your own process. A Gmail agent with one job is easy to test. You send it emails and check that it handles each one right, every time. Testing one big assistant on the same task is much harder, because its context is full of everything else. Small agents also let you use what people call jagged models. A model can be great at one thing and poor at the rest, with no pattern you could guess. Schroeder runs a side project that gives every model the same prompt for a small 3D world. The world he liked best came from a Tencent model that, in his words, is bad at almost everything but amazing at 3D. The whole world cost 60 cents to generate. Cost follows the same logic. Schroeder says DeepSeek V4 Flash is 137 times cheaper per task than Claude Fable. He is clear that it won't work like Claude in general. On a small task, like tracking a fleet of trucks, it is good enough. His team's own tests show much lower token spend on small tasks, but he says none of those numbers are public yet.

Narrow jobs, cheaper models

For one small task, the cheap model is enough

137×cheaper per task: DeepSeek V4 Flash against Claude Fable

60 centsfor a whole 3D world, from a model weak at almost everything else

Both are the speaker's figures. His team's token tests aren't public yet.

From the talk. Model names come from YouTube's automatic captions.
## Thirty years of the same factory Here the history comes back, and Schroeder corrects his own story. The electric motor did not change factories, at least not at first. Owners put a motor where the steam engine stood and kept every shaft and belt. That went on, he says, for about 30 years after the induction motor. The numbers back him up. Nikola Tesla patented his induction motor in 1888. In 1899, the economist Paul David found, motors supplied less than 5% of the power that turned machines in American factories. The rest still came through shafts and belts. Schroeder's version of today: upgrading the model in the middle of all your skills. It works, it's a little more efficient, and nothing else changes. What changed factories, he says, was standards. Before them, there was no agreement on direct or alternating current, on frequency, on voltage. A factory that wanted an electric motor had to build one to fit its own power. In 1918, London alone had ten different frequencies. Once North America settled on 60 hertz, and Europe on 50, a motor became a standard product. Schroeder shows a bench mill from 1910 and one from 2021. In his words, they are interchangeable on the power side. Economists tell a fuller story, and I told it in [the note on Levi's](/notes/levi-strauss-rebuilt-the-process-before-the-agents.html). The big gains came when factories were rebuilt around a motor at every machine: lighter buildings on one floor, and machines laid out freely. Both readings fit together. The standard made a motor at every machine affordable. The new floor plan is what made it pay.

Electricity on the factory floor

The motor came first, the plug made it spread

  1. Before 1900Line shaftsOne steam engine, a belt to every machine.
  2. 1888The motorTesla patents the induction motor.
  3. 1899Same factoryMotors drive under 5% of the machinery, often in the engine's place.
  4. 1918No common plugLondon alone has ten different frequencies.
  5. ThenThe plug60 hertz in North America, 50 in Europe. A motor at every machine.
The order is from the talk. The dates and figures are from Paul David's 1990 paper and Wikipedia, not from the talk.
## What an agent plug would hold There is no standard for building an agent today. "We are completely inventing this," Schroeder says. He lists what agents need before they can spread like motors did. The tension in the list is on purpose. An agent should not depend on one vendor, yet each install should run the exact same model. Not a similar one: the same model, from the same provider, at the same quantization. Quantization is a compressed version of a model's weights, which runs cheaper but can answer differently. If any of them changes, the evals you ran may no longer hold. Composability exists in pieces: some protocols already let agents talk to each other, and he says we need more. His company wants to publish an open-source spec for building domain-specific agents. The goal is a runtime you install agents into, with competing runtimes, as there are for Node or Python.

What agents need, by Schroeder's list

Five rules for an agent you can install

NeedWhat it means

SpecificBuilt for one business process

HarnessIt ships whole and editableSame behaviour on your machine as on mine

PortableInstalled like a packageWith npm or pip

PinnedNo single vendor, one exact modelSame model, provider and quantization

ComposableA standard way to talk to other agentsSome exist. He wants more

His list from the talk. The one-word labels are mine.
## His postcard from the future Schroeder ends with forecasts of his own, so here is his postcard. He predicts fewer tools that let you pick your model. "Who cares?" he asks. The heating company certainly doesn't. Choosing a model is a burden to them; they only want the process done right. In the questions, someone asks about governance. Models change all the time, so how does a company keep control of a fleet of agents on different models? His answer is a platform where the IT department sees every small agent. Each one has its own evals: private tests on its own process, not public scores. Then comes the part I find most useful. If an agent does its process right, don't upgrade it. Leave it alone until its model is retired.

The factory path, laid over agents

If history repeats, the standard comes last

  1. TodayOne big modelEvery task tied to it through skills and MCP. The line shaft.
  2. Each new modelSwap the engineUpgrade the model in the middle, keep the rest.
  3. NextSmall agentsOne job each. A motor at every machine.
  4. ThenThe plugA standard to install and run them anywhere.
His forecast, drawn as the factory story he tells. The order is a projection, not a measurement.
A few things to keep in mind before you treat the postcard as a map. - **Who gains.** Schroeder sells the standard he argues for. His company plans the spec and the runtime. The argument may still be right. - **His numbers.** The 137 times and the token savings come from his own tests and his own choice of task. Nobody outside has checked them yet. - **The history.** A standard alone did not fix the factories. They also had to be rebuilt around the work. A plug for agents won't help a team that keeps its old process. - **The cost of small.** Ten small agents on ten models means ten things to watch. His answer, private evals and no upgrades until a model is retired, is sound. It is also work that someone has to do. The postcards from 1899 got some things right and many wrong, and nobody could tell which at the time. Small agents with one job each feel right to me, for the trust and the evals more than for the token bill. What their standard will look like is still open. ## Try it The talk runs 25 minutes. The line-shaft comparison starts at 2:18, the Gmail example at 10:24, jagged models at 15:42, and the standards at 18:53. - Agentic AI Foundation, [Why Domain-specific Agents Are the Future](https://www.youtube.com/watch?v=wIPr9GmLRaQ), Justin Schroeder of Standard Agents. - Paul A. David, "The Dynamo and the Computer", American Economic Review, 1990: the classic paper on why electric motors took decades to pay off. - [Levi's rebuilt its development process before it added agents](/notes/levi-strauss-rebuilt-the-process-before-the-agents.html), the new factory floor for agents. - [An agent can carry your request, not your authority](/notes/agents-carry-requests-not-authority.html), on limits an agent cannot cross. - [Fork your agent's harness, keep the winner](/notes/fork-your-agents-harness.html), on testing a harness against your own task. Then pick one process in your work with a clear start and end. Write down what an agent for it would need, and what it should never touch. If the second list comes out longer than the first, tell me which process it was.