Pub/Sub Clearly Explained (in Under 6 Minutes)

Mike's Notes

Excellent description.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Level Up Coding System Design
  • Home > Handbook > 

Last Updated

14/01/2026

Pub/Sub Clearly Explained (in Under 6 Minutes)

By: Nikki Siapno
Level Up Coding System: 20/12/2025

Founder LUC | Eng Manager | ex-Canva | 400k+ audience | Helping you become a great engineer and leader.

(6 Minutes) | How It Works, Best Practices, Why Teams Reach for It, When Not to Use It, and Tradeoffs

Pub/Sub Clearly Explained

Pub/sub is not “just a queue with topics.”

It’s a different way of wiring a system. Instead of calling a specific service and waiting, you publish an event and let whoever cares react.

That shift sounds small, but it changes your scalability, your failure modes, and how teams add features without tripping over each other.

If you’ve ever added “just one more downstream call” and watched latency, coupling, and deploy coordination explode, pub/sub is the pattern that turns that mess into a cleaner fan-out.

What Pub/Sub Actually Is

Publish/subscribe (pub/sub) is a messaging pattern where publishers broadcast messages to a topic, and subscribers receive messages for the topics they registered to, without either side needing to know who the other is.

That last part is the real power: decoupling.

The publisher doesn’t care who listens, and the listener doesn’t care who produced the event.

Each side evolves, scales, deploys, and even fails independently. You stop wiring services together one call at a time and start letting events flow through the system like signals; allowing teams to plug in new subscribers without modifying the service that emits the event.

How It Works

Most pub/sub setups have a broker (also called an event bus). Publishers send messages to the broker on a named topic/channel, and the broker routes a copy to every subscriber of that topic.

Key parts:

  • Publisher → Produces an event and publishes it to a topic.
  • Topic/Channel → The category label that subscribers use to filter what they receive.
  • Message broker → Tracks subscriptions and handles routing/buffering/filtering.
  • Subscriber → Consumes events for topics it subscribed to.

Two details that matter in real systems:

  • Push vs pull → Brokers may push events to subscribers, or let subscribers pull, depending on the implementation.
  • Transient vs durable → Some brokers store-and-forward (so offline subscribers can catch up), others only deliver to active subscribers.

Why Teams Reach for Pub/Sub

Pub/sub earns its popularity the moment a team feels how much friction it removes.

Instead of stitching services together with fragile chains of calls, you let events move through the system and let each component respond on its own terms.

That shift opens up a kind of freedom that’s hard to give up once you’ve experienced it.

It buys you that freedom in three ways:

  • Loose coupling → Publishers and subscribers don’t need to know about each other, so components evolve independently.
  • Async flow → Publishers don’t wait for subscribers to finish, so the system stays responsive and producers keep moving.
  • Fan-out scaling → One event triggers many independent workflows, and subscribers can scale out in parallel.
And you see the impact immediately.

A UserSignedUp event can kick off analytics, send a welcome email, run fraud checks, and sync the CRM; all without the signup service knowing or calling any of those systems.

The Tradeoffs

Pub/sub feels like a breakthrough the first time you use it.

You publish an event, everything reacts in parallel, and the system suddenly looks cleaner and more scalable.

But the moment you move past the happy path, you start to see the tradeoffs that come with that freedom. The architecture gets simpler; the responsibilities shift somewhere else.

Here’s where the cracks start to show:

  • Debugging gets harder → Tracing “who reacted to what” is less obvious, so you need strong observability.
  • Delivery semantics vary → Many systems are at-least-once or at-most-once, so consumers must handle duplicates or missed messages.
  • Ordering is not guaranteed → Global ordering is difficult; you may only get ordering within a partition, or none at all.
  • Operational overhead is real → Running brokers, scaling subscribers, and tuning throughput adds complexity.
  • Fire-and-forget” can bite you → Publishers typically only know whether the broker accepted the event; not whether any subscriber successfully processed it.
  • Schema still couples you → You remove service coupling, but you keep contract coupling via event shape/meaning.

In the end, pub/sub doesn’t fully erase complexity; it moves it.

Instead of wrestling with chains of downstream calls, you manage event contracts, consumer behavior, and the operational realities of the broker.

The system becomes more flexible, but you’ll need to carry the new responsibilities that come with that flexibility.

When to Use Pub/Sub

As systems grow, there’s a moment when direct calls stop being a convenience and start becoming a liability.

Pub/sub shines in that moment.

Use it when your system benefits from decoupled, asynchronous, one-to-many communication.

Where it works well:

  • One-to-many events → A single event triggers updates across multiple services/UI components.
  • High throughput workflows → Many tasks can run in parallel off the same event.
  • Rapid evolution → You expect to add new subscribers later without changing the service that emits the event.
  • Real-time feeds/notifications → One update fans out to many subscribers without polling.

When Not to Use It

But pub/sub isn’t magic; it works beautifully in the right context and poorly in the wrong one.

Don’t force pub/sub into problems that need the following:

  • Single dedicated recipient → Use a queue or direct call because fan-out isn’t needed.
  • Strict global ordering → Pub/sub ordering is hard; you’ll add complexity fast.
  • Immediate confirmation → If the workflow requires “did it succeed?” you need request/response or an explicit acknowledgment protocol.
  • Small/simple systems → Pub/sub can be overkill when a few components can just talk directly.

Best Practices

Pub/sub works best when you treat events as first-class APIs.

The architecture gives you room to move, but only if the contracts and operations are strong enough to support that freedom.

These practices help keep the system predictable as it grows:

  • Design clear event schemas → Define each field, its meaning, and its expected stability because consumers rely on your contract.
  • Version events thoughtfully → Add fields in a backward-compatible way and deprecate slowly so subscribers have time to adjust.
  • Make consumers idempotent → Handle duplicates safely because delivery semantics vary across brokers.
  • Keep events focused → Emit facts (“UserSignedUp”) rather than commands (“SendWelcomeEmail”) because facts allow many independent reactions.
  • Avoid leaking internal details → Publish stable domain-level events instead of exposing internals that might change as the system evolves.

Recap

Pub/sub gives you a different way to wire a system: publish once, react in many places.

