small pondering

 Where Should Orchestration Reside? I ended the last post on a question: maybe LoCAL was about externalizing the LLM internals and making it less opaque… I think it might be time for LoCAL2? LoCAL2 is still a Loosely-Coupled Agent Language model. Agents and tools talk to each other using the same message bus. We still have a critic and memory agent, as well as a few other tools for the LLM to use. The big difference from LoCAL1 is that it doesn’t have the scaffolding layer orchestrating when an Agent should act and what it should do. In LoCAL2, we let the Gemma4 model do its own orchestration natively, thinking through the problem, deciding when to look up memory, do a web search, document lookups, or use other tools. As I was implementing this, two things occurred to me. First, this looks a lot like the hub-spoke architecture that I went to a lot of trouble to get rid of. That looked like we regressed back to an earlier version of LoCAL1. The second was this had the potential of ...

Can Intelligence be Externalized? In my previous posts, I explored the idea that intelligence may emerge not only from sheer parameter scale within a single model, but from the dynamic interactions between models and their environment. That line of thinking led me to build a prototype multi-agent framework I call LoCAL (Loosely-Coupled Agent Language model). The original architecture was straightforward: a collection of specialized role players communicating through a pub-sub message bus, entirely coordinated and driven by a central Core orchestrator. The Refactoring Initially what I was not happy about was that the Core Agent was doing all the heavy lifting. All the other agents just reacted to messages from Core. So, I started refactoring the codebase, systematically moving behavioral rules out of Core into the peer-to-peer interactions between the agents themselves. The first pass reduced the central code by 20%. A second pass cut another 25%. The refactoring kept going until a rad...