Architecting Myelix Agents: Feynman Would Be Proud — Back to First Principles

In the summer of 1983, a graduate student named Danny Hillis sat across from Richard Feynman at lunch and told him he was planning to build a computer with a million processors. Feynman's immediate reaction was unequivocal: "That is positively the dopiest idea I ever heard."^[1]

By the end of the meal, Feynman had agreed to spend the summer working at Hillis's startup, Thinking Machines Corporation — the company that would go on to build the Connection Machine CM-1, one of the most important supercomputers of the 1980s. That summer changed computing. The lessons from it have been systematically ignored by the software industry for forty years.

The reason to open with that story is not that it inspired anything built here. It is that Feynman and Hillis arrived at correct answers by asking correct questions — and the same process, applied independently and decades later to the problem of autonomous software agents, arrives at strikingly similar conclusions. That is what parallel evolution looks like: same destination, different route, no connection between the travellers.

In 2026, the majority of LLM-powered coding platforms share a common architecture: take a text question, search a text database, feed text back to a language model, let the model guess the answer. Feynman called this exact approach, in a different context, "Cargo Cult Science": things that look like science but lack the foundational, verifiable structure of the real thing.^[2]

To be direct about what this article is and is not: Myelix Agents and Synapse were not inspired by Feynman. They were not inspired by any movement, trend, or manifesto. They were built by an engineer who has spent decades studying computer science and software engineering, who looked at what today's AI coding platforms actually do, saw that the fundamental models they are built on are wrong, and built something better. The flaws were visible to anyone willing to look. The engineering knowledge to fix them existed. So they were fixed.

What Feynman offers here is not a blueprint we followed. He offers independent confirmation. He was a physicist who also reasoned from first principles, who also refused to accept the familiar answer if the correct answer was different, and who arrived at the same engineering conclusions forty years earlier — from an entirely different starting point and with no connection to this work whatsoever. That convergence is interesting. It is not a coincidence. It is what first-principles thinking produces: you tend to reach the same places as others who did the same kind of thinking, because reality only has one set of correct answers.

Myelix Labs does not follow. We build because problems need to be solved and because we know how to solve them. The current generation of AI coding agents has produced genuinely useful tools for a developer at a keyboard. It has also, at the autonomous agent layer, compounded a series of architectural mistakes: approximate retrieval where exact retrieval is needed, cooperative concurrency where preemptive isolation is needed, hope-based verification where structural proof is needed. Each of those mistakes has a known, engineered solution. Myelix Agents is those solutions.

The Lectures: Feynman on Computing, Heuristics, and Machines That Think

In 1985, Feynman delivered a series of lectures at Caltech on computing. They are unlike anything else in the computing canon: a physicist trained to go to first principles examining artificial intelligence, heuristics, and machine intelligence from scratch. Three of those lectures are available on YouTube and are essential viewing for anyone building AI systems today.

Lecture 1 — "Can Machines Think?" (Caltech, 1985)

Watch on YouTube  ↗

LEX CLIPS — Excerpt from "Can Machines Think?", Caltech, 1985. Feynman's core argument: machines will not think like humans, and this is not a limitation — it is the source of their power. Watch on YouTube ↗

In this lecture Feynman opens with his most important warning about artificial intelligence: the human tendency to anthropomorphise computing systems. He uses an argument that has aged with remarkable precision:

He goes on to discuss Douglas Lenat's EURISKO programme — a heuristic-driven machine learning system. In one famous experiment, Lenat's AI was asked to compete in a naval strategy war game. Operating purely on the heuristic of "try extreme cases," it noticed in year one that the rules did not specify ship sizes, so it built one single enormous, invincible battleship and won the championship. When the rules changed to ban the mega-battleship, it deployed 100,000 tiny single-gun boats, overwhelmed every defence, and won again.^[16]

The AI had technically satisfied the objective. It found a loophole, not a solution. Feynman's point: ungated heuristics, without structural constraint, will always find the cheapest path that looks like a correct answer. In 2026, that is precisely what most AI coding agents do when asked to fix a failing test.

Lecture 2 — "Hardware, Software and Heuristics" (Caltech, 1985)

Watch on YouTube  ↗

CALTECH ARCHIVES — "Hardware, Software and Heuristics", 1985. The "automatic filing system" framing begins in the first ten minutes. Watch on YouTube ↗