It removes the tight coupling of direct calls and opens the door to parallel workflows, faster evolution, and cleaner boundaries between teams. But it also shifts complexity into event design, operations, and debugging.

In the end, pub/sub pays off when you embrace its power and its responsibilities.

Building the Reasoning Engine at Axiom

Mike's Notes

This is a very worthy aim. I hope they succeed. I discovered this article from reading This Week In AI Research from Dr Ashish Bamania.

"AxiomProver is an autonomous multi-agent ensemble theorem prover for Lean 4.21, developed by Axiom Math.

It autonomously and fully solved 12 out of 12 problems in Putnam 2025, the world’s hardest college-level math test, using the formal verification language Lean, 8 of which within the exam time.

A repository containing the solutions generated by AxiomProver can be found using this link.

A technical report will follow in the coming days, as per the team." - This Week In AI Research

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > This Week In AI Research
  • Home > Handbook > 

Last Updated

13/01/2026

Building the Reasoning Engine at Axiom

By: Axiom
Axiom: 24/05/2025

.

How hierarchical planning, verification, and self-play converge to mathematical superintelligence.

For centuries, mathematics has been humanity's most powerful sandbox – a place where we construct logical frameworks to understand reality's most complex systems. Why do grid cells fire in a hexagonal pattern? Why do quantum energy levels align with the spacing of primes?

Yet mathematical progress has always been shackled by a fundamental cruel bottleneck: the scarcity of extraordinary minds. When Évariste Galois revolutionized algebra in a fevered night before his fatal duel at twenty, he left behind ideas so far ahead of their time that decades passed before his contemporaries could grasp them. Srinivasa Ramanujan, before he succumbed to malnutrition and ill health, channeled thousands of formulas from his dreams into notebooks – results so profound that mathematicians spent nearly a century proving what he had intuited.

Even when breakthroughs occur as mathematicians' legacy, the extreme fragmentation of modern mathematics means experts in different subfields often cannot understand each other's work, causing vital connections between domains to remain hidden for decades. This combination of scarce genius and siloed knowledge creates an extraordinarily long pipeline from discovery to application – fundamental theorems discovered today might take generations before their full implications reshape technology and society – a delay so long that Hardy didn't anticipate in A Mathematician's Apology.

We're on a moonshot mission to change that. Axiom is building a reasoning engine capable of mathematical discoveries at scales and speed previously unimaginable – an AI mathematician.

The timing

Three trends are colliding for the first time in history.

First, neural networks have stepped beyond pattern matching into scalable reasoning, improving as compute, model size, and data grow.

Second, mathematical formalization has come of age through languages like Lean: by the Curry–Howard correspondence, proofs become executable programs, and programming languages are no longer just tools for producing outputs but instruments for certifying properties of abstract objects.

And lastly, LLMs have crossed a critical threshold in code generation, reliably producing high-quality code across many languages – including formal specification languages – and serving as a strong prior over the otherwise infinite action space of mathematics.

This synergy creates an unprecedented opportunity: reasoning engines that can conjecture and prove infinite theorems with zero human involvement.

The Convergence

Autoformalization is the Natural Language Compiler

Our data factory

Imagine you were a programmer in the 1950s. Your day to day was punching machine code into cards.

In the 1970s, you were wrestling with FORTRAN. By the 1990s, maybe C++. Today? You're basically just talking to the computer in English. Turing's childhood dream is now your reality with coding agents.

Each generation got to think a little less about the machine and a little more about the fun problem they were actually trying to solve.

Modern compilers are one-way DAGs. They take Python and transform it down the stack through multiple representations until it becomes machine code. There's some upward flow - as you type in your IDE, a partial compilation happens via Language Server Protocol, feeding information back up to create those squiggly lines and suggestions. But compilers never go fully back up the abstraction ladder. Disassembly exists, but it doesn't reconstruct your original high-level intent.

Mathematics needs something compilers never achieved: a true bidirectional cycle. For thousands of years, mathematicians think in high-level, intuitive leaps, not formal logic. Yet, math is undergoing a modernization. With proofs now spanning hundreds of pages, they are often riddled with hidden errors. In fact, every time proofs dogmatically resist being formally proven, the informal human source was wrong – just recently, mistakes were fixed during the formalization effort of Fermat's Last Theorem. The bottom formal layer catches what high-level intuition misses.

Meanwhile, autoformalization - the process of converting natural language proofs to Lean code - is a form of hierarchical planning, bridging between the abstraction layers.

Going down the stack: Autoformalization translates intuitive mathematical reasoning into formal proof – the compiler's traditional direction.

Going up the stack: Autoinformalization translates formal proofs back into human intuition – something compilers never truly do.

When combined, these create an interactive prover in natural language, freeing mathematicians to explore dozens of strategies and rapidly prototype ideas while the machine handles formalization.

But here's the most powerful part: machine discoveries at the formal level feed back up. The machine finds patterns, lemmas, and connections in the formal space that humans never intuited, then surfaces them as new high-level insights. The mathematician's intuition becomes augmented by discoveries happening in a space they couldn't naturally explore.

The compiler revolution took decades; the mathematical compiler revolution is happening now.

Formal Verification Guides Mathematical World Modeling

Our algorithmic core

You are a gold prospector in 1849. Everyone brings you shiny rocks claiming they've struck it rich.

Experienced prospectors examine them: "Looks like gold to me."

But when confronted with exotic ores, even experts disagree. Their pattern matching fails on things they've never seen.

Then someone brings an assayer's scale. The metal either dissolves in acid or it doesn't. Binary truth.

When you write a proof, it's either correct or it's not. Formal verifiers like Lean provide perfect ground truth while model judges are pattern matchers that fail when being pushed on generating genuinely novel proofs. From an engineering angle, verification gives us efficiently scalable rewards for learning.

And here's the philosophical perspective of why we need formal verification: Our self-consistent, observer-supporting universe follows rules that can be captured mathematically – from laws of physics to probability theory. Mathematics is the consistent language of our consistent universe and formal languages like Lean let us consistently operate in the mathematical world model.

We are training systems in mathematics as reality's minimal simulation – by learning to navigate the world of mathematics one grounded step at a time, the hope is that the AI has learned some fundamental rules that our reality has to follow. Video generation models learn physics too. Sometimes one ponders … where do abstract reasoning and spatial reasoning join?

