Showing posts with label complexity. Show all posts
Showing posts with label complexity. Show all posts

The curious life of a clever slime mold

Mike's Notes

Slime Moulds are one cell, yet perform tricks of memory. From Knowable Magazine.

This example from nature is one of the many reasons why Pipi is modelled on how biological cells work.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Knowable Magazine
  • Home > Handbook > 

Last Updated

10/09/2026

The curious life of a clever slime mold

By: Tim Vernimmen
Knowable Magazine: 11/02/2026

Tim Vernimmen: Tim Vernimmen is a freelance science writer based near Antwerp, Belgium. For this article, he was hoping to interview Physarum itself, but scientists are still working out how to do that.

...

In its quest to feed, avoid nasty substances and just generally live its life, the brainless, one-celled Physarum polycephalum performs some impressive tricks of learning and memory

...

Sixteen years ago, a brainless, unicellular organism blew our human minds. And it continues to fascinate and surprise researchers to this day.

Scientists had known that some slime molds of the species Physarum polycephalum consist of one giant, pulsating cell that keeps changing shape as it moves around and branches out to access food and avoid unpleasant things like salt or light. But it took a 2010 experiment led by Japanese biologist Toshiyuki Nakagaki of Hokkaido University to reveal the depths of its sophistication. When Nakagaki placed the oat flakes that Physarum likes in a pattern mimicking the cities surrounding Tokyo, the slime mold’s branches almost exactly reproduced the efficient transport connections between them that humans had taken years to develop.

From the center of a petri dish, the slime mold Physarum polycephalum extends branches to find food in this time-lapse video.

CREDIT: © DUSSUTOUR / CNRS

To Karen Alim, a theoretical physicist starting a postdoctoral project at Harvard University at the time, that study was a revelation. “I was like, ‘Wow, this is so crazy.’ A single cell that solves complex tasks appealed very much to me as a physicist.” Perhaps, Alim thought, she could apply her training to make sense of this clever creature with its network of contractile tubes and constantly pulsating currents.

So Alim and colleagues grew Physarum on a jelly-like substance called agar and carefully watched and recorded its behavior under the microscope. They measured the strength and direction of the fluid flow in its network of tubes. Then they simulated what they’d seen in mathematical models.

The result? Through studies like this, as Alim recounts in the Annual Review of Condensed Matter Physics, she has become convinced that the flow of fluid can be a way of transmitting information, and she’s working to understand the underlying mechanisms. Other researchers, meanwhile, are continuing to uncover new, intriguing behaviors in Physarum, a creature that appears able to learn, remember and make decisions — all without a brain.

Photograph of Karen Alim holding up a petri dish on which a slime mold is growing.

Researcher Karen Alim (right) and her colleagues grow Physarum polycephalum in petri dishes containing a nutrient-rich agar medium.

CREDIT: STEFAN WOIDIG / TUM

The flow of memory

Though Physarum is a single cell, the large body it forms can often be easily seen by the naked eye, growing to more than a foot in diameter under favorable conditions. It looks like a central blob from which a network of vein-like tubes emanates — larger tubes, then smaller tubes that fan out from them. Inside those tubes, cytoplasmic fluid is rhythmically flowing back and forth, supplying all parts of the cell with what they need. In nature, the slime mold is found in damp, dark spots like forest floors and decaying logs.

Many of the studies revealing Physarum’s unexpected skills revolve around its most important concern: finding food. Whenever Physarum encounters something edible, the outer wall of tubes near the food become soft. As a result — due to the pressure of the constantly moving fluid inside its tubes — that part of the body spreads out like a fan. This fan then slowly morphs into a network of even tinier tubes. Under the microscope, this looks like a river delta network of yellow slime feeding into the larger tubes of Physarum’s body.

How does it happen? Alim, who now works at the Technical University of Munich in Germany, figured out that encounters with food lead to an increase in local fluid flow within the tubes. This exerts greater shear force on the tube walls. The walls in that region grow thinner, allowing the tubes to expand.

Inside the slime mold Physarum polycephalum’s branching, pulsating body, currents of fluid flow back and forth to transport food and other molecules. These currents are key to the organism’s ability to move, change its shape and learn.

CREDIT: DELESCLUSE & DUSSUTOUR / CNRS

The opposite happens when Physarum encounters something awful like salt or light that it wants to get away from. In response to a repellent, the tube walls stiffen and contract, which redirects fluid flow elsewhere.

In sum, researchers now understand that where the flow is stronger, the tubes expand, and where the flow is weaker, they shrink. This interplay of shrinking and expansion in different areas of the body is what reorganizes the shape of Physarum’s tube network, causing it to approach food and avoid things like salt.

More recently, Alim and colleagues discovered just what creates a tube network as efficient as Tokyo’s transport links. It ties into something crucial about the fluid flow in Physarum’s body: Tube walls respond to changes in flow with some delay. First the flow increases. Then, slightly later, the tube expands in response, causing the flow to decrease. This causes the tube to shrink, again with some delay.

The result, Alim found, is that the best-positioned tubes will grow larger and larger and receive more and more flow, while others will fade away — and hence, over time, a super-efficient network of links will form.

Put another way, Alim adds, you could say that the shape of the network (and its underlying fluid flow dynamics) helps Physarum to remember. Appropriately sizing its branches in accordance with food sources it has encountered recently makes for a simple but effective way to recall where food can be found.

Recent work in Alim’s lab suggests it’s not just the shape of the network that helps Physarum remember, but also how, when and where it contracts the walls of its branches. For example, she says, putting food in a certain location leads the slime mold to respond with a certain pattern of contractions and move toward the food. Between experiments, the contraction pattern diminishes, but if food is put in the same spot, it reappears, more quickly than before. In one experiment, a persistent wave of contractions caused a slime mold to keep crawling in one direction for hours to get away from a light source, long after the light had been switched off, which suggests it still remembered it.

Like all of us, Physarum polycephalum has its food preferences, as this time-lapse video shows.

CREDIT: © DUSSUTOUR / CNRS

Salt and slime

The finding is reminiscent of a study by Audrey Dussutour, a biologist working on the same species, now at the National Centre for Scientific Research in France. In 2019, Dussutour had reported something interesting: After a few attempts, Physarum took less time to cross a nasty salty patch inside its dish while moving toward a food source — implying some kind of learning. The effect remained even after the slime mold had spent time in the dormant state it adopts under stressful conditions.

