"... Self-contained computers ..." - I like that wording. IMO, Smalltalk gets one thing wrong - it uses synchronous message passing instead of asynchronous message passing. Smalltalk methods are just synchronous function calls with a different syntax. I think Sam Aaron gets this more right with Sonic Pi in this video (approx. 9:29). He writes 3 sequential-looking statements, hits "Play" and all 3 statements fire at once, not one after another in sequence (Sonic Pi plays this script as a chord).

As it happens, I - literally - watched the same Alan Kay video for a 2nd time yesterday and took notes (expecting to summarize and post to 'linking-together'). I think he shows two important slides at 36:08 and then at 36:57. The first slide is a set of gears beside a set of cells. Our programming languages are like the gears, but modern problems, like the internet, are like the cells. The second slide shows a cell without a membrane beside a cell encapsulated in a membrane. Our programming languages break through the membrane by using a shared callstack and functions-call-functions thinking, while UNIX gets it right-er. Now that we can afford more than one CPU, we should have programming languages/IDEs/workflows that produce programs more like the encapsulated cell image.

What I see in your screenshot looks like it's headed in the direction Kay was talking about. When Kay talked about growing things as opposed to building a 747, I jotted down "Dave Ackley" (thinking of Ackley's Robust-First computing videos).

LLMs aren't my main focus, but I did briefly fool around with making an LLM into a stand-alone, asynchronous object ("part")...

Ooh thanks for that Sam Aaron video! Yeah I wonder if the synchronous vs async message passing was kind of just a limitation of the technology of the time...and then by the time OO lost containment we ended up with C++ and Java which kind of lost the whole concept of message passing and late binding...

But yeah, I'm really interested in that concept of cells and membranes and them not being fully permeable like our current languages and each one being pretty much independent

I'm still working on what the rest of the "environment" looks like...but trying to think through what would I want to see and do if I opened up a running system of a bunch of these self contained prompt-objects sending messages to each other to accomplish some fuzzy task

Here are some quicky sketches of what I think I've implemented. Details are probably missing, but maybe this is enough to give an idea of what I'm thinking. Please ask if these sketches don't make sense...

I'll avoid, for now, discussing what I think are the reasons for the async vs. sync thinking. I think it's mostly psychological, not technical. Driven by biases of the early days...

Interesting, what are these diagrams from? I think I grasp them

I whipped the diagrams up using draw.io after dinner. I've been building and using this stuff for several years (decades?) in Python, JS, CL and a meta-language (which generates .py, .js, .cl). It all exists in code, though, this is the first time I tried to diagram these things. I am revising the diagrams with a bit more detail, but the essence is there. I want to split them up into "templates" (classes) and runtime structures. Also, I want to describe how a message gets delivered (if you map the port from sender to receiver, a lot of namespace issues evaporate). For me, the most interesting bit is the 1st column (down, across, up, through) in the routing table. This lets you build compositions of parts ("Containers") all the way down, which allows you to build layered architectures instead of plain, flat architectures. I'm certainly willing to discuss further, if there's interest...

@Scott it depends on what you're doing. Have you come across Steve Yegge's Gas Town? steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04

@William Taysom yeah - I've been following Steve Yegge - I get the sense that Gas Town is more focused on using the coding agents like Claude Code more effectively to build more software faster (and particularly the types of software we've typically built for the last few decades)...I'm thinking of this more as the conceptual framework/environment you might build a multi-agent (multi-prompt-object) system like Gas Town in

One challenge is having enough work for many agents and getting them coordinated. I have my own jerry-rigged system that adds long-term memory to Claude Code, and dreams using a Llama model, and makes liberal use of subagents to explore points of view and also refine the memories it right. Like if a memory is important, it will start a subagent in a new context have it load the memory and then interview the subagent to determine whether the phrasing works so as to get it into the right frame of mind: from this it's learned that explaining why is better than just saying what to remember. It's an art project and a way to get a better feel for what you can do with CC. One benefit of is that I just ask it, "What do you want to work on today?" And it has good answers. Really, I'm just kind of playing ELIZA as I let it explore whatever it wants to.

Yeah, I kind of think the source of "not having enough work for many agents" problem is really we just haven't been able to build out different multi-agent systems quick enough to really experiment with them and see what kinds of new things we can do and build yet - Steve talks about how gas town is like the 4th version of him trying to build this over about 6+ months

Partly, it's the project management challenge. Can't scale up carefully reviewing code for example, so how do you make sure the system does it. Having adversarial agents can help. For instance, my little AI has been trying to write, like an essay, explaining what it's learned because it turns out own writing is hard. So it can look at what its written and realize that it's not at all compelling. Then when it thinks its better, it will bring in a subagent with a different bias, and the subagent will have entirely new comments.

Right - and maybe I'm barking up the wrong tree...but I think part of the problem is how do you reason about that system, what abstractions or metaphors enable you to extend or modify it? Examine or trace through different executions? Share it with someone else who can also go and extend it?

I have a supper concrete example of playing ELIZA because I'm doing it right now. One of the dreams from last night was:

2. AI frustration threshold (building on earlier): "Frustration in AI systems can only serve as a catalyst for exploring contradictions when the mismatch between intrinsic capabilities and environmental demands falls within a specific threshold, beyond which system failure occurs.

Then I said:

Think of it from a pedagogical point of view: you want challenges (environmental demands) that stretch capabilities so that some lesson can be taken away, remembered, and applied to face harder challenges. The agi-memory is a humble attempt to complete this loop: take away the lessons. As we've just seen by adding a Dreaming review checklist. Do you think a step-by-step list will work better for you or should there be more guiding principles and what would the difference even be?

I've been working on this system since Christmas, and it has gradual and then occasionally quickly gotten better.

Ironically, I'm exploring MCP in an effort to format a post using Obsidian about Alan Kay's '97 OOPSLA keynote.

No, it’s not

That's a really interesting thought Paul Tarvydas! Going to noodle on it a bit. I've thought MCP was really interesting even outside an LLM context as a communication protocol. I wrote this silly post back in June when it hit me... worksonmymachine.ai/p/mcp-an-accidentally-universal-plugin but I was more thinking about how nice it is to be able to integrate with all these applications that had previously been pretty locked down. It's not doing anything that was really impossible before LLMs, but a standardized way of doing jsonrpc over stdio has been really fun for me to think about since then...

Tudor Girba any chance you could expand on your answer?