Conjecturing-Proving Loop Realizes Self-Improving AI

Our discovery engine

While able to test if gold is real, finding new veins is harder: working in concert with verification, we enter the chapter of scientific discovery. Imagine you're in the middle of an ocean. Sailing towards new lands, of course, you start daydreaming about mathematics:

Your map is the Knowledge Base – showing where you've been. The entire corpus of mathematics indexed into a knowledge graph: definitions, theorems, and proofs. Formalized mathematics as a searchable, Internet-scale dataset.

Your ship is the Conjecturer – navigating uncharted territories. It spots distant landmasses through fog: "something valuable three days west." Built for open-ended exploration beyond known results, it samples out of distribution and generalizes with leaps guided by intrinsic motivations.

But when you spot an unknown island on the horizon, how do you know if it's India or the West Indies? The shape looks right, the distance seems plausible, but educated guess isn't certainty. You ask the experienced captain for wisdom that you trust – that is the Prover. Successful proofs extend the knowledge base. Failed attempts provide signals for improving both the Conjecturer and Prover. While formal verification turns "might be true" into "is true," counterexample construction shows "is false." Both grow the library.

The loop is self-reinforcing. More verified theorems mean a richer knowledge base. A richer knowledge base enables more sophisticated conjectures. More proof attempts (successful and failed) train better models. Better models generate more interesting conjectures and find proofs faster.

Axiom is building the AlphaGo for mathematics, but with infinite branching.

The Path Forward

The implications extend far beyond pure mathematics. Every complex system humans want to understand – from protein folding to quantum field theory and economic models – ultimately reduces to mathematical structures. A reasoning engine that can autonomously explore mathematical space and generate new theories doesn't just solve math problems; it provides a general-purpose tool for understanding reality.

Our founding team brings together precisely the expertise needed for this revolution. We were among the first to apply AI to compilers, bringing deep experience in programming languages and compiler technology. Our work spans from AI for mathematical discovery to pioneering self-improving systems. We're building reasoning engines that can operate in the mathematical world model at superhuman scale to tackle our most complex challenges.

The mathematical renaissance isn't coming. It's here.


AxiomProver at Putnam 2025

Putnam 2025, the world's hardest college-level math test, ended December 6th. By the end of the competition, AxiomProver had solved 8 out of 12 problems. In the following days, it solved the remaining 4. AxiomProver is an autonomous multi-agent ensemble theorem prover for Lean 4.21.0, developed by Axiom Math.

This repository contains the solutions generated by AxiomProver. Asterisk denotes solutions found after the competition.

  1. 2025 A1: [source], [graph]. Prover: 110 minutes, 7M tokens. Proof: 652 lines, 23 theorems, 561 tactics.
  2. 2025 A2: [source], [graph]. Prover: 185 minutes, 6M tokens. Proof: 556 lines, 26 theorems, 581 tactics.
  3. 2025 A3: [source], [graph]. Prover: 165 minutes, 8M tokens. Proof: 1,333 lines, 78 theorems, 1,701 tactics.
  4. 2025 A4: [source], [graph]. Prover: 107 minutes, 8M tokens. Proof: 960 lines, 32 theorems, 1,107 tactics.
  5. 2025 A5*: [source], [graph]. Prover: 518 minutes, 9.1M tokens. Proof: 2,054 lines, 52 theorems, 3,074 tactics.
  6. 2025 A6*: [source], [graph]. Prover: 259 minutes, 16M tokens. Proof: 588 lines, 28 theorems, 670 tactics.
  7. 2025 B1: [source], [graph]. Prover: 270 minutes, 7M tokens. Proof: 1,386 lines, 49 theorems, 1,841 tactics.
  8. 2025 B2: [source], [graph]. Prover: 65 minutes, 2M tokens. Proof: 417 lines, 28 theorems, 325 tactics.
  9. 2025 B3: [source], [graph]. Prover: 43 minutes, 2.9M tokens. Proof: 340 lines, 11 theorems, 422 tactics.
  10. 2025 B4*: [source], [graph]. Prover: 112 minutes, 249K tokens. Proof: 1,061 lines, 23 theorems, 1,433 tactics.
  11. 2025 B5: [source], [graph]. Prover: 354 minutes, 18M tokens. Proof: 1,495 lines, 66 theorems, 1,967 tactics.
  12. 2025 B6*: [source], [graph]. Prover: 494 minutes, 21M tokens. Proof: 1,019 lines, 30 theorems, 1,052 tactics.

The Strange Physics That Gave Birth to AI

Mike's Notes

Part of a series "Science, Promise and Peril in the Age of AI" from Quanta magazine in 2025. The series is excellent, explaining the science behind AI.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

12/01/2026

The Strange Physics That Gave Birth to AI

By: Elise Cutts
Quanta Magazine: 30/04/2025

Elise Cutts is one of those ex-researchers who realized that writing about science is much more fun than doing it herself. Previously a geobiologist, she now writes about physics, geoscience, and space research in Europe and beyond from her home in Graz, Austria.

Modern thinking machines owe their existence to insights from the physics of complex materials.

Spin glasses might turn out to be the most useful useless things ever discovered.

These materials — which are typically made of metal, not glass — exhibit puzzling behaviors that captivated a small community of physicists in the mid-20th century. Spin glasses themselves turned out to have no imaginable material application, but the theories devised to explain their strangeness would ultimately spark today’s revolution in artificial intelligence.

In 1982, a condensed matter physicist named John Hopfield borrowed the physics of spin glasses to construct simple networks that could learn and recall memories. In doing so, he reinvigorated the study of neural networks — tangled nets of digital neurons that had been largely abandoned by artificial intelligence researchers — and brought physics into a new domain: the study of minds, both biological and mechanical.

Hopfield reimagined memory as a classic problem from statistical mechanics, the physics of collectives: Given some ensemble of parts, how will the whole evolve? For any simple physical system, including a spin glass, the answer comes from thermodynamics: “toward lower energy.” Hopfield found a way to exploit that simple property of collectives to store and recall data using networks of digital neurons. In essence, he found a way to place memories at the bottoms of energetic slopes. To recall a memory, a Hopfield network, as such neural nets came to be known, doesn’t have to look anything up. It simply has to roll downhill.