Since the slime mold absorbed and retained some salt, it’s possible that this lowered the shock of encountering it again and allowed it to move faster, says Dussutour. So in a recent experiment, as yet unpublished, she used light as the repellent instead. Physarum still shaved down its travel time with repeated exposures, even though light isn’t retained the same way salt is. Dussutour suspects that contraction patterns may persist and store information “similar to the way waves of activity in our brain can store information,” she says.

In addition to the information stored in the layout and contractions of its tubes, says Dussutour, Physarum has another way to “remember”: the trail of slime it leaves wherever it goes. “Avoiding slime is a convenient way to make sure it’s exploring new places rather than retracing its own trail,” she says.

In the wild, Physarum polycephalum is often found on dead plant material, as shown in this time-lapse video.

CREDIT: © DUSSUTOUR / CNRS

Dussutour was also able to show that slime molds can learn about each other: They are sensitive to aspects of each other’s behavior. “They will approach others that have access to food, and avoid ones that are starving or stressed,” she says. “Remarkably, they also prefer to approach young individuals.”

Older slime molds become very slow and fragile, she adds. “We have some in the lab that are now 5½ years old…. We hardly dare to use them anymore. But intriguingly, when they go through dormancy, or fuse with a younger individual, it’s as if they’re young again.”

For a better understanding of the slime molds’ mysterious ways, it would be very helpful to find out what exactly they’re up to in the wild, says behavioral ecologist Tanya Latty of the University of Sydney. “Almost everything we know about their behavior is based on experiments done in a lab,” she says — experiments that focus on the large, multi-nucleus forms of the creatures, not the single-nucleus, microscopic amoeba state in which they spend most of their lives.

So Latty’s research group has been collecting wild slime molds to investigate. “They’re often found on rotting logs, but we’ve also found them in the leaf litter just in front of our building. People have also found them on house plants. They’re everywhere,” she says.

Latty suspects that the large form, with its various ways of learning, allows Physarum to consume a lot more food in preparation for making the spores it needs to spread. Physarum may be far less clever in its microscopic form, she adds, if its surprising behavior really depends on its ability to branch and contract its tubes. “But who knows? We didn’t think they were capable of anything when we started to study them.”

10.1146/knowable-021126-1

Jessica Kerr on Symmathesy

Mike's Notes

I was watching "A Learning System Made of Learning Parts" on Still Burning, an episode of Kent Beck's video blog.

Jessica Kerr joins Kent by the fire to argue that AI didn't take the programmer's job; it split it in two. The part we loved, crafting code by hand, has been commoditised like IKEA furniture. What's left is harder and more human: understanding what to build, proving it works, and stewarding the living "symmathesy" of people, code, and agents all learning from each other. They get into accelerated learning, why play is a signal you're learning, the loop that "becomes a noose," and choosing excitement over fear while the ground keeps shifting."

Resources

References

  • Symmathesy — A Word in Progress Proposing a New Word that Refers to Living Systems. Nora Bateson. Nora Bateson Foundation

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Still Burning
  • Home > Ajabbi Research > Library > Authors > Kent Beck
  • Home > Handbook > 

Last Updated

02/08/2026

Jessica Kerr on Symmathesy

By: Jessica Kerr
Jessitron: 15/04/2018

Jessica Kerr manages the Developer Relations team at honeycomb.io, because observability is one way our teams learn from our software. In speaking and teaching, Jess works across languages and communities, spreading cheerful deep thoughts. Code, tools, and people are not separable; all form the team that operates useful software.

Symmathesy is a term coined by filmmaker and systems theorist Nora Bateson in 2015 to describe a learning system made of learning parts, emphasising mutual learning that occurs within and between living contexts. Derived from the Greek roots sym (together) and mathesi (to learn), it serves as a response to mechanical, rigid frameworks by shifting the focus from individual elements to the dynamic relationships that generate evolution and adaptation.

In a symmathesy, learning is not an isolated process of acquiring information; it is an ongoing, multi-contextual process of mutual adjustment and calibration.

Collective problem solving in music, art, science, and software

A Learning System Made of Learning Parts

How function diversity scales, from cells to companies

Mike's Notes

Fascinating work. Something to test Pipi against using long-cycle simulations.

Resources

References

  • Scaling laws for function diversity and specialization across socioeconomic and biological complex systems. Authors: Vicky Chuqiao Yang, James Holehouse, Hyejin Youn, José Ignacio Arroyo, Sidney Redner, Geoffrey B. West, and Christopher P. Kempes. PNAS (February 12, 2025). DOI: 10.1073/pnas.2509729123

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Parallax
  • Home > Handbook > 

Last Updated

04/05/2026

How function diversity scales, from cells to companies

By: Santa Fe Institute
Parallax: 18/02/2026

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

A mystery novel, a history book, and a fantasy epic may have little in common in plot or style. But count the words inside them and a strange regularity appears: many new words show up early, then fewer and fewer as the author reuses what has already been introduced.

That pattern, known as Heaps’ law, turns out not to belong to books alone. A new study in PNAS finds that the same rule also describes the growth patterns in many complex systems, from living cells and corporations to universities and government agencies — and could even be used to predict how they will change in the future.

The study, led by scientists at the Santa Fe Institute and MIT, doesn’t just document this regularity; it introduces a mathematical model that quantifies how different systems diversify and specialize. It finds that, while systems vary in how much they invest in creating entirely new functions, once those functions exist, their subsequent growth follows a remarkably universal rich-get-richer process.

“What’s striking is that these systems weren’t designed to follow the same rules,” says SFI Program Postdoctoral Fellow James Holehouse, who co-led the study with Vicky Chuqiao Yang, a former SFI Omidyar Fellow now at MIT. “Yet when you look at how they grow, you see the same trade-off between adding something new and building on what already exists.”

“It is remarkable that cells, bureaucracies, and companies, despite obvious differences, all grow their function repertoire with a similar pattern.”

In the study, researchers focus on what they call “distinct functions” — the different kinds of work a system performs. In a cell, that might mean different proteins. In an organization, it could mean different kinds of jobs. As systems grow, they do add new kinds of work, but they do so more and more slowly over time.

