Actor model

One way to explain manifesting is that what you imagine becomes the path you map for yourself. So if you think, “I’m going to acquire my first 100 readers,” you will take different steps than someone who has decided to find 1000 readers. The mechanisms used and risks taken are determined by the outcome you imagine.

My goal with AI isn’t to replace my thinking. That’s one reason I’ve avoided agents and the team of agents method.

It’s not what I’m trying to build, but the agent swarm is a useful model. It has some advantages, one being functional differentiation. An agent has a defined job, and it can use the modelled concept of that job to define what they should and should not do. I’m trying to figure out how to get that without letting autonomous agents loose.

My ever-evolving AI system is starting to use a bastardized version of the actor model. It’s a programming paradigm used in languages like Erlang that keeps phone systems running so reliably. But essentially, I’m setting up actors, giving them addresses, and sending messages to those addresses.

• Actor: A set of behaviors that manage their own state and process messages. These can be roles an LLM takes on, but could also be more deterministic scripts and browser-based applications.
• Address: A many-to-many id. One address can serve multiple actors, and one actor can have multiple addresses.
• Message: A message to an actor’s address that the actor itself chooses how to process.

The LLM-based actor is really just a document setting behaviors and scope for Claude. The addresses accept messages for the actor(s). But nothing happens until I decide to start a session and designate an actor or actors to run in the Cowork session. The actor then processes its messages with my own prompt being considered another message to process.

One thing this gives me is the ability to set up new actors, addresses, and messages that sit untouched until I decide to run them. Let’s say I have an idea to build a hardware abacus that works as an input device for my computer. I can create the actor in charge of the project, set up an address, and send it a message. And then never touch the project again. I can even keep sending messages and shaping the actor, or spawn new actors, without ever running them. Everything waits until the actor is invoked.

Essentially I work as a manual scheduler for the system. Maybe someday I’ll replace myself with a more automated scheduler that runs even when I’ve stepped away from the keyboard. But for now I’m an actor in the system with my own addresses and messages to process. My own job should also get tightly defined.