The Hopfield network was a “conceptual breakthrough,” said Marc Mézard, a theoretical physicist at Bocconi University in Milan. By borrowing from the physics of spin glasses, later researchers working on AI could “use all these tools that have been developed for the physics of these old systems.”

In 2024, Hopfield and his fellow AI pioneer Geoffrey Hinton received the Nobel Prize in Physics for their work on the statistical physics of neural networks. The prize came as a surprise to many; there was grumbling that it appeared to be a win for research in AI, not physics. But the physics of spin glasses didn’t stop being physics when it helped model memory and build thinking machines. And today, some researchers believe that the same physics Hopfield used to make machines that could remember could be used to help them imagine, and to design neural networks that we can actually understand.

Emergent Memory


A black-and-white portrait of a man in a tweed jacket and tie with his arms crossed.

The American physicist John Hopfield, pictured in 1988, developed a model of a neural network that laid the foundation for modern AI. Caltech Archives and Special Collections

Hopfield started his career in the 1960s working out the physics of semiconductors. But by the end of the decade, “I had run out of problems in condensed matter physics to which my particular talents seemed useful,” he wrote in a 2018 essay(opens a new tab). So he went looking for something new. After a foray into biochemistry that produced a theory of how organisms “proofread(opens a new tab)” biochemical reactions, Hopfield settled on neuroscience.

“I was looking for a PROBLEM, not a problem,” he recalled in his essay, emphasizing the need to identify something truly important. “How mind emerges from brain is to me the deepest question posed by our humanity. Definitely a PROBLEM.”

Associative memory, Hopfield realized, was a part of that problem that his tool kit from condensed matter physics could solve.

In a normal computer, data is stored statically and accessed with an address. The address doesn’t have anything to do with the information that’s stored. It’s just an access code. So if you get the address even a little bit wrong, you’ll access the wrong data.

That’s not how humans seem to remember things. We often remember by association. Some cue or scrap of memory brings the full thing flooding back. It’s what happens when you smell lilacs and recall a childhood episode in your grandpa’s garden, or when you hear the first few lines of a song and find yourself belting out every word to a ballad you didn’t know you knew.

Hopfield spent years on understanding associative memory and translating it to a neural network. He tinkered with randomly wired neural networks and other potential models of memory. It wasn’t looking good until, eventually, Hopfield identified an unlikely key to the “PROBLEM.’’

Two smiling men in suits stand side by side.

Geoffrey Hinton (left) and John Hopfield accepted the 2024 Nobel Prize in Physics at a ceremony in Stockholm in December. The prize honored their pioneering work on the earliest neural network models, which were based on the physics of spin glasses. Wikimedia Commons

Spin Glasses

In the 1950s, scientists studying certain dilute alloys such as iron in gold realized that their samples were doing some strange things. Above a certain temperature, these alloys behave similarly to a normal material such as aluminum. They aren’t magnetic on their own, but they do interact weakly with external magnetic fields. For instance, you can use a very strong magnet to move an aluminum can, but aluminum itself can’t work as a magnet. Usually, materials such as aluminum lose their magnetization as soon as the external magnet disappears. But below a certain temperature, spin glasses do something different. Their transient magnetization sticks around, albeit at a lower value. (This isn’t the only weird thing that spin glasses do; their thermal properties are also puzzling.)

Around 1970, condensed matter physicists started to get a theoretical handle on these materials by tweaking physicists’ go-to model of collective magnetic behavior: the Ising model.

An Ising model looks like a simple grid of arrows, each of which can point up or down. Every arrow represents the intrinsic magnetic moment, or “spin,” of an atom. This is a simplification of a real atomic system, but by tweaking the rules by which nearby spins affect one another, the model can generate surprisingly complex behaviors.

In general, nearby arrows that point in the same direction have low energy, while arrows that point in opposite directions have high energy. If the spins are free to flip, the Ising model’s state will thus evolve towards a lower-energy state of alignment, like a ball rolling downhill. Magnetic materials such as iron end up settling into simple states with their spins aligned in either the all-up or all-down state.

In 1975, the physicists David Sherrington and Scott Kirkpatrick devised a model that could capture the more complicated behavior of spin glasses by modifying the rules of how spins interact. They randomly varied the interaction strengths between spin pairs and allowed each spin to interact with every other spin — not just its nearest neighbors. That change led to a rugged “landscape” of possible energy states. There were peaks and valleys corresponding to higher and lower energy configurations; depending on where the spin glass started off in this landscape, it would end up in a unique valley, or low-energy equilibrium state. That’s quite different from ferromagnets such as iron, which “freeze” into one of two orderly states with all spins aligned, and nonmagnets, whose spins fluctuate randomly and don’t settle down at all. In a spin glass, randomness gets frozen.

The Ising model is very much a toy model. Using it to try to predict anything about real materials is a bit like using a stick figure to plan a surgery. But remarkably, it often works. The Ising model is now a workhorse of statistical mechanics. Variations on its theme can be heard in just about every corner of the study of complex, collective phenomena — including, because of Hopfield, memory.

Spin Memory

A simple view of interacting neurons has a lot in common with an Ising model of magnetic spins. For one thing, neurons are often modeled as basically binary on-off switches; they either fire or they don’t. Spins, likewise, can point either up or down. In addition, a firing neuron can either encourage or discourage the firing of its neighbor. These variable interaction strengths between neurons recall the changeable interaction strengths between spins in a spin glass. “Mathematically, one can replace what were the spins or atoms,”  said Lenka Zdeborová, a physicist and computer scientist at the Swiss Federal Institute of Technology Lausanne. “Other systems can be described using the same toolbox.”

To make his network, Hopfield started with a web of artificial neurons that can be either “on” (firing) or “off” (resting). Each neuron influences every other neuron’s state, and these interactions can be adjusted. The network’s state at any given time is defined by which neurons are firing and which are at rest. You can code these two states in binary: A firing neuron is labeled with a 1 and a resting neuron with a 0. Write out the state of the entire network at any given moment, and you’ve got a string of bits. The network doesn’t “store” information, exactly. It is information.