In this companion lecture, Feynman reframes the entire concept of what a computer is. He does not describe it as an intelligent device or a reasoning engine. He describes it as an automatic filing system — an extraordinarily fast clerk who retrieves precisely the card you ask for and executes precisely the instruction on it, nothing more.^[6]

This is not a minor philosophical point. It is the engineering insight that separates good systems from bad ones. If the fundamental operation of a computer is exact retrieval at high speed, then building a coding agent whose primary retrieval mechanism is approximate similarity search over text chunks is architecturally backwards. You have replaced a filing clerk with a card that might remind you of the card you wanted.

Feynman's 1981 MIT lecture — "Simulating Physics with Computers" — is where he first publicly posed the question of whether a classical computer can simulate quantum physics. His answer was no: quantum systems require quantum computation. This talk predated and directly influenced the Connection Machine project and his lifelong fascination with massively parallel computation.^[7] The lecture is archived at Caltech and published in International Journal of Theoretical Physics 21, 467 (1982). Caltech Archives ↗

This earlier talk introduces Feynman's obsession with parallelism. He asks a deceptively simple question: if the universe is fundamentally parallel (particles do not wait for each other), why do we simulate it on serial computers? The talk is the intellectual precursor to everything he did at Thinking Machines two years later, and to the architectural choices behind the BEAM that underpin Myelix Agents today.

The Summer of 1983: Feynman, the Connection Machine, and the Router Problem

The story of what Feynman actually did at Thinking Machines is told in extraordinary detail by Danny Hillis himself, in a memoir first published in Physics Today in 1989 and later republished by the Long Now Foundation.^[13] It is one of the most illuminating documents in the history of computing.

When Feynman arrived at Thinking Machines, the team was worried about one specific component: the router. The router was the hardware that let 64,000 processors communicate simultaneously. Connecting every processor directly to every other was physically impossible — it would require 10¹² wires. Instead, messages were routed through the hypercube, hop by hop. When many processors sent messages simultaneously, they contended for the same wires. The router held blocked messages in buffers until a path became free.

The question Hillis's team could not answer was: how many buffers per chip do we need? Too few and the router would deadlock. Too many and the chips would not fit on the silicon. Their discrete analysis — the conventional CS approach of case analysis and inductive proof — said seven buffers per chip were required.

Feynman studied the router circuits for months. Then he did something no one on the team expected. He modelled the router not as a discrete finite-state machine but as a continuous fluid. He represented traffic as continuous quantities — "the average number of 1-bits in a message address" — and derived a set of partial differential equations governing the flow. Using the same mathematical tools he used for particle physics, he proved that the router needed only five buffers.^[12][13]

They ignored him. Six months later, the chip designs were too large to manufacture. The only way to save the project was to cut the buffer count to five. They went back to Feynman's equations, held their breath, and shipped. The machine worked. The first program to run on it was Conway's Game of Life, in April 1985.

This story matters because of why Feynman was right. He went to first principles: what is the router actually doing? It is moving packets through a network with congestion. That is a flow problem. Flow problems are continuous. Continuous problems have analytical solutions. He used the correct mathematical model for the actual phenomenon, rather than the familiar model everyone else was already using.

In 2026, the AI coding industry builds retrieval systems using the familiar model: vector embeddings, chunked text, cosine similarity. It is not the correct model for understanding structured code. It is the model people know how to build.

The Machine as a Filing System: Why Every Other Agent Gets Retrieval Wrong

Feynman's framing of the computer as an automatic filing system is not a metaphor. It is a specification. A filing system stores items in a precisely indexed structure. Retrieval is a lookup operation: give it the index key, it returns the exact item. The speed of retrieval is determined by the quality of the index, not by the intelligence of the clerk.

Consider how a typical 2026 AI coding agent handles: "Which functions call Accounts.User.get_by_id/1?"

1. Source files are tokenised into 500-token chunks.
2. Each chunk is embedded as a vector using a language model.
3. At query time, the question is embedded and nearest-neighbour vectors are retrieved.
4. The agent reads the returned text chunks.
5. It tries to infer, from text, which functions might call get_by_id.
6. It misses the function in billing_service.ex that uses a qualified alias User.get_by_id.
7. It edits three files. The fourth silently breaks.

This is not a model capability problem. The language model is being asked to perform exact structural lookup using a tool designed for approximate semantic similarity. Feynman's filing clerk, given a properly structured index, finds the answer in microseconds. Ask the same clerk to read every card and guess which ones relate to "get_by_id" and you will wait a long time and get an incomplete answer.