Using their model, the team analyzed dozens of bacterial and microbial cells, more than a hundred U.S. federal agencies, thousands of companies and universities, and hundreds of metropolitan areas. Across most of these cases, the same pattern appeared: as systems got bigger, the pace at which they added new functions steadily slowed, growing sublinearly.

In practical terms, sublinear growth means that doubling the size of a system does not double the number of functions inside it. Instead, growth increasingly comes from expanding what already exists. A growing organization hires more people into established jobs before creating new titles. A cell produces more of the proteins it already uses instead of evolving entirely new ones.

“It is remarkable that cells, bureaucracies, and companies, despite obvious differences, all grow their function repertoire with a similar pattern,” says Yang, an assistant professor at MIT Sloan and the Institute for Data, Systems, and Society. “This suggests that the regularity discovered in Heaps’ law applies not only to what humans create, like books, but also to human organizations themselves.”

Cities, however, follow a different version of the same trend. They still add new kinds of jobs as they grow, but they do so much more slowly, following a logarithmic pattern rather than the power-law pattern seen in other systems. Even as populations soar, genuinely new job types become increasingly rare.

That difference reflects a deeper structural divide. Cells, firms, and agencies behave like organisms, with clear boundaries and unified goals. Cities, by contrast, resemble ecosystems shaped by the independent choices of individuals rather than centralized control.

Geoffrey West, a co-author and Santa Fe Institute Shannan Distinguished Professor, adds, “There are underlying regularities shaping how complexity builds, even in systems that look completely different on the surface.”

This material is based upon work supported by the U.S. National Science Foundation under Award No. 2526746

20 Engines

Mike's Notes

While I finish off testing the Pipi System Engine (sys), here is the plan for the next stage.

Update 27/04/2026

Today, I have also been setting up some new twin 27" monitors to help with coding. I need larger 16pt Arial or Noto Sans font sizes these days.😎 Hopefully, better visuals will mean I will not get so tired.

Update 03/05/2026

The list has been pruned to 18 engines now, not 20.

Update 23/05/2026

Two more engines were added to the list, bringing the total back to 20.

Update 27/05/2026

Nest Engine (nst)  renamed as Nestspace Engine (nst)

Update 17/06/2026

DevOps Engine (dvp) added, bringing the total to 21. The order has also been changed. Going very well. This fix alone will speed up development 10x.😎

Resources

References

  • Reference

Repository

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

Last Updated

17/06/2026

20 21 Engines

By: Mike Peters
On a Sandy Beach: 26/04/2026

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

Project

The project is to import the 18 20 engines necessary for Pipi to run in deterministic mode, and self-manage with a minimal set of internal features, no adaptation or self-evolution. That will come later, when many more engines are imported, contained inside other engines, and probabilistic behaviour begins.

Variables

All of these engines have worked for years (some with origins dating back 26 years) and are mature and stable, but have been migrated from a laptop to a data centre, where the host environment differs. I forgot to sort that out first. 😎 The Nestspace Engine (nst) was rapidly invented to solve that problem, but the variables generated by the Nestspace are also causing name clashes.

Process

Each engine needs the same minor tweak upon import. I'm also carefully checking all spelling in each engine. Completing descriptions for future self-documentation.

Logs

Each engine is then left running while I watch the logs. Once the log engine is imported, logs can be visualised in Mission Control using third-party open-source tools. This will speed things up a lot. Eventually, the logs will feed feedback loops as this beast scales.

System Engine (sys)

The System Engine (sys), on its own, is like the empty skin of an elephant, to be stuffed and used in a museum exhibit. It looks like an elephant, but it is not alive.

The System Engine has intrinsic properties. It is designed to contain all other engines. As the engines are added and interact, the System Engine will come to life.

It's the whole that is greater (George Ellis) or lesser (Terrence Deacon) than the sum of the parts.

21 Engine import list

In this order.

  1. System Engine (sys)
  2. Nestspace Engine (nst)
  3. JVM Engine (jvm)
  4. CGI Engine (cgi)
  5. Namespace Engine (nsp)
  6. Data Engine (dta)
  7. Code Engine (cde)
  8. Variables Engine (var)
  9. Versioning Engine (ver)
  10. DevOps Engine (dvp)
  11. Render Engine (rnd)
  12. Template Engine (tem)
  13. Log Engine (log)
  14. Configuration Engine (cnf)
  15. Conductor Engine (cnd)
  16. Directory Engine (dir)
  17. Node Engine (nde)
  18. CMS Engine (cms)
  19. Core Engine (cor)
  20. Factory Engine (fac)
  21. Page Engine (pge)

Pipi is the IDE

I built Pipi using Pipi, so I'm stuck in chicken-and-egg land at the moment. The more engines are imported, the easier this will get. I have a rough idea of the import order, and luckily, I can use Synethesia to run simulations, which are usually very fast and accurate. After all, it's how I build everything.

Pipi Editions

Each engine is like a different kind of Lego brick, and each Pipi is built out of hundreds of these bricks. The 4 Editions are built with the same bricks, combined in different ways. The Instances of any Edition are built exactly the same way, but their databases, with the same data models, will store different histories, weights, parameters, etc., as they adapt and evolve.

DevOps Engine (dvp)

The DevOps log below is currently maintained manually, but will be generated automatically once the DevOps Engine (dvp) is back up and running. These logs will be automatically published on the Ajabbi Developer website using an interactive format with more detail.


DevOps log (edit)

A record of work done.

NZ DateTime Action Engine Status
2026-05-07 20:01 Edit 18 engines - short and long descriptions. Complete





Test System Engine (sys)





Create Nestspace Engine (nst) - Code for Linux vs Windows path delimiters.

Test Nestspace Engine (nst)




21/05/2026 12:35 Create JVM Engine (jvm) Completed

Edit JVM Engine (jvm) - configuration
21/05/2026 09:12 Edit JVM Engine (jvm) - variables Completed

Edit JVM Engine (jvm) - spelling

Test JVM Engine (jvm)




22/05/2027 11:17 Import CGI Engine (cgi) Completed
22/05/2026 18:46 Edit CGI Engine (cgi) - variables Completed

Test CGI Engine (cgi) - spelling

Test CGI Engine (cgi)





Test System Engine (sys)





Test Namespace Engine (nsp)





Test System Engine (sys)





Import Render Engine (rnd)

Edit Render Engine (rnd) - variables.