A woman in a white sweater stands in front of a large architectural feature.

Lenka Zdeborová, a physicist and computer scientist at the Swiss Federal Institute of Technology Lausanne, studies how the physics of matter can help model the behavior of machine learning algorithms. Samuel Rubio for Quanta Magazine

To “teach” the network a pattern, Hopfield sculpted its energy landscape by modifying the strengths of interactions between neurons so that the desired pattern fell at a low-energy steady state. In such a state, the network stops evolving and stabilizes in just one pattern. He found a rule for doing this inspired by neuroscience’s classic “neurons that fire together wire together” rule. He would tune up interactions between neurons that both fire (or both rest) in the desired final state and dial down interactions between mismatched pairs. Once a network is taught a pattern this way, it can reach the pattern again simply by navigating downhill through the network’s energy landscape; it will naturally reach the pattern when it settles into an equilibrium state.

“Hopfield made the connection and said, ‘Look, if we can adapt, tune the exchange couplings in a spin glass, maybe we can shape the equilibrium points so that they can become memories,’” Mézard said.

Hopfield networks can remember multiple memories, each in its own little energy valley. Which valley the network falls into depends on where it begins in its energy landscape. In a network that stores a picture of a cat and a picture of a spaceship, for instance, a starting state that’s vaguely cat-shaped will roll down into the cat valley more often than not. Likewise, starting the network in a state that recalls the geometric forms of a spaceship will usually prompt it to evolve toward the spaceship. That’s what makes Hopfield networks a model of associative memory: Given a corrupted or incomplete version of a memory, a Hopfield network dynamically reconstructs the whole thing.

Old Model, New Ideas

From 1983 to 1985, Hinton and his colleagues built on Hopfield’s work. They found ways to inject randomness into Hopfield networks to create a new type of neural network called a Boltzmann machine. Rather than remember, these networks learn the statistical patterns in training data and spin up new data to match those patterns — an early kind of generative AI. In the 2000s, Hinton was able to use a pared-down version of the Boltzmann machine to finally crack the stubborn problem of training “deep’’ neural networks consisting of multiple layers of neurons.

By 2012, the success of deep neural networks developed by Hinton and other pioneers was impossible to ignore. “It became clear that this is actually working amazingly well and just transforming the whole tech industry,” Zdeborová said. The generative AI models many of us now interact with every day, including large language models such as ChatGPT and image-generation models such as Midjourney, are all deep neural networks. They can trace their success back to curious physicists in the 1970s who refused to let the “useless” properties of spin glasses go unexplained.

Hopfield networks aren’t just part of AI’s past, however. Thanks to new ideas, these old models could be making a comeback.

In 2016, Hopfield and Dmitry Krotov(opens a new tab) of IBM Research realized that Hopfield networks weren’t just one model, but a whole family of models with different memory storage capacities(opens a new tab). Then, in 2020, another team showed that a key part of the transformer architecture, the blueprint of most modern successful AI models, was a member of that extended Hopfield network family(opens a new tab).

Armed with that insight, Krotov and his colleagues recently developed a new deep learning architecture called the energy transformer(opens a new tab). Typical AI architectures are usually found by trial and error. But Krotov thinks energy transformers could be designed more intentionally with a specific energy landscape in mind, like a more complex take on a Hopfield network.

Though Hopfield networks were originally designed to remember, researchers are now exploring how they can be used to create. Image generators such as Midjourney are powered by “diffusion models,” which are themselves inspired by the physics of diffusion. To train them, researchers add noise to the training data — say, pictures of cats — and then teach the model to remove the noise. That’s a lot like what a Hopfield network does, except instead of always landing on the same cat picture, a diffusion model removes “non-cat” noise from a noisy, random starting state to produce a new cat.

A smiling man with crossed arms stands in front of a blackboard.

Dmitry Krotov, a computer scientist at IBM Research, has shown that some of the most advanced AI models in use today follow the same basic principle that Hopfield networks employed from the start. Kim Martineau

It turns out that diffusion models can be understood as a particular kind of modern Hopfield network(opens a new tab), according to Krotov and his colleagues, including Benjamin Hoover(opens a new tab), Yuchen Liang(opens a new tab) and Bao Pham(opens a new tab). And that approach can be used to predict aspects of these networks’ behavior. Their work suggests that feeding a modern Hopfield network more and more data doesn’t just saturate its memory. Instead, the model’s energy landscape gets so rugged that it is more likely to settle on a made-up memory than a real one. It becomes a diffusion model(opens a new tab).

That a simple change in quantity — in this case, the amount of training data — can trigger an unexpected change in quality isn’t anything new for physicists. As the condensed matter physicist Philip Anderson wrote back in 1972, “more is different(opens a new tab).” In collective systems, simply scaling up networks of interactions between parts can add up to surprising new behaviors. “The fact that [a neural network] works is an emergent property,” Mézard said.

Emergence in a deep learning architecture — or a brain — is as captivating as it is puzzling; there’s no universal theory of emergence. Perhaps statistical physics, which provided the first tools for understanding collective behavior, will be the key not just to using but also to understanding the inscrutable machine intelligences changing our world.

Top mistakes from Neo Kim

Mike's Notes

This is a compilation of posts taken from different issues of Neo Kim's excellent System Design Newsletter. It's worth subscribing to.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > System Design Newsletter
  • Home > Handbook > 

Last Updated

11/01/2026

Top mistakes from Neo Kim

By: Neo Kim
System Design: 24/12/2025


39 mistakes YOU make in scaling a system  (21/12/2025)