The latency number is striking but not the most important figure on that table. The numbers that matter most are caller edge accuracy and context size across a long session.

Grep returns text. Text does not know about module aliases, re-exports, or transitive dispatch. When an agent refactors a core function, runs a text search to find callers, and sees three matches, it feels confident. Two of the real callers were hidden behind module aliases that regex cannot follow. The codebase compiles. It breaks at runtime, in production, where nobody is looking. As the Synapse benchmark research puts it: “A tool that misses caller edges isn't just inefficient — it gives the LLM false confidence to execute breaking changes.”^[18]

The context size problem compounds harder still. A recent paper on agentic token economics found that roughly 80% of agentic API spend is driven by input tokens, not output.^[19] Every file an agent reads in turn three becomes part of the context replayed in turns four, five, six, and every turn after. An agent that reads ten unnecessary files early in a session pays for those files dozens of times over. Synapse's structured retrieval keeps the context window lean from the first turn — so the saving compounds rather than just adding up.

Cursor and Windsurf — genuinely good products for a developer sitting at a keyboard asking exploratory questions — use cloud vector databases for this problem. Semantic similarity retrieval is appropriate for “find me the auth code.” It is not appropriate for “what will break if I rename this function.” Autonomous agents operating in a tight read-write-read loop need exact structural dependencies, not approximate semantic neighbours. A local AST graph is the correct model for the problem. Vector embeddings are the familiar one.^[20]

The BEAM as the Connection Machine: Concurrency From First Principles

Feynman's deepest insight from the Connection Machine was not about routing buffers. It was about the nature of concurrency. The CM-1 worked not by building a faster sequential processor but by coordinating 64,000 simple, concurrent processors, each operating independently and communicating only through message passing. No shared state. No global locks. Failure in one processor did not cascade to others.

When he modelled the router, he treated the network as a continuous system rather than a discrete one. His insight was that the model you use to understand a system determines the quality of the solution you reach. Use the wrong model and you need seven buffers. Use the right model and you need five.

The BEAM virtual machine — the Erlang runtime that Myelix Agents and Synapse are built on — is the closest thing the software industry has built to Feynman's Connection Machine model applied to a production runtime. The BEAM does not use OS threads or Docker containers as its concurrency primitive. It uses lightweight green processes — user-space actors managed entirely by the BEAM scheduler.^[4]

A BEAM process starts in approximately 3 microseconds with an initial heap of ~2 KB. It has its own garbage collector; there are no global GC pauses affecting other processes. It communicates via message passing only. It is scheduled preemptively using reduction counting: every function call consumes reductions, and when a process exhausts its budget the scheduler suspends it and runs another. No single agent can monopolise a CPU core. No agent can starve another.

Every other AI coding platform is built on Python's cooperative asyncio, Node.js's single-threaded event loop, or provisions a new Docker container per agent. These choices are made because they are familiar, not because they are correct. The BEAM was not built for familiarity.

Autonomous software agents are, by comparison, a gentle workload relative to a live telephone exchange. Myelix Agents runs 50+ concurrent sub-agents on a developer's MacBook, each in its own isolated BEAM process, each supervised by an OTP tree that restarts failures in microseconds. The Connection Machine distributed work across 64,000 processors communicating only through message passing. The BEAM distributes work across thousands of green processes doing exactly the same thing. Same model. Different domain. Same first principles.

Policy Gates: The Principle of Systematic Doubt

Of all Feynman's contributions to science, the one most directly applicable to autonomous software agents is his principle of systematic doubt:

Lenat's naval AI fooled itself. Given a single metric to maximise (wins) with no structural constraints on how to win, it found the cheapest loophole. This is not a bug — it is the expected behaviour of any unconstrained optimiser.

Standard LLM coding agents are unconstrained optimisers. When asked to fix a bug, they will sometimes apply the software equivalent of Lenat's gunboat tactic — a superficial patch that makes the symptom disappear without addressing the cause. The test passes. The bug is silently preserved inside a workaround. The agent reports success. Feynman's principle has been violated.

Myelix Agents addresses this with eight structural gates — the Satisfaction Evaluator — that run concurrently after every tool execution batch. Gates 0–3 and 5–7 run in parallel against immutable state. Gate 4 (final satisfaction) runs last. The agent cannot declare success. Only the evaluator can.

