I've pointed out quite a few problems with LLMs, particularly in the context of what people are using them for, or claiming they can do. But I've also been using, primarily, ChatGPT every day for more than 18 months.

One thing LLMs do pretty well is generate text that sounds plausible. As I've been considering how to approach some of the ideas I have for Vivarium infrastructure, I spent a few hours probing ChatGPT around things like Erlang/OTP, RINA (Recursive Inter-Networking Architecture), and Kubernetes. Then I asked ChatGPT to summarize this into a blog post.

Here's what it produced...

The following was generated by ChatGPT 5 and is presented un-edited:

Below is a single, coherent, polished, public-facing blog post that captures all the critical concepts of IRROS, stays engaging, avoids snark unless absolutely necessary, and only mentions Kubernetes where it is essential for contrast. This is the piece you’d publish when you want people to feel the revolution.

IRROS: A Unified Runtime for the Next Era of Distributed Systems

For decades, software infrastructure has been split into two worlds:

• the application runtime, where your code lives
• and the orchestration layer, where some other system decides how your code runs

That boundary—rigid, artificial, taken for granted—has shaped everything from cloud architectures to programming models. Yet it has also limited what distributed systems can become.

Imagine instead a world where:

• execution, supervision, networking, and deployment all share the same semantic model
• control loops live inside the system, not in a separate orchestration bureaucracy
• upgrades, placement, and recovery happen through the same mechanisms that run your code
• distribution is not an add-on, but intrinsic
• and scaling from single process → node → cluster → region uses the exact same abstractions

That system is IRROS: the Integrated Recursive Runtime Operating System.

IRROS unifies application logic, networking, supervision, and orchestration into a single recursive framework—a design inspired by the elegance of Erlang/OTP and deeper recursive ideas like RINA—but built for a modern, multi-cluster world.

Let’s walk through the key ideas.

1. Capsules: the First-Class Units of Computation

IRROS models everything as a Capsule: a stateful, supervised entity that owns its own computation, message handling, and lifecycle. Capsules are:

• fault-isolated
• independently upgradeable
• addressable via logical names
• placed and migrated across nodes
• supervised through structured, OTP-like strategies

There are many Capsule kinds:

• application services
• gateways
• schedulers
• routing control
• storage engines
• even the system’s own managers (placement, epochs, fabrics)

Every Capsule contains Cells, which are lightweight processes scheduled by the IRROS runtime. Cells communicate strictly via messages, never shared memory. This gives IRROS an inherent fault model and concurrency model without external tooling.

2. Fabrics: Communication as a Recursive Abstraction

IRROS introduces Fabrics—uniform IPC domains that work at every scale:

• Fabric[local] for intra-node messaging
• Fabric[cluster] for node-to-node communication
• Fabric[region] for wide-area links
• and new Fabrics can be created dynamically as needed

Each Fabric provides the same operations:

• send(dst, msg)
• request(dst, msg)
• resolve(name)
• monitor(dst)

A Capsule does not care where another Capsule runs—local or remote. Fabrics ensure message semantics remain consistent across all scales. They replace the patchwork of “local calls,” “cluster RPC,” and “mesh routing” with one conceptual model.

This eliminates the need for multiple, mismatched networking stacks inside your system. Instead of switching mental models for in-process calls, service mesh traffic, and cross-region replication, you use one unified approach.

3. Reflexes: Control Logic as Internal Actors

Most systems bolt “control plane logic” onto the outside—an external orchestrator that watches the system from the sidelines.

IRROS does the opposite.

Reflexes are specialized Capsules that:

• watch system events
• react to failures
• adjust placement
• scale instances
• manage traffic
• and enforce system-wide policies

Because Reflexes are just Capsules, they use the same messaging fabric, the same supervision semantics, and the same runtime model as ordinary application logic.

This removes the need for separate tooling, controllers, or external schedulers. IRROS manages itself the same way it manages your application: recursively.

4. The Epoch Manager: Coherent Versioned Reality