Edit Render Engine (rnd) - spelling.

Test Render Engine (rnd)





Test Render Engine (rnd) - run Nest Engine (nst) templates to create a nest.





Test System Engine (sys)





Import Template Engine (tem)

Edit Template Engine (tem) - variables.

Edit Template Engine (tem) - spelling.

Test Template Engine (tem)





Import Template Engine (tem) - import temporary nest templates





Test System Engine (sys)





Test Render Engine (nst) + Template Engine (tem) + Nest Engine (nst)





Test System Engine (sys)





Import Variables Engine (var)

Edit Variables Engine (var) - variables.

Edit Variables Engine (var) - spelling.

Test Variables Engine (var)





Test System Engine (sys)





Create Variables Engine (var) - quick & dirty CRUD editor.





Create Temporary web form UI for each engine

Test Temporary web form UI for each engine





Import Log Engine (log)

Edit Log Engine (log) - variables.

Edit Log Engine (log) - spelling.

Test Log Engine (log) - CRUD log file formats

Render Log Engine (log) - logs





Import Graphing library for logs

Create Embed visualisations on Mission Control web pages.





Test System Engine (sys)





Import Data Engine (dta)

Edit Data Engine (dta) - variables.

Edit Data Engine (dta) - spelling.

Test Data Engine (dta)





Test System Engine (sys)





Import Configuration Engine (cnf)

Edit Configuration Engine (cnf) - variables.

Edit Configuration Engine (cnf) - spelling.

Test Configuration Engine (cnf)





Test System Engine (sys)





Import Versioning Engine (ver)

Edit Versioning Engine (ver) - variables.

Edit Versioning Engine (ver) - spelling.

Test Versioning Engine (ver) - automatic versioning.

Render Versioning Engine (ver) - version logs





Test System Engine (sys)




























A Comprehensive Analysis of Palantir’s Forward Deployed Engineering Model

Mike's Notes

A fascinating article by Diogo Santo, about Palantir, with many lessons for implementing enterprise systems.

I figured out a very long time ago that large system complexity had to be embraced, not minimised, and proceeded with building Pipi on that basis.

As it turns out, Pipi and Palantir have some similarities due to convergent evolution. For example, Pipi is also ontology-driven and a multi-industry platform.

I agree 100% with what Diogo writes.

"Enterprise software fails because software vendors refuse to become students of the institutions they're trying to change

The FDE model is not a service delivery strategy that happens to look like product development. It is a product development strategy that looks like services from the outside.

The real insight is that institutional complexity is not a problem to be minimized. It is the environment that the product has to live in, and the only way to build something that functions in that environment is to understand it from the inside. The gravel road to paved highway is not about customization, it is about ground truth. The Echo/Delta team formation is not about about coverage, it’s about complementary perspectives on action and reality. The meritocracy of outcomes is not a culture value, it is a selection mechanism for the specific kind of intelligence that institutional embedding requires." - Diogo Santo

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Vertical AI Advantage
  • Home > Handbook > 

Last Updated

09/04/2026

A Comprehensive Analysis of Palantir’s Forward Deployed Engineering Model

By: Diogo Santo
Vertical AI Advantage: 07/04/2026

Helping senior consultants build specialized consulting practices that outcompete the big firms | Author | Senior Director of Data & AI @ Fujitsu.

Most enterprise AI is still trying to solve from the outside what Palantir figured out can only be solved from within.

Note to the Reader:

If this article feels extensive or you’re short on time, you can skip to the Key Takeaways at the end for a concise summary.

At its core, this piece explores how Palantir transformed enterprise software delivery by embedding engineers directly inside complex institutions. It shows why traditional product discovery often fails, how team structure and talent selection drive real impact, and what SaaS companies or consulting firms can learn about building solutions that actually work in the messy realities of organizations. The lessons here are about turning field experience into product insight, creating sustainable transformation, and bridging the gap between technical capability and operational reality.

In September 2001, the U.S. intelligence departments had more data than it had ever collected in its history. It had analysts who were extraordinarily skilled at interpreting fragments of information. What it did not have was the ability to make those two things talk to each other. The CIA had its systems. The NSA had its systems. The FBI had its systems. None of them could see what the others were seeing.

Palantir was founded, in part, to solve that specific problem. And the solution they arrived at was not a better algorithm or a cleaner data model. It was a kind of person. An engineer who would go inside, stay for months or years, and not leave until the institution’s data reflected its operational reality.

The rest of the software industry looked at this and called it services. Palantir looked at it and called it product discovery.

That gap in interpretation is still producing winners and losers twenty years later.

The reality about enterprise software is that most of it does not actually get used.

Enterprise software is not used in the scenarios the product managers imagined. Somewhere between the demo environment and the production floor, between the quarterly business review and the analyst’s actual morning, the software encounters the institution, an organization with dynamics — and the institution wins.

This is the problem everyone in enterprise software knows. We all know as well that current model of software delivery is structurally broken.

The conventional delivery model works roughly like this: a product team defines requirements through interviews and usage data, builds a product in a controlled environment, and deploys it to a customer who is then responsible for adoption. The product team is intelligent and well-intentioned. The customer is usually paying significant money and is sincerely motivated to adopt. And yet the gap between capability and actual use remains wide, across every sector, every company size, every level of leadership commitment.

The surface explanation is change management. The real explanation is deeper than that.

The product team, building from the outside, has an approximate model of his customer. They know what their customer says it does. They know what their customer believes it does. And although all of that might be true, the operational reality tends to drift from that picture, because of existing culture, legacy systems, undocumented errors and code, disaligned incentives, among others.

Palantir’s founders understood this because their first customer, the CIA, made the conventional discovery process not just impractical but structurally impossible. Analysts couldn’t describe their workflows to an external vendor. They couldn’t share their data. Requirements couldn’t be fixed because threats evolved daily. And none of this could be managed by signing a NDA.

How could they build an impactful solution and deliver real outcomes in such conditions?

To solve this, Palantir built a model that placed the engineer inside the illegibility. Not to study it from a safe distance, but to operate from within. To build under actual constraints rather than imagined ones. To treat operational complexity not as a blocker to be engineered around, but as the environment in which the product had to live.

By 2016, Palantir employed more forward-deployed engineers than traditional software engineers. That ratio was not just strategy, but a profound realization that without truly understanding the day to day operational complexities of their customers, the success of their product could not be guaranteed.