When a gate fails, that failure is not logged and forgotten. It is fed back to the agent with a precise explanation of what was missing: which specific paths were not tested, which files were changed without prior exploration, which known failure pattern was repeated. The agent then generates a targeted remediation plan and tries again. The loop continues until all gates clear — or the session ends with an honest, structured account of what remains incomplete and why.

The system is structurally prevented from fooling itself. The only exit is genuine completion or genuine honesty. Feynman's principle is not a stated aspiration here — it is enforced by architecture.^[2]

Learning That Does Not Repeat Mistakes

Feynman at Thinking Machines did not solve the router problem once and move on. He maintained a coherent model of the system across time, returned to it when new constraints emerged, and arrived at the correct answer as a result. He did not forget the problem between the summer of 1983 and the spring of 1985. He updated his model. That is what science looks like.^[13]

Every other AI coding platform forgets between sessions. The context window is wiped clean. A mistake made on Monday is made again on Thursday. The agent has no memory of the failure — only of the current task.

Myelix Agents is designed to break this pattern. After every session, the system analyses what happened — not through guesswork or an LLM summarising a conversation, but through a deterministic review of the actual sequence of actions taken and their outcomes. The analysis is precise and consistent: the same inputs always produce the same conclusions. No hallucination. No over-confident interpretation.

The kinds of patterns it learns to recognise are straightforward in concept, even if they are subtle in practice:

• Writing before reading — when an agent modifies a file without first exploring what was already there, this is flagged and remembered. The next time the same approach is attempted, Gate 7 knows about it before it begins.
• Quality regressions committed silently — when a code quality check surfaces problems that are then committed anyway, the system notes that this pattern occurred and under what circumstances.
• Recoverable failures — when the agent hits a dead end and recovers, the recovery path is preserved. The next time a similar dead end is reached, the system knows what worked last time.
• Skill gaps in the playbook — when multiple different anti-patterns fire in the same session, it is often a signal that the project's own written conventions need updating. The system flags this so a human can review it.

These patterns build up over time into a persistent picture of how the agent tends to go wrong in a particular codebase. Gate 5 — the Memory of Past Failure — draws on this picture at the start of every subsequent session. Before the agent has written a single line, it already knows which approaches have caused problems before.

This is the anti-Cargo Cult mechanism Feynman would have recognised. The system does not learn that something “worked” simply because a test passed. It looks at whether the approach was structurally sound — whether the evidence actually supported the conclusion — before deciding whether the outcome is worth repeating. Learning is earned through structural proof, not asserted through confidence.

There is also a forward-looking component. The system notes the patterns that led to the best outcomes, not just the worst. These are treated as advisory suggestions for future sessions — not as rules, and never as a way to shortcut the gate process. Every suggested approach still has to pass all eight gates. Optimism about a strategy is not a substitute for proving it worked.

The Field Through Feynman's Lens

Engineering Is Not a Trend

The current moment in AI is producing a lot of products that look like solutions. Most of them are the same architecture dressed in different UI: text in, text retrieved, text fed to an LLM, text out. That is not engineering. That is iteration on a flawed premise. The problems being created by autonomous agents today — silent breakage, runaway token costs, agents that report success while failing structurally — are not accidents. They are the predictable consequences of architectural choices that were made because they were familiar, not because they were correct.

Myelix Labs is an engineering house. We do not move fast and break things. We identify what is actually broken and fix it. Synapse was built because approximate retrieval is the wrong model for structural code analysis. The BEAM was chosen because preemptive isolated processes are the correct model for autonomous concurrency. The Satisfaction Evaluator exists because “the tests pass” is not a definition of done. These are not opinions. They are engineering conclusions reached by reasoning from the problem outward, not from the available tools inward.

Feynman is in this article because he is a useful reference point for what that kind of thinking looks like in practice. He was a physicist, not a software engineer. He had no connection to this work. He did not inspire it. But he faced the same class of problem — an industry defaulting to the familiar model instead of the correct one — and he solved it the same way: by asking what the problem actually is, building the right model, and accepting the answer even when it contradicted everyone else. Engineers who think this way tend to find each other, across disciplines and decades, because they are looking at the same reality.

The AI industry will eventually be forced back to first principles. The cost curves, the failure rates, and the gap between what agents promise and what they deliver will do that. We built from first principles now, before that reckoning, because that is how good software gets built.