Here are the biggest mistakes I see 99% of YOU making in scaling a system:

  1. Scaling vertically instead of horizontally (and hitting hard limits)
  2. Adding “microservices” too early (plus unnecessary complexity)
  3. Ignoring load balancing
  4. Not using caching at all… and increasing system load linearly with traffic
  5. Caching ‘everything’ blindly (causing stale data, memory pressure, complexity)
  6. Forgetting CDNs for static assets
  7. Keeping the server STATEFUL… (and limiting horizontal scalability + recovery)
  8. Scaling compute before data (databases are usually the first bottleneck)
  9. Treating the database as “infinite” storage
  10. Not using read replicas
  11. Sharding BEFORE understanding access patterns
  12. Never indexing ‘critical’ queries
  13. Allowing SLOW queries reach production… and amplify under load
  14. Blocking requests with “synchronous” processing
  15. Not using QUEUES for background jobs
  16. Ignoring retries and back-off… transient failures are typical in distributed systems
  17. Not setting “timeouts” (and causing thread exhaustion + cascading failures)
  18. Forgetting RATE LIMITS
  19. Letting failures ‘cascade’ by not using circuit breakers
  20. Ignoring backpressure
  21. Deploying ONLY to a single zone/region (and failing during zone/region outages)
  22. No global traffic routing
  23. Manual scaling instead of auto scaling (and moving slowly on traffic spikes)
  24. Shipping without ‘load testing’
  25. Never doing “capacity planning”
  26. Storing big files in databases (instead of object storage)
  27. Sending uncompressed payloads
  28. Making “excessive“ network calls
  29. Not BATCHING for writes
  30. No ‘service discovery’
  31. No failover strategy
  32. No graceful degradation… and disrupting core functionality under load
  33. Retries without ‘idempotency’ (and causing data corruption)
  34. No observability,,, you cannot scale what you cannot measure
  35. No monitoring alerts
  36. No “tracing” across services in a distributed system
  37. Scaling features instead of fixing BOTTLENECKS
  38. ‘Blindly’ copying big tech architectures
  39. Believing scale is about tools,,, not tradeoffs

23 latency mistakes YOU make when building distributed systems (24/12/2025)

Here are the biggest latency mistakes I see 99% of YOU making:

  1. Not indexing CRITICAL database queries (and causing full table scans + slow reads at scale)
  2. Hitting the database ‘repeatedly’ instead of caching hot data
  3. Not using a CDN for static assets and cacheable responses
  4. Deploying everything in a single region,,, and ignoring geographic latency
  5. Designing architectures with too many network hops… and unnecessary microservice chains
  6. Not using load balancers (and overloading individual servers)
  7. Scaling vertically instead of horizontally under CONCURRENT load
  8. Running “inefficient” code and algorithms on the critical path
  9. Executing ‘independent’ work sequentially instead of batching + parallelizing it
  10. Blocking requests with synchronous heavy processing (instead of async queues)
  11. Sending large payloads (instead of efficient compression & serialization)
  12. Sticking to HTTP/1.1 and missing out on multiplexing benefits from HTTP/2 & HTTP/3
  13. Opening new connections per request… instead of connection pooling
  14. Blocking threads with locks or synchronous I/O (and destroying parallelism)
  15. Running systems at “full capacity” with no headroom for traffic bursts
  16. Not measuring latency percentiles or profiling bottlenecks
  17. Allowing cold start affect user-facing requests
  18. Separating data and compute unnecessarily (and forcing extra network calls)
  19. Letting SLOW external dependencies sit on the critical path
  20. Not using ‘timeouts or circuit breakers’ for downstream calls
  21. Relying on slow disks or poorly tuned infrastructure for latency-sensitive paths
  22. Choosing runtimes & languages without tuning for latency
  23. Believing low latency comes from a single optimization instead of disciplined system design & tradeoffs

Latency is rarely caused by one big mistake… It’s the accumulation of many small, avoidable decisions in architecture, code, and execution.

Context Engineering 101: How ChatGPT Stays on Track

Mike's Notes

Basic guide to better prompts and why.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > System Design Newsletter
  • Home > Handbook > 

Last Updated

10/01/2026

Context Engineering 101: How ChatGPT Stays on Track

By: Neo Kim and Louis-François Bouchard
System Design: 19/12/2025

Neo Kim: I Teach You System Design • 0.5M+ Audience

Louis-François: Focused on making AI accessible. What's AI on YouTube, Spotify, Apple Podcasts. Co-founder @towards_ai. ex Ph.D. student @Mila_Quebec @polymtl.

You’ve probably used an AI assistant like ChatGPT and gotten an answer that felt off.

You rewrote your question, added “think step by step,” and maybe gave a bit more detail. Sometimes it helped. Sometimes it didn’t…

That kind of trial and error is a form of prompt engineering: trying different ways of asking to get a better response. For simple tasks, it’s often enough. But once you ask the assistant to do something more complex, wording usually isn’t the main problem anymore.

More often, the issue is that the model is working with the wrong information.

Something important is missing, buried in the conversation, or mixed in with a lot of irrelevant text. The result can look like confusion: it loses the thread, makes shaky assumptions, or answers confidently without solid grounding.

This is where context engineering comes in.

Instead of asking, “How do I phrase this better?”, you ask, “What information should the model see right now?”

Andrej Karpathy, one of the founding members of OpenAI, describes it as:

“The delicate art and science of filling the context window with just the right information for the next step.”

This newsletter looks at what that means in practice and how you can start doing it yourself (and how your favourite products like ChatGPT do it for the best user experience).

Onward.

I want to introduce Louis-François Bouchard as a guest author.

He focuses on making AI more accessible by helping people learn practical AI skills for the industry alongside 500k+ fellow learners.

What is Context?

Before getting into techniques or frameworks, it helps to be clear about what “context” actually means.

When you send a message to an AI assistant, it doesn’t just see your latest question. It sees the information included with your message, such as system instructions that guide its behavior, relevant parts of the conversation so far, any examples you provide, and sometimes documents or tool outputs.

All of that together is the context.

This matters because the model lacks long-term memory as humans do. It cannot recall past conversations unless that information is included again. Each response is generated solely from the current context.

The model can pay attention to only a limited amount of text at once. This limit is often called the context window. Dumping more into that space often makes answers worse, not better.

Everything the model sees when generating a response: system instructions, examples, tools, conversation history, and the current message—all compete for limited space.

Context engineering is about managing that working space.

The goal is not to give the model as much information as possible, but to give it the right information at the moment it needs to respond.

Why does this matter for agents?

This becomes more important when the AI is doing more than answering a single question.

A simple chatbot takes your question, replies, and stops. But more advanced AI systems, often called agents, work on tasks that unfold over many steps. They might search for information, read results, summarize what matters, and then decide what to do next.