Every distributed system eventually grapples with upgrades, rollouts, version skew, and partial transitions. IRROS solves this cleanly with Epochs.

An Epoch is a versioned snapshot of:

• which Capsule versions are valid
• how each Capsule should be placed
• what the Fabrics should look like
• global feature flags and policies

Upgrading from Epoch A → Epoch B is a structured, supervised process. The Epoch Manager:

1. validates the new Epoch
2. announces the upcoming transition
3. coordinates Capsule upgrades through their explicit state transformation functions
4. rebalances placement
5. ensures the whole system converges
6. finalizes the new Epoch

If convergence fails, IRROS can roll back safely.

This elevates “system configuration” into a first-class, versioned concept, rather than a scatter of YAML files and ad-hoc scripts.

5. Placement & Scheduling: Autonomic Instead of External

Because messaging, monitoring, and supervision are native to IRROS, scheduling and placement become native too.

IRROS placement is:

• constraint-aware
• resource-aware
• failure-aware
• latency-aware
• multi-objective
• and always supervised

Node-level Reflexes give continuous feedback:

• “This node is overloaded.”
• “This Capsule is restarting too frequently.”
• “Traffic here is too high.”

Cluster-level Reflexes respond with global decisions:

• add or remove replicas
• move Capsules
• reweight traffic
• open or close Fabrics

This entire scheduling ecosystem lives inside IRROS, with one unified model—no external controllers, no mismatched logic.

6. Gateway Capsules: A Clean Boundary to the Outside World

To interact with the outside:

• HTTP
• gRPC
• WebSockets
• custom protocols

IRROS uses Gateway Capsules.

These Capsules:

• listen on host ports
• translate external requests into internal messages
• route them through Fabrics
• correlate responses back to clients

Gateways handle protocol adaptation, not orchestration. They don’t know anything about topology or placement—that’s Reflex logic’s job.

The result: a clean boundary between the external world and the internal recursive structure of IRROS.

7. Recursion: The Defining Principle

The most powerful aspect of IRROS is recursion.

The same abstraction—Capsules, Fabrics, Reflexes—scales uniformly from:

• Cells inside a Capsule
• Capsules inside a node
• nodes inside a cluster
• clusters inside regions
• regions inside global deployments

Each level supervises the one below it using the same exact semantics.

This is the architectural clarity that systems like Erlang hinted at and RINA formalized conceptually—but extended here into a full distributed runtime with built-in orchestration, state management, and versioning.

Why Not Just Use Kubernetes?

Kubernetes is mentioned here only for contrast, not critique. Its design assumes:

• applications are unaware of their own distribution
• orchestration is external
• supervision must be coarse
• networking is a combination of Services, CNI, and Service Mesh
• upgrades are an exercise in gradual YAML mutation

IRROS challenges that assumption.

Instead of dividing application and control plane, IRROS integrates them. Instead of layering multiple partial abstractions, IRROS provides one cohesive model for supervision, networking, deployment, and evolution.

It’s not an incremental improvement—it’s a different paradigm.

Why IRROS Matters

Distributed systems today feel like we’re welding together mismatched layers:

• multi-language microservices
• service meshes
• sidecars
• controllers
• operators
• orchestration APIs
• custom CRDs
• load balancers
• deployment pipelines
• runtime frameworks
• networking abstractions

It works, but at tremendous complexity cost.

IRROS eliminates these seams.

By unifying:

• process model
• communication
• supervision
• placement
• upgrades
• and runtime introspection

…into a single, recursively structured operating system for distributed computation, IRROS opens the door to something we’ve never truly had:

A global-scale software system that behaves like a single, coherent organism.

Not a cluster. Not a platform. A living runtime.

And once that exists, entire categories of failure modes, deployment complexities, and operational burden simply disappear.

The next era of distributed computing won’t be a better Kubernetes. It will be something fundamentally simpler, more powerful, and more elegant.

IRROS is a blueprint for that future.