The Perceptron: The 1958 Machine You’re Still Using
Image-to-text with a vision model is all the rage right now. So is throwing GPT at every classification task that walks past your desk. I get it — when the model is that good, why think harder?
But you and I have built things. We know the rule. You only add complexity as you need it. Not before.
So here’s a question that doesn’t get asked enough: what if all you actually need is a yes or no? A binary this or that? Spam or not spam. Defect or no defect. Crack in the beam image or no crack. One bit of output. That’s the entire problem.
You don’t need a hundred-billion-parameter language model for that. You need a decision-maker. Something that takes a vector of inputs, weighs them against what it has learned, and answers in one bit.
And as it turns out, somebody already built that. In 1958. Out of photocells and motors and adjustable knobs, in a Navy-funded lab in upstate New York. A psychologist named Frank Rosenblatt called it the perceptron, and it was the first machine in history that learned to make a yes-or-no decision from examples.
Here’s the part I keep coming back to. The math that machine ran in 1958 is still running today — inside every neural network you have ever used. Every neuron in GPT, every neuron in Claude, every neuron in the Cursor agent picking the right tool. Hundreds of billions of perceptron-shaped units, firing in parallel, every time a model answers a question.
The simplest decision-maker we ever built turned out to be the irreducible unit of the most complicated systems we have ever built.
That is where this series starts.
Before we go further
Over the last few months, I have been getting a lot of requests. Researchers and RSEs reaching out, asking me to help them understand how AI and agents actually work. Not the marketing version. The real version. The kind of explanation that lets them sit down at their laptop on Monday and make a smarter call about whether to use an LLM, or whether to use something much smaller.
When I went looking for material to point them at, I noticed something. Almost everything out there talks about the individual concepts. RAG. Attention. Tool use. MCP. Each piece on its own. And for some readers that is enough. But if you have shipped software for fifteen or twenty years, or written research code your entire career, that is not the gap you have. You already have the individual pieces. What you are missing is something else.
You are missing the throughline. What connects all those pieces? In what order did they arrive? What was each one a response to? In other words, how did we get here?
I kept opening tabs. Half-hour videos. Research papers. Substacks. Some good, some not, none of them in conversation with each other. And at some point I just thought — fine. I will do it.
So that is what this is. Every Tuesday, for the next six months or so, we are going to walk the timeline together. Perceptron to backprop. Backprop to convolutional networks. CNNs to attention. Attention to transformers. Transformers to GPT, to Claude, to tool use, to agents, to MCP, to the systems you are quietly building today. One contribution per week. One thread back to something you are already using.
I am not writing this for total beginners. I am writing this for the engineer or researcher who is honestly tired of pretending to understand a field they never had time to study from the ground up. The person who has shipped real systems but never learned what is actually happening behind the API call. If that is you, welcome. We are going to take this slowly, and I am going to walk you through every connection. You should not have to fill in the blanks alone.
If you only want one episode per week, this is the one. The deeper, more recent stuff I write goes out on Wednesdays and Thursdays. Tuesdays are for the bones.
Cornell, 1958
To understand the perceptron, you have to picture the world it showed up in.
It is the late 1950s. Computers exist, but they are room-sized cabinets full of vacuum tubes, owned by the military and a few universities. The word “software” barely means anything yet. The dominant view of intelligence — both in psychology and in the small group of researchers who would soon call themselves AI people — was symbolic. The brain, they argued, was something like a logic engine. To build intelligence, you wrote rules. If A then B.
Frank Rosenblatt did not buy it.
Rosenblatt was a psychologist. Not a mathematician, not a computer scientist, a psychologist. He had grown up in New York, gone to The Bronx High School of Science, then up to Cornell — undergrad in 1950, Ph.D. in experimental psychology in 1956. By 1957, he was working at the Cornell Aeronautical Laboratory in Buffalo, a contract research outfit that lived off Navy money.
And he had a different theory of what a brain was doing.
His view, drawn from the empiricist tradition, was that the brain does not arrive in the world preloaded with rules about how reality works. It arrives mostly random. It then organizes itself, slowly, through exposure. A baby does not know what a face is. A baby sees thousands of faces and the neural connections that fire when a face is present get reinforced. The ones that fire on noise get pruned. Over time, the network learns to do something it could not do at birth — recognize a face — not because anyone wrote it the rules, but because it adjusted itself.
That, Rosenblatt argued, was the more interesting question for a machine. Not how to write the rules. How to make a system that could learn them.
He wrote it down in 1958, in a paper called The Perceptron: A Probabilistic Model for Information Storage and Organization in the Brain. It was published in Psychological Review, not a computer science journal — because Rosenblatt was not building a pattern recognizer. He was building a brain model. In his own words: “a perceptron is first and foremost a brain model, not an invention for pattern recognition.”
That distinction is going to matter later. Hold onto it.
How it actually decides
Let’s walk through what the perceptron is, in the simplest possible terms.
Picture a tiny machine with two jobs. Job one: take in a list of numbers. Job two: produce a single answer — a 1 or a 0. Yes or no. Spam or not spam.
To get from the inputs to the answer, the perceptron does three things.
First, it has a weight for each input. A weight is just a number that says how much that particular input matters. If you are trying to classify an email as spam, the input “the word ‘invoice’ appears” might have a weight of 0.3, and the input “the email comes from a random address” might have a weight of 0.8. The numbers are not magic. They are just dials.
Second, it multiplies each input by its weight and sums everything up. One number out the other side. Call it the score.
Third, it checks whether the score is above a threshold. If yes, the perceptron fires — outputs a 1. If no, it does not — outputs a 0. That is the step function. Hard on, hard off, no in between.
That is the entire architecture. Inputs, weights, sum, threshold. There is no hidden complexity. No layers. No magic.
If you tried to draw it on a napkin, you would draw a row of input dots on the left, a single circle on the right, a bunch of arrows between them with little numbers (the weights) written on each arrow, and one arrow coming out — pointing at a 1 or a 0.
That napkin drawing is the entire 1958 paper.
Now — the magic part. The part that made Rosenblatt’s machine actually interesting.
The learning rule (where it gets good)
The perceptron does not arrive in the world knowing the right weights. It arrives random. The weights start as small random numbers. You ask it a question — “is this email spam?” — and at first, it will guess wrong about half the time. As you would expect from a random machine.
Here is the part Rosenblatt figured out.
You show the perceptron a labeled example — an email and the correct answer (spam or not). The perceptron makes its guess. If it gets it right, you do nothing. If it gets it wrong in the direction of “yes when it should have been no,” you slightly decrease the weights of the inputs that contributed to the wrong answer. If it gets it wrong in the other direction — “no when it should have been yes” — you slightly increase those weights.
You do that with one labeled example. Then another. Then ten thousand more. Each time, you nudge the weights in the direction that would have produced the right answer.
And here is the result Rosenblatt proved, in a piece of math called the Perceptron Convergence Theorem: if a correct set of weights exists for your problem, this procedure will find it. Not in infinite time. In a finite number of steps.
A guarantee. The machine, starting from random, will land on the right answer.
Geometrically — if you like pictures — what this means is the perceptron is learning to draw a line. Imagine all your spam emails as red dots floating in some high-dimensional space, and all your not-spam emails as blue dots. The perceptron’s job is to find a single straight line (a hyperplane, if the space has more than two dimensions) that puts all the red dots on one side and all the blue dots on the other. The weights of the perceptron describe where that line goes.
That, in 1958, was new. A machine that, on its own, given examples, found the line.
The machine itself
Here is the part that always stops me cold.
Get Cordero Core’s stories in your inbox
Join Medium for free to get updates from this writer.
Rosenblatt did not just write the paper. He built the machine. In hardware. Out of physical parts.
It was called the Mark I Perceptron. It was built at the Cornell Aeronautical Lab in Buffalo, starting in 1957, under a Navy contract called Project PARA — Perceiving and Recognizing Automaton. The Navy paid for it because they wanted a machine that could recognize things in images — silhouettes of ships, that kind of thing. Office of Naval Research, Information Systems Branch. Cold War money for a research bet on artificial intelligence.
The hardware was wild.
The input layer was a twenty-by-twenty grid of photocells — four hundred little light sensors arranged like the pixels of a tiny camera. You held a card up in front of them, and each cell measured the brightness of the part of the card it could see. That was your input vector.
Behind the photocells were five hundred and twelve association units. And the weights — the actual numbers the machine was learning — were stored as the positions of physical potentiometers. Knobs. Little adjustable dials. When the perceptron’s learning rule said “increase this weight a little,” the machine literally sent electrical signals to electric motors that physically turned the corresponding knob.
The Mark I’s memory was electromechanical. Its learning rule was implemented in moving parts.
You could, in principle, walk up to this machine while it was learning and watch its memory rotate.
The custom hardware was first publicly demonstrated on June 23, 1960. Before that, in 1958, Rosenblatt had run his ideas on an IBM 704, simulating the perceptron in software so he could show the math was right before they finished welding the physical version together.
But the hardware is the part I think about. Because when we say “neural network” today, we mean a giant tensor sitting in GPU memory. In 1958, when Rosenblatt said neural network, he meant a wall of motors turning knobs. Same idea, different substrate.
The Times article and the Navy’s framing
A day after the Mark I program was unveiled — July 8, 1958 — The New York Times ran a piece titled “NEW NAVY DEVICE LEARNS BY DOING: Psychologist Shows Embryo of Computer.” This is where one of the most famous quotes in AI history shows up. The Navy, the article reported, expected this machine to eventually be “able to walk, talk, see, write, reproduce itself and be conscious of its existence.”
That is the quote that gets pulled out every time someone wants to make 1950s AI researchers look silly.
It is worth being honest about who actually said it. The framing came from the Navy press office — they ran the press conference, they wrote the talking points, they pitched the story. Rosenblatt was there, and his own public claims about the perceptron were not exactly modest — he described it as “the first machine which is capable of having an original idea” — but the Times article is closer to military PR than to Rosenblatt’s actual paper. The paper, the actual paper in Psychological Review, is mostly careful math and mostly careful biology.
This matters because the hype around the perceptron is going to become a problem. A specific person is going to come along about ten years later, look at how oversold this thing was, and write a book that almost ends the entire field.
But that is Episode 2.
Two kids from the Bronx
One more piece of history before we leave 1958, because it is going to be load-bearing later.
Frank Rosenblatt — born 1928, Bronx High School of Science class of 1946 — overlapped at that school with another kid named Marvin Minsky. Minsky was one year behind. They likely knew each other as teenagers. They certainly knew each other ten years later, when both of them ended up at the center of the new field of artificial intelligence.
By the late 1950s and early 1960s, the two of them were on opposite sides of the most acrimonious public debate in early AI history. Rosenblatt believed in the perceptron — the bottom-up, learn-from-examples, neural approach. Minsky believed in symbolic AI — the top-down, write-the-rules approach. People who watched their conference exchanges described them as “great spectator sport.” Heated. Technical. Personal.
And here is the kicker. By all accounts, they remained personal friends throughout it. The combat was about ideas. They had grown up at the same school in the Bronx, become the two most public faces of two opposed visions of how to build a mind, and they apparently never stopped liking each other.
It was Minsky who eventually wrote the book that knocked the perceptron out of the spotlight.
We will get to that. For now, just know: two kids from the Bronx, one Cornell, one MIT, both convinced the other was looking at the brain wrong.
What it couldn’t do
I owe you a limitation before we land this. Every contribution we walk through in this series will have one. The perceptron’s limitation is the one that almost killed it.
A perceptron, the way Rosenblatt built it, can only solve problems where the two classes you are trying to separate can be split by a single straight line. Linearly separable problems. Spam versus not-spam, maybe. Crack versus no-crack in a photograph, maybe. Things where if you plot the examples in some feature space, you can draw one line and have all the yeses on one side and all the nos on the other.
The classic example of a problem the perceptron cannot solve is XOR.
XOR — exclusive or — is true when the inputs disagree (0,1) or (1,0), and false when they agree (0,0) or (1,1). Plot those four points on a square. The two “trues” sit on diagonally opposite corners. The two “falses” sit on the other two corners. Try to draw a single straight line that separates the trues from the falses. You cannot. There is no angle and no position where it works.
This is not a matter of giving the perceptron more data. It is not a matter of training it longer. It is architectural. A single-layer perceptron is incapable of representing XOR. The math says no.
In 1958, Rosenblatt knew about this kind of limit. He also believed — correctly, as it would later turn out — that stacking perceptrons in multiple layers would fix it. He did not have the tools to make those multi-layer networks learn yet. That tool would not arrive until the 1970s, in another country, in a different paper.
But before that tool arrived, someone was going to write a book about the limit. And the field was going to lose almost a decade because of it.
Why this is still inside everything
Let me bring this back to the laptop in front of you.
I said up top that the perceptron is still doing math inside Claude. I want to walk you through exactly what I meant.
A modern neural network — the kind that runs inside GPT, Claude, Gemini, a Cursor agent, anything you have touched in the last three years — is, at its bottom, just a stack of perceptrons. Different name now. We call the individual units neurons or units, not perceptrons. And the activation function has changed; we no longer use the hard step function Rosenblatt used. We use smooth, differentiable functions — ReLU, sigmoid, GELU. That single change is what made multi-layer networks trainable, and it is the move that took us out of the AI winter Episode 2 sets up.
But underneath the new vocabulary, the unit is the same shape. Vector of inputs. Vector of learned weights. Multiply. Sum. Pass through an activation function. Output a number that becomes the next layer’s input.
Stack those units in layers, connect the layers, and you have a deep neural network. Add attention — the move from Episode 9 — and you have a transformer. Train a transformer on most of the text on the internet, and you have an LLM.
The numbers got bigger. The architectures got smarter. The substrate moved from photocells and motors to GPU silicon. But every single time Claude takes a token in and produces a token out, hundreds of billions of these perceptron-shaped units fire in parallel inside the model, each one doing exactly what Rosenblatt’s machine did in 1958. Inputs times weights, summed, passed through a threshold-ish function, output to the next layer.
You are not using a different kind of math than the Mark I used. You are using the same kind of math, in such a large quantity that emergent behavior shows up.
Watch a coding agent for a minute and you will see it. The agent reads a chunk of your code. It has to decide — should I open the file or call grep first? Run the test or read the failure? Each of those decisions is the output of weights pushing one option above another. Yes or no on each branch. Hundreds of millions of those tiny verdicts a second, stacked deep enough that what comes out the top reads like a plan.
The same thing is true under the hood of every agentic system you have looked at this year. Tool routing. Context selection. Whether to retrieve, whether to ask a clarifying question, whether to stop. Each one is some pile of perceptron-shaped units coming down on a side. The difference between an LLM and a 1958 perceptron is not the kind of decision. It is the depth of the stack and the smoothness of the curve.
Which brings us back to the question you and I started with. What if you only need a yes or no? One bit of output. The same binary classification problem the Mark I was solving with photocells and motors in 1960.
You do not need a hundred billion neurons for that. You might need ten. You might need one. The engineering instinct that whispered “only add complexity as you need it” — that instinct is right. Sometimes, the right amount of model is not a model at all. Sometimes the right amount is a logistic regression. Sometimes, honestly, the right amount is a single perceptron.
That is not a knock on the big models. It is an honoring of the truth that they are made of small ones.
The single perceptron is to modern AI what the transistor is to modern computing. Not the final product. The irreducible unit from which everything else was assembled.
When you understand the irreducible unit, everything else stops looking like magic and starts looking like engineering.
The perceptron got something fundamental right and something fundamental wrong, both at the same time. Rosenblatt found a way to make a machine learn from examples — the first time in history that was actually achieved. He also made claims it would not live up to, and his architecture left a limitation that critics could and would exploit.
Both of those things are part of how we got here.
Next Tuesday: what happened when Minsky and his MIT colleague sat down to write a book, and how a single set of mathematical proofs about XOR almost ended neural networks as a field for an entire decade.
If this series resonates with someone you work with — a colleague who keeps almost-getting around to learning how their AI tools actually work, or a researcher who is using LLMs every day and quietly suspecting they should understand them better — send it their way. The goal of this is that no one feels left behind in their own field.
If you want to follow along, every Tuesday for the next six months I am walking one contribution in the timeline. Wednesday and Thursday articles go deeper on whatever I’m building or watching that week. You can sign up for the Substack or follow on Medium — both will run the full series.
Cordero is a senior research software engineer at the Scientific Software Engineering Center at the University of Washington’s eScience Institute. If this landed, send it to the researcher in your department who keeps saying “I really need to sit down and learn this stuff” — Tuesday at a time, that is exactly what we are doing.