The System Behind Palantir’s Scalable Deployment Engine

The first structural insight was the Field-Driven Productization. Forward-deployed engineers built rough, tactical, client-specific solutions. Quick fixes on unstable pipelines. Workarounds for undocumented APIs. Hacks for data schemas that are not fully mapped. The priority was not architectural elegance. The priority was that the analyst (their customer) could do her job today, under the actual conditions of her actual job.

Meanwhile, the core engineering team was looking for patterns. When entity resolution appeared as a problem at one government agency and then at a pharmaceutical company and then at a financial institution, in different forms, with different surface characteristics, but with the same structural core, it got abstracted into a reusable primitive and pulled upstream into the platform.

The field work existed to generate the product, not just to generate revenue.

That distinction matters more than it might appear. A consulting firm builds something once for one client and bills for the hours. Palantir builds something once for one client, watches it fail in interesting ways, and turns the failure into platform infrastructure. Every engagement was, functionally, an R&D investment that paid in operational insight. The deployment cost per customer declined as the platform matured. The advantage compounded.

The second structural insight was the team formation. Palantir didn’t send just a single engineer into a client environment. It sent two distinct profiles:

  • The Delta — the Forward Deployed Engineer — writes production-grade code. Data pipelines. Ontology modeling. AI agent design. They pass the same technical interview as Palantir’s core product architects and engineers. They are not solution consultants. They are engineers who happen to be working inside a customer instead of a corporate campus. They have the profile of a scrappy startup CTO: technically deep, comfortable with ambiguity, able to navigate a broken data environment and produce something that functions. A Delta might spend three months designing a pipeline that routes unknown fields to a dataset and alerts on contract violations just because they’ve spent enough time inside organizations to understand what happens when this isn’t there. They understand foundational work is key to make downstream work to function.
  • The Echo — the Deployment Strategist — is usually not a software engineer. They are former military officers. Former clinicians. Former forensic accountants. People with specific domain knowledge. People who understand how institutions actually work. Which departments carry unspoken adversarial relationships, which data is politically untouchable, which workflow has been broken for a decade and quietly worked around by everyone who knows better than to escalate it. The Echo translates mission reality into technical requirements. They own the relationship. They own adoption. They own the long-term durability of what the Delta has built. When the Delta’s pipeline is technically complete, the Echo is the one who understands why three departments won’t use it and what change management it will take to make them start.

The tension between these two profiles is the point. A Delta left alone builds something technically correct and operationally irrelevant. An Echo left alone generates beautifully aligned strategy without nothing tangible and concrete. This team of 2 is designed so that both pressures are always present, always competing, always correcting each other.

The third structural insight is about what kind of person makes this model work at all. Palantir got particularly interested in free thinkers and independents motivated by the problem rather than the org chart. The willingness to eat pain — to stay inside a broken institution long enough to actually understand it — is not a competency that traditional consulting careers develop or reward. The meritocracy is built around outcomes, not credentials, and that selection effect ripples through everything the company builds.

You cannot hire your way into this model with standard enterprise talent. The profile that makes it work is specific, somewhat contrarian, and deeply uncomfortable in environments that measure outputs rather than outcomes. Most companies that have tried to replicate the FDE approach fail not at the structural level, but at the hiring level. They send consultants who are limited in how far they can challenge the status quo—people who prioritize keeping the client comfortable, echoing what the customer wants rather than addressing what will actually move the needle. Palantir, by contrast, hires engineers and operators who are pragmatic, willing to confront messy realities, and focused on delivering real transformation for clients who are ready to change, not just preserving political niceties or operating within a scripted theater.

Enterprise software fails because software vendors refuse to become students of the institutions they're trying to change

The FDE model is not a service delivery strategy that happens to look like product development. It is a product development strategy that looks like services from the outside.

The real insight is that institutional complexity is not a problem to be minimized. It is the environment that the product has to live in, and the only way to build something that functions in that environment is to understand it from the inside. The gravel road to paved highway is not about customization, it is about ground truth. The Echo/Delta team formation is not about about coverage, it’s about complementary perspectives on action and reality. The meritocracy of outcomes is not a culture value, it is a selection mechanism for the specific kind of intelligence that institutional embedding requires.

What Palantir built was not a software platform with an unusual go-to-market. It built an institutional learning machine that happens to produce software as its primary output. The software improves because the learning compounds. The differentiator isn’t the platform, is the institutional understanding which is encoded in the platform and every new deployment makes it deeper.

None of this is to say the model is easy to replicate or without genuine costs.

Forward deployment at Palantir’s standard requires a talent profile that is hard to faind and hard to train. Engineers who can write production-grade code and navigate institutional politics simultaneously, domain experts who understand both the mission and the messy data architecture that serves it.

Lessons for SaaS and Consulting in Enterprise AI

For SaaS product companies, the lesson isn’t just “embed your engineers.” The lesson is that product discovery cannot be safely delegated just to customer interviews, usage analytics, and quarterly business reviews. Those tools are adequate for understanding a market from a comfortable distance. They are not adequate for understanding how work actually gets done inside a complex institution — the decisions that happen outside any documented workflow, the data that never makes it into the system of record, the workaround that has been load-bearing for years without anyone acknowledging it.

For founders building enterprise AI products, the practical version of this is the Bootcamp — and Palantir’s execution of it beginning in 2023 is worth studying carefully. One to five days. Working on your data. Your actual operational problem. A functioning capability at the end, not a slide deck with next steps. U.S. commercial revenue grew 137% year-over-year by Q4 2025. The fastest way to overcome an institution’s uncertainty about whether AI can work for them is to show them a piece of it already working inside their own environment. You are not selling a platform. You are selling a glimpse of their own operational reality, improved. Skepticism dissolves faster than any roadmap could dissolve it.

The second lesson is about sustainability and also applies to SaaS Product Companies. From the beginning, Palantir structured its engagements to end with a customer who no longer needs Palantir to operate the platform. Palantir built it as the growth mechanism. Customers who own their platform build more on it. Customers who depend on vendor engineers remain cautious about expanding scope, because every expansion means another engagement they can't control. Self-sufficiency is the condition that makes the relationship valuable enough to deepen. Customers invest more per year because they learn how to operate the platform, not because Palantir continued to operate it for them.

