What is an Actor?

All of your assets in Pod-OS operate in the Actor Model. Understanding this model is the single most important concept for working with the platform.

The Actor Model in Brief

The Actor Model is a model of concurrent computation first described by Carl Hewitt in 1973 specifically for AI. It has since become the foundation for many large-scale distributed systems, including Erlang/OTP (language-specific), Akka (language-specific), and now Pod-OS (language-agnostic).

The core idea is simple: an Actor is the fundamental unit of computation. Each Actor can:

1. Receive messages — an Actor registers and handles messages or can leverage a mailbox where incoming messages queue up
2. Process messages one at a time — ensuring there are no race conditions or shared-state bugs
3. Send messages to other Actors — the only way Actors communicate
4. Create new Actors — spawning child Actors to delegate work
5. Change its own internal state — but only its own state, never another Actor's

That is it. Five behaviors, and they are enough to model any computation.

Share-Nothing Architecture

The most important property of the Actor Model is share-nothing. Each Actor:

• Has its own private state that no other Actor can read or write
• Has its own message-handling for messages
• Runs on its own logical thread(s) of execution

There are no shared variables, no shared memory, no locks, no mutexes. If Actor A needs information from Actor B, it sends B a message and awaits or checks a queue for a reply. This eliminates entire categories of bugs that plague traditional concurrent systems.

Location Transparency

An Actor does not know — and does not need to know — where other Actors physically reside. Actor A sends a message to Actor B using B's address. Whether B is:

• Running in the same instance
• On a different pod in the same Kubernetes cluster
• On a machine in a different data center
• On an edge device in a different country

...the message-sending code is identical. The Gateway handles routing.

This property is called location transparency, and it is what allows Pod-OS systems to scale from a single edge device to a global deployment without changing application code.

Actors in Pod-OS

In Pod-OS, every entity is an Actor:

When you deploy a Gateway through the Pod-OS dashboard, you are creating an Actor responsible for routing, Actor management and Message authorization. When you query an Evolutionary Neural Memory database, you are sending a message to an Actor via a Gateway. The mental model is always the same.

Supervision and Fault Tolerance

In the Actor Model, Actors are organized into supervision trees. A parent Actor (supervisor) monitors its child Actors. If a child fails:

• The Gateway Actor observes
• The Gateway Actor decides what to do: restart the child, stop it, escalate, or take corrective action
• Other Actors in the system are unaffected

This "blast-radius containment" philosophy means you do not need defensive error handling in every Actor. Instead, you design your supervision strategy, and the runtime takes care of recovery. A failure in one part of the system does not cascade to bring down the whole system.

Why This Matters

The Actor Model gives you:

• Concurrency without complexity — no locks, no race conditions, no deadlocks
• Fault isolation — a failure in one Actor does not affect others
• Scalability — add more Actors on more machines without changing code
• Location transparency — deploy anywhere, route everywhere
• Simple reasoning — each Actor is an understandable unit with clear inputs and outputs

Once you internalize this model, every feature of Pod-OS becomes intuitive. Gateways, Evolutionary Neural Memories, Agentic, Legacy Services — they are all just Actors doing their specific job.

Next: Deploy Actors with GitHub — deploy Shell and Socket actors from a GitHub repository, or continue to What is an Evolutionary Neural Memory?.