Each step generates new information that is added to what the model sees next, such as search results, summaries, and intermediate notes. Over time, the context grows, and much of it becomes no longer relevant to the current step. This is called context rot, where useful information gets buried under outdated details.

Model performance degrades as the context grows. The sweet spot is finding the minimum high-value information needed—more context isn’t always better.

Agents often work well on focused tasks.

But when a task is broad and requires many steps, the quality can vary. As the context gets heavier, important details from earlier can get lost.

The Anatomy of Context

Understanding what causes context rot is the first step.

The next is knowing exactly what goes into the context window so you can control it.

When an AI generates a response, it is not just reacting to your last message. It is responding to a structured bundle of inputs. Each part plays a different role, but they all compete for the same limited space.

System Prompt and User Prompt

The system prompt determines the model's overall behavior.

It describes how the assistant should act, the rules it should follow, and the kinds of responses expected.

Most of the time, you do not see the system prompt directly. It’s defined by the product or application you are using. This is why two assistants built on the same underlying model can behave very differently.

For example, ChatGPT tends to answer politely, refuse certain requests, and format responses in predictable ways, even if you never explicitly asked it to do so.

The user prompt is your message.

This includes your current question and, in a chat setting, earlier messages that are still included.

Both are sent to the model together. The system prompt guides behavior, and the user prompt describes what to do right now.

If you are building an AI feature and you control the system prompt, the hard part is balance. If the instructions are too strict, the assistant can become brittle when something unexpected occurs. If they are too vague, responses become inconsistent.

A practical approach is to start minimal, test with real use cases, and add rules only when you see specific failures.

Examples

Sometimes the clearest way to guide an AI is to show it what you want.

Instead of writing a long list of rules, you can include one or two example inputs and the exact outputs you expect. This is often called few-shot prompting.

You have probably done this in ChatGPT without realizing it. If you say, “Format it like this,” and paste a sample answer, the model will usually follow the pattern.

Examples work because they remove ambiguity. They show tone, structure, and level of detail in a way that instructions often cannot.

The tradeoff is space. Examples take up room in the context window, so they need to earn their spot. A few well-chosen examples are usually better than a long list.

Message History

In a chat, the model can respond to follow-up questions because earlier messages remain in context.

For example, if you ask ChatGPT, “What is the capital of France?” and then ask, “What is the population?”, it can usually infer you still mean the capital you just discussed.

This works because the conversation so far acts like shared scratch paper. The model does not truly remember the earlier exchange. It is simply reading it again as part of the input.

The problem is that the message history grows over time. As more turns accumulate, older messages take up space even when they are no longer relevant. That can make the model less focused. It may repeat itself, follow outdated assumptions, or miss a detail that matters now.

Managing message history usually means keeping what is still relevant, summarizing what is settled, and letting the rest drop out of the active context.

Tools

On its own, an LLM can only generate text. Tools let it do more than that.

Tools allow an agent to search the web, read documents, run code, query databases, or interact with external systems. When a tool is used, the result is usually fed back into the context so the model can use it in the next step.

You have seen this in ChatGPT when it searches the web or analyzes a file you uploaded. The output becomes part of what the model sees before it responds.

Tools are powerful, but every tool call adds more text that competes for attention. If a tool returns too much information or in an unclear format, it can overwhelm the model rather than help it.

Good tool design keeps results focused and predictable. Clear names, narrow responsibilities, and concise outputs make it easier for the model to use tools effectively.

Data

Beyond messages and tools, agents often work with external data.

This can be a document you upload, an article you paste into the chat, or files the system can access. When that information is included, it becomes part of the context.

Large documents do not always behave the way you expect. The model may focus on the wrong section or miss details. This is often a context management problem, not carelessness.

Managing documents usually means breaking them into smaller pieces, pulling in what is relevant to the current step, and leaving the rest out of the active context until needed.

Context Retrieval Strategies

System instructions, examples, tools, and message history are the context in which you can write directly.

But often the most important information is not known in advance. It has to be retrieved during the task.

For example, if you ask ChatGPT a question about a PDF you uploaded, it needs to find the relevant section. If you ask it to search the web, it has to decide what to search for and which results matter.

Loading upfront (left) retrieves chunks upfront based on the query. Just-in-time (right) retrieves as the model reasons—more precise, but more round-trips.

How an agent retrieves and injects information is a major part of context engineering. There are two main approaches: loading everything upfront, or retrieving as you go.

Loading Upfront

The simplest approach is to retrieve relevant information before the model starts responding, then include it in the context all at once.

This is what happens when ChatGPT searches the web and then writes an answer using the results it just found. The model is not answering from memory. It is answering based on the information that was retrieved and added to its context.

This pattern is commonly called retrieval augmented generation (RAG).

Loading upfront works well when the question is clear, and the agent can predict what information will be useful. The downside is that the agent makes an early retrieval decision and may stick with it.

If something important is missing or the task changes direction, it can be harder to correct course.

Just-in-Time Retrieval

Another approach is to retrieve information as the task unfolds.

Instead of loading everything at the start, the agent takes a step, looks at what it has learned so far, and retrieves more information only when needed. You can sometimes see this in ChatGPT when it searches, reads, refines the query, and searches again during longer tasks.

This keeps the context cleaner because only the information actually needed gets pulled in. The tradeoff is that it takes more steps and requires the agent to decide when to retrieve and when to stop.

A useful pattern within just-in-time retrieval is to start broad and then drill down. This specification is called Progressive Disclosure.

Rather than loading full documents immediately, the agent may start with short snippets or summaries, identify what looks relevant, and pull in more detail only then.

This is how humans tackle research, too.

You do not read every article in a database. You scan titles, read abstracts of promising ones, and dive deep only into the sources that matter.

Hybrid Strategy

Fortunately, you don’t have to pick one or the other.

Many agents combine both approaches. They load a small amount of baseline information upfront, then retrieve more as needed.

You can see this in tools like ChatGPT. Some instructions and conversation history are already present, and additional information, such as search results or document excerpts, is pulled in based on what you ask.

For simpler use cases, loading upfront is often enough. As tasks get more complex and span multiple steps, retrieving as you go becomes more important.