The third lesson applies to consulting firms. It reshapes the consulting industry into categories. The market is splitting into three layers:

  1. Strategy consultancies (such as McKinsey, BCG, Bain, Roland Berger, Oliver Wyman) doing high-level transformation architecture, operating model redesign. The deck that frames the problem before the technology conversation begins. I believe this layer is not going away. It is, however, becoming progressively decoupled from the implementation work that follows it, because the gap between a transformation roadmap and a functioning production system is widening faster than these firms are moving to close it;
  2. Industrial-scale integrators (such as Accenture, Deloitte, IBM, Capgemini) operating as primary delivery partners for enterprise AI platforms. These firms will own the middle of the market, the deployments that are large enough to need coordinated delivery but standardised enough not to require genuine institutional embedding;
  3. And a third category that currently has no clean name — forward-deployed engineering teams that wire AI into live systems, govern it in production, and remain accountable for what happens six months after the platform vendor has moved on. It does not yet have a standard business model, a recognised category name, or a talent pipeline that trains people for it deliberately.

The third category is going to become, in my opinion, the most valuable layer of the three, because it is the only one willing to operate inside the institutional complexity that neither the strategists nor the integrators are prepared to enter. Most boutique consulting firms are currently sitting in the first or second bucket by default.

To conclude. What the Palantir story tell us is that growth is not directly tied to platform’s value. SaaS product growth happens when an institution discovers that a piece of technology understands its specific operational reality — not in the abstract way that a platform demo understands it, but in the way that only comes from someone sitting inside the mess for months, learning the undocumented APIs, mapping the workflows that don't appear in any org chart, staying until the gravel road becomes passable.

Most enterprise AI is currently being sold as a destination. Buy the platform, complete the implementation, arrive at transformation. That transformation is a process of continuous institutional learning.

Key Takeways

1. Product Success Requires Immersion in Operational Reality

  1. Enterprise software often fails because product teams rely on interviews, usage data, or quarterly reviews, rather than understanding day-to-day workflows inside the institution.
  2. Palantir’s solution: Forward-Deployed Engineers (FDEs) operate inside the customer environment, building under real constraints rather than imagined ones.
  3. Software becomes effective when it reflects ground truth, not assumptions or polished demos.

2. Field-Driven Productisation Compounds Advantage

  • Initial deployments are tactical, client-specific, and often messy (“quick fixes on unstable pipelines”).
  • Core engineering observes patterns across clients to abstract reusable primitives.
  • Every deployment acts as R&D, reducing future customer deployment costs and improving the platform.
  • Palantir converts operational failures into platform infrastructure, creating compounding advantage.

3. Team Structure Matters: Delta + Echo

  • Delta (Engineer): writes production-grade code, navigates broken data, implements solutions.
  • Echo (Strategist): understands institutional politics, workflow realities, and adoption barriers.
  • The tension between the two ensures both operational functionality and strategic alignment.

4. Talent Selection is Critical

  • Success is not just about hiring experienced enterprise consultants; it’s about contrarian, outcome-focused people willing to endure operational friction.
  • Palantir hires engineers and operators who can confront messy realities and drive real transformation, not just maintain client comfort or political correctness.
  • The meritocracy of outcomes selects for the type of intelligence capable of navigating institutional complexity.

5. Transformation is a Process, Not a Destination

  • Software must be embedded in institutional learning, not treated as a one-off implementation.
  • Institutional complexity is not a problem to bypass; it is the environment in which the product must function.
  • Palantir’s approach turns product delivery into continuous operational learning, where each engagement deepens institutional insight.

6. Lessons for SaaS and Consulting Firms

  • SaaS: Product discovery cannot rely solely on distant analytics; short, hands-on engagements (“Bootcamps”) reveal real operational impact.
  • Sustainability: Design hand-off and internal capability development into every engagement. Customers who can operate independently expand platform and partnerships adoption more aggressively.
  • Consulting Industry: A new category of “forward-deployed engineering teams” is emerging, bridging gaps between strategy consultancies and large integrators by embedding in complex institutional systems.

7. Strategic Implication

  • Firms that succeed in enterprise AI are those willing to operate inside institutional complexity, show immediate proof of value, and build customer capability, rather than just delivering slides or managing relationships.
  • Value is created through learning inside the client’s reality, not by selling a destination or platform alone.

The Coming Crisis: Fingers of Instability

Mike's Notes

An excellent description of what a critical state is, using a real-world example: the global financial system. Critical state also applies to other phenomena, including earthquakes.

I have read the two excellent books by Buchanan and Taleb in the references. I must also read Sornette's book.

I think everything in the universe has its time in the sun, with a birth, existence, and death, often followed by a transformation into its oppositeThe laws of science apply to everything, including social systems like capitalism, trees, planets, schools of music, cars, etc.

Resources

References

  • Why Catastrophes Happen, by Mark Buchanan.
  • Antifragility, by Nassim Taleb.
  • Why Stock Markets Crash, by Didier Sornette.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Thoughts from the Frontline
  • Home > Handbook > 

Last Updated

02/03/2026

The Coming Crisis: Fingers of Instability

By: John Maudlin
Thoughts from the Frontline: 28/02/2026

John Maudlin is Co-Founder, Mauldin Economics.

This letter is a little different. I am indeed working on my book about what I believe is a coming crisis by reviewing five different cycle theories. They all arrive at a similar scenario from  different points of view, but they all suggest a crisis occurring sometime around the end of this decade or perhaps shortly thereafter. And all for different reasons. One background element ties them together, which is the subject of today’s letter.

This is essentially a shortened first chapter. To long time readers, that background connection is our old friend: sandpiles and fingers of instability. but with a lot of edits and additions. Jumping in…

Ubiquity, Complexity Theory, and Sandpiles

With five different views about the coming crisis, which one is right? Do they conflict or reinforce each other? The correct answer is they’re all connected, but not in obvious ways. And in the end, it makes no difference which one is “more” right. The results will be the same. Understanding this below-the-radar connection is key to making sure you, your family, community and country all get through this to what will be the inevitable positive conclusion, even if it is a very bumpy ride.

We are going to start our exploration with excerpts from an important book by Mark Buchanan, called Why Catastrophes Happen. I HIGHLY recommend it to those of you who, like me, are trying to understand the complexity of the markets, economy and politics/society. The book is about chaos theory, complexity theory and critical states. It is written in layman’s terms. There are no equations, just easy-to-grasp, well-written stories and analogies. But it gives us an essential framework to understand the coming storms.

As kids, we all had the fun of going to the beach and playing in the sand. Remember taking your plastic buckets and making sand piles? Slowly pouring the sand into an ever-bigger pile, until one side of the pile started an avalanche?

Imagine, Buchanan says, dropping one grain of sand after another onto a table. A pile soon develops. Eventually, just one grain starts an avalanche. Usually it’s a small one, but sometimes it builds on itself and seems like a side of the pile collapses. Why?

Well, in 1987 three physicists named Per Bak, Chao Tang, and Kurt Weisenfeld began to play the sandpile game in their lab at Brookhaven National Laboratory in New York. Now, piling one grain of sand at a time is a slow process, so they wrote a computer program to do it. Not as much fun, but a whole lot faster. Not that they really cared about sandpiles. They were interested in what are called nonequilibrium systems.

They learned some interesting things. What is the typical size of an avalanche? After a huge number of tests with millions of grains of sand, they found there is no typical size. "Some involved a single grain; others, ten, a hundred or a thousand. Still others were pile-wide cataclysms involving millions that brought nearly the whole mountain down. At any time, literally anything, it seemed, might be just about to occur." The piles were chaotic in their unpredictability.

Now, let’s read this next paragraph from Buchanan slowly. It is important, as it creates a mental image that may help us understand the organization of financial markets, the world economy and society (emphasis mine).

"To find out why (such unpredictability) should show up in their sandpile game, Bak and colleagues next played a trick with their computer. Imagine peering down on the pile from above, and coloring it in according to its steepness. Where it is relatively flat and stable, color it green; where steep and, in avalanche terms, ‘ready to go,’ color it red. What do you see? They found that at the outset the pile looked mostly green, but that, as the pile grew, the green became infiltrated with ever more red. With more grains, the scattering of red danger spots grew until a dense skeleton of instability ran through the pile. Here then was a clue to its peculiar

The Critical State

Something only a math nerd could love? Scientists refer to this as a “critical state.” The term can mean the point at which water goes to ice or steam, or the moment that critical mass induces a nuclear reaction, etc. It is the point at which something triggers a change in the basic nature or character of the object or group. Thus (and very casually for all you physicists), we refer to something being in a critical state (or use the term critical mass) when there is the opportunity for significant change.

"But to physicists, [the critical state] has always been seen as a kind of theoretical freak sideshow, a devilishly unstable and unusual condition that arises only under the most exceptional circumstances [in highly controlled experiments]… In the sandpile game, however, a critical state seemed to arise naturally through the mindless sprinkling of grains."

Thus, they asked themselves, could this phenomenon show up elsewhere? In the earth’s crust, triggering earthquakes, or as wholesale changes in an ecosystem – or as a stock market crash?

"Could the special organization of the critical state explain why the world at large seems so susceptible to unpredictable upheavals?" Could it help us understand not just earthquakes, but why cartoons in a third-rate paper in Denmark could cause world-wide riots?

Buchanan concludes in his opening chapter:

"There are many subtleties and twists in the story … but the basic message, roughly speaking, is simple: The peculiar and exceptionally unstable organization of the critical state does indeed seem to be ubiquitous in our world. Researchers in the past few years have found its mathematical fingerprints in the workings of all the upheavals I’ve mentioned so far [earthquakes, eco-disasters, market crashes], as well as in the spreading of epidemics, the flaring of traffic jams, the patterns by which instructions trickle down from managers to workers in the office, and in many other things. At the heart of our story, then, lies the discovery that networks of things of all kinds – atoms, molecules, species, people, and even ideas – have a marked tendency to organize themselves along similar lines. On the basis of this insight, scientists are finally beginning to fathom what lies behind tumultuous events of all sorts, and to see patterns at work where they have never seen them before."

Going back to the sandpile game, you find that as you double the number of grains of sand involved in an avalanche, the probability of an avalanche becomes 2.14 times more likely. We find something similar in earthquakes. In terms of energy, the data indicate that earthquakes become four times less likely each time you double the energy they release. Mathematicians refer to this as a "power law," a special mathematical pattern that stands out in contrast to the overall complexity of the earthquake process.

Fingers of Instability

So, what happens in our game?

"…after the pile evolves into a critical state, many grains rest just on the verge of tumbling, and these grains link up into ‘fingers of instability’ of all possible lengths. While many are short, others slice through the pile from one end to the other. The chain reaction triggered by a single grain might lead to an avalanche of any size whatsoever, depending on whether that grain fell on a short, intermediate or long finger of instability."

Now, we come to a critical point in our discussion of the critical state. Again, read this with not just markets but our entire society in mind:

"In this simplified setting of the sandpile, the power law also points to something else: the surprising conclusion that even the greatest of events have no special or exceptional causes. After all, every avalanche, large or small, starts out the same way, when a single grain falls and makes the pile just slightly too steep at one point. What makes one avalanche much larger than another has nothing to do with its original cause, and nothing to do with some special situation in the pile just before it starts. Rather, it has to do with the perpetually unstable organization of the critical state, which makes it always possible for the next grain to trigger an avalanche of any size."

This concept applies to not just financial markets, but to how we organize our political systems, generational differences, geopolitics and war, the over-production of elites and even how information is interpreted. They ALL connect. The Great Recession was a financial crisis. COVID-19 was a health crisis with a financial crisis and added political crises which further divided a fractious world.

We all see pressures building up in many different aspects of society. They each create their own fingers of instability. But in the sandpile of life, they are connected. 

Now, let’s couple this idea with a few other concepts. First, Hyman Minsky (who should have been a Nobel laureate) points out that stability leads to instability. The more comfortable we get with a given condition or trend, the longer it will persist and then when the trend fails, the more dramatic the correction.

The problem with long term macroeconomic stability is that it tends to produce unstable financial arrangements. Just as long term geopolitical or social stability will eventually produce a critical state. If we believe that tomorrow and next year will be the same as last week and last year, we are more willing to add debt or postpone savings in favor of current consumption. Or ignore any of a number of societal crises. Thus, says Minsky, the longer the period of stability, the higher the potential risk for even greater instability when market participants or a country’s citizens must change their behavior.