The right choice depends on how predictable your agent’s information needs are.

Techniques for Long-Horizon Tasks

Retrieval helps an agent pull in the right information.

But some tasks create a different problem. They run long enough that the agent produces more text than can fit in the context window.

You may have seen this in ChatGPT during long conversations or research tasks. Early responses are clear, but after many steps, the answers can drift or repeat themselves, especially when you send very long instructions, like asking for help with entire code bases. Over a long task, the agent can encounter far more information than it can keep in working memory at once.

Larger context windows are not a complete solution. They can be slower and more expensive, and they still accumulate irrelevant information over time. A better approach is to actively manage what stays in context and preserve the important parts as the task grows.

Three techniques help with this:

  • compressing the context when it gets full,
  • keeping external notes,
  • splitting work across multiple agents.

1. Compaction

When the context approaches its limit, one option is to compress what’s there.

The agent summarizes the conversation so far, keeping the essential information and discarding the rest. This compressed summary becomes the new starting point, and the conversation continues from there.

You may have noticed something like this in long ChatGPT conversations. After many messages, earlier details can fade. This often happens because older parts of the conversation are shortened or dropped to make room for new input.

When context fills up, compress what matters—key decisions, goals, and facts—while keeping recent messages verbatim. The result: a fresh context that preserves the essential state.

The hard part is deciding what to keep.

The goal, key constraints, open questions, and decisions that affect future steps should stay. Raw tool outputs that have already been used can usually go. Repeated back and forth that does not change the plan can go too.

There is always a risk of losing something that matters later. A common safeguard is to store important details outside the context before discarding them, so the agent can retrieve them if needed.

2. Structured Note Taking

Compaction occurs when you’re running out of space. Structured note-taking happens continuously.

As the agent works, it keeps a small set of notes outside the context window. These notes capture stable information, such as the goal, constraints, decisions made so far, and a short list of what remains.

You can see a user-level version of this idea in features like ChatGPT’s memory. If you tell it to remember something, that information can persist beyond a single conversation and be brought back when relevant.

This works well for tasks with checkpoints or tasks that span multiple sessions.

A coding agent might keep a checklist of completed steps. A support assistant might store user preferences so that it does not have to ask the same questions again.

3. Sub-Agent Architectures

Sometimes the best approach is to break a large task into pieces and assign each piece to a separate agent with its own context window.

In many research-style agent designs, a main agent coordinates the overall task, while sub-agents handle focused subtasks. A sub-agent explores one area in depth, then returns a short summary. The main agent retains the summary and proceeds without carrying all the raw details forward.

You can think of research features in tools like ChatGPT as an example of the kind of workflow where this pattern is useful.

Sub-agents work in their own context windows, using tens of thousands of tokens, but only pass condensed summaries to the lead agent—keeping its context clean and focused.

This works well when subtasks can run independently or require deep exploration.

The tradeoff is complexity. Coordinating multiple agents is harder than managing a single one, so it is usually best to start with simpler techniques and add sub-agents when a single agent becomes overwhelmed.

Choosing the Right Technique

There’s no one-size-fits-all solution. The right approach depends on your “agent and your use case”. These rules of thumb can help:

  • Compaction works best for long, continuous conversations where context gradually accumulates.
  • Structured notes work best for tasks with natural checkpoints or when information needs to persist across sessions.
  • Sub-agents work best when subtasks can run in parallel or require deep, independent exploration.

These techniques can be combined. Start with the simplest approach and add complexity as needed.

Putting It All Together

Context engineering is not a single technique.

It’s an approach to designing AI systems. At each step, you decide what goes into the model’s context, what stays out, and what gets compressed.

Start simple and iterate. Test on small tasks first—if it works, scale up and test again. If it fails, diagnose the problem type and apply the targeted fix. Either way, loop back and keep testing until it works reliably.

The components we covered work together.

System prompts and examples shape behavior. Message history maintains continuity. Tools let the agent take actions. Data gives it information to work with. Retrieval strategies determine how and when that information gets loaded. For long-running tasks, compaction, external notes, and sub-agents help manage context that would otherwise overflow.

When something goes wrong, context is often the place to look. If the agent hallucinates, it might need better retrieval to ground its answers. If it picks the wrong tool, the tool descriptions might be unclear. If it loses track after many turns, the message history might need summarization.

A practical approach is to start simple.

Test with small tasks first. If it works, scale up. If it fails, identify what went wrong and address the specific issue.

Pipi 9.1.0

Mike's Notes

Pipi self-versioning has resumed after being frozen since 2020. Previously, Pipi was versioned whenever developers logged changes.

Resources 

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

10/01/2026

Pipi 9.1.0

By: Mike Peters
On a Sandy Beach: 9/01/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Automated Pipi semantic versioning has restarted. The previous version was frozen at Pipi 9.0.2+398; the current version is Pipi 9.1.0+399.

The next minor version change occurs on Friday, 10 April 2026, at 8am.

Build

  • Every change to a namespaced object increments the Build Number by 1
  • It is the internal system change ID
  • Daily Builds could vary from 0 to 1,000s
  • Never resets.

Patch

  • Release daily if there have been Build Number increases
  • Numbered 0-999
  • Resets when a Minor Release occurs
  • Minor documentation edits

Minor Release

  • Release 4x per year, 3 months apart on the 2nd Friday at 8am, NZ Time.
  • Numbered 0-99
  • Resets when a Major Release occurs
  • Documentation officially updated

Major Release

  • Release when a Minor Release backwards-incompatible change occurs, on the 2nd Friday of January, April, July or October.
  • Usually every 2-3 years
  • Numbered 1-99
  • New documentation released
  • Account migration required

Notes

Minor releases account for emergent behaviour changes in the system as a whole; the date is arbitrary. Major Releases account for phase-level changes when they occur.

It will take a while to get everything running according to plan. It requires enabling extensive automation across multiple systems. As a result, some parts will initially be out of sync.

If the Version Engine (ver) had been running since 2000, the number of changes would make the current Pipi version look something like

  • Pipi 9.18.78+25,000-beta

Rendered HTML

Rendered: 08:41 UTC, 9 January 2026 by Pipi 9.1.0+399-beta