Relating this to our sandpile, the longer a critical state builds up in an economy, or in other words, the more "fingers of instability" are allowed to develop connections to other fingers of instability, the greater the potential for a serious "avalanche."

Therefore (and ironically), the longer a crisis takes to come about, the bigger the repercussions. One of the conclusions at the end of the book will be that we simply don’t know when the avalanche will be triggered. The US is such a large and wealthy country, and many of the rest of the shirts in the global laundry are just as (or even more) dirty, that global money might come to the US as a safe haven, thus prolonging our “stability” as the sandpile grows to an ever more critical state.

We Are Managing Uncertainty

Or, maybe, a series of smaller shocks lessens the long reach of the fingers of instability, giving a paradoxical rise to even more apparent stability. This is the thrust of Nassim Taleb’s book, Antifragility.

“People often think that the opposite of fragility is durability. If something is fragile, that means it’s easily broken. Therefore, if something isn’t easily broken, logically that should mean it’s the opposite of fragile. However, there’s another step beyond. Since there isn’t an established English word for such a thing, [Nassim] calls it antifragility—not just the lack of fragility, but its true opposite.

“We live in an unpredictable world. The models and theories we use to try to predict the future invariably fall apart as unforeseen events prove them wrong and, in turn, destroy the plans we made based on those models. Clearly, systems based on such flawed models are bound to be fragile—easily broken.

“The solution to this problem is antifragility. Instead of a never-ending search for more accurate models and better predictions, all we need to do is make sure that we’re in a position to benefit from uncertainty and volatility instead of being harmed by it.

“This is hardly a new concept; nature exhibits antifragility in almost everything she creates. An organism can strengthen itself through minor damage in the form of exercise. In a similar sense, a species can strengthen itself through minor damage in the form of natural selection, which leads to evolution.

“However, unlike nature, humans try to control the world through models and rules. We think we can perfectly predict the future and avoid any shocks that would cause our fragile systems to fall apart. We think we can outsmart millions of years of evolution and antifragility, and we’re almost invariably wrong.

“Instead of trying to predict the future, we should assume that there will be major events we can’t see coming—because, sooner or later, there will be. If we’re prepared for them, using the methods and practices explained in this book, we can make sure that such events work to our advantage instead of hurting us. By avoiding fragility and embracing antifragility wherever possible, we can set ourselves up to thrive in an uncertain world.

Another way to think about it is the way Didier Sornette, a French geophysicist, has described financial crashes in his wonderful book, Why Stock Markets Crash (the math, though, was far beyond me!). He wrote:

"[T]he specific manner by which prices collapsed is not the most important problem: a crash occurs because the market has entered an unstable phase and any small disturbance or process may have triggered the instability. Think of a ruler held up vertically on your  the instantaneous cause of the collapse is secondary."

When things are unstable, it isn’t the last grain of sand that causes the pile to collapse or the slight breeze that causes the ruler on your fingertip to fall. Those are the "proximate" causes. They’re the closest reasons at hand for the collapse. The real reason, though, is the "remote" cause, the farthest reason. The farthest reason is the underlying instability of the system itself.

This is one reason we get "fat tails" in financial markets. In theory, returns on investment should look like a smooth bell curve, with the ends tapering off into nothing. According to the theoretical distribution, events that deviate from the mean by five or more standard deviations ("5-sigma events") are extremely rare, with 10 or more sigma being practically impossible – at least in theory.

However, under certain circumstances, such events are more common than expected; 15-sigma or even rarer events have happened in the world of investing. Examples include Long Term Capital in the late 1990s and any of a dozen bubbles in history. Because the real-world commonality of high-sigma events is much greater than in theory, the distribution is "fatter" at the extremes ("tails") than one would expect.

This holds true in geopolitics, too. The unthinkable sometimes happens. Before World War I began, no one thought it would come to war. Peace had been the rule for 40 years. Surely, mankind had evolved. Until…

Thus, the build-up of critical states, those fingers of instability, is perpetuated even as, and precisely because, we hedge risks. We try to "stabilize" the risks we see, shoring them up with derivatives, emergency plans, insurance, treaties, alliances, political change and all manner of risk-control procedures. And by doing so, the economic and social systems can absorb body blows that would have been severe only a few decades ago. We distribute the risks, and their effects, throughout the system.

Yet as we reduce the known risks, we sow the seeds for the next 10-sigma event. It is the improbable, unseen risks that will create the next real crisis. It is not that the fingers of instability have been removed from the equation, it is that they lurk in different places, not yet visible.

A Stable Disequilibrium

We end up in a critical state that Paul McCulley calls "stable disequilibrium." It has "players" all over the world, tied inextricably together in a vast dance through investment, debt, derivatives, trade, globalization, international business and finance. Each player works hard to maximize their own personal outcome and reduce their exposure to "fingers of instability."

The longer we go on, asserts Minsky, the more likely and violent any "avalanche" is. The more the fingers of instability can build, the more that state of stable disequilibrium can go critical on us.

It's all connected. We are building an unstable sandpile and it will come crashing down at some point. Then we will have to dig our way out.

The good news is we have seen this movie before. And after the crisis, a new period of stability and growth follows, for at least another 50-80 years. In my upcoming book we will look for ways to get through to that happier future.

Scottsdale, Houston, Los Angeles, West Palm Beach, Boston and New York

Next week I fly to Houston where I am on an economic advisory board for the Rice University economics department. Then I will be in LA meeting with the Inner Circle, exploring several companies that are literally changing the technology landscape of defense and energy. We will be opening clinics in West Palm Beach and the DC area, hopefully in early April. Construction has begun. Then NYC and Boston.

I finish this from Scottsdale where Dr. Roizen and I are attending the 2026 Functional Longevity Summit, along with 3-400 doctors. The organizers have asked us to talk about Therapeutic Plasma Exchange. For those interested in staying healthy for longer, Mike and many experts now believe the first part of your journey should begin with therapeutic plasma exchange. Seriously. You can learn more at Lifespan-Edge.com (note the dash). If you haven’t, you really need to read our main research report. The research and other information can make a real difference in your life. You can set up a discovery call to talk with our doctors about the procedure and see if it is right for you. As well as look at a lot more research.

And with that, I will hit the send button. Have a great week.

Your thinking how to make my body antifragile analyst,