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 radical realization hit me: we didn’t need a Core Agent at all. We had crossed into a Stigmergic Architecture.

Stigmergic Architecture

Stigmergy is a mechanism of indirect coordination where independent actors interact through alterations made to a shared environment. Ants use stigmergy natively: they don’t have a central “commander ant” dispatching teams; instead, they lay down localized pheromone trails that automatically change the behavior of the next ant who encounters them.

LoCAL’s shared environment is its Pub-Sub Message Bus and the distributed memory of past interactions. The choreography was entirely driven by decentralized agents checking the bus for specific topics, recognizing tasks they are equipped to handle, and independently broadcasting their results. No need for a orchestrator or a central message board. It all happened dynamically.

However, moving to a decentralized choreography brought a separate challenge: How do you allow agents to adapt their behavior dynamically while keeping their underlying rules simple? If an agent follows a traditional, deterministic state machine, its world is highly rigid and uninteresting. It relies on a classic transition rule: If you are in state s and take action a, transition to state s′: (s, a) → s′. This creates a static environment that limits flexibility. Looking at ways to create non-deterministic agents, I hit on a two-Stage State Transitions.

Two-Stage State Transitions

First we observe the environment to select a strategy:

  • Stage 1 (Observation): (s, e) → a

When an agent is in state s within an environment e, it takes action a. Once the contextual action a is derived, the agent’s second layer executes it to evolve its internal state:

  • Stage 2 (Execution): (s, a) → s′

When an agent in state s takes action a, it moves to state s’. This two stage structure allowed individual agents to vary their behavior organically based on what is happening across the system.

Two Layers of Environment

In LoCAL, the environment e exists across two distinct layers: the routing layer and the prompt layer.

  1. The Routing Layer (Macro-Behavior): This layer determines an agent’s structural strategy by watching the message bus. For example, if an agent notices a history of negative user feedback on a similar past query, or if another agent gives it a bad review, the routing layer triggers an alternate tactical approach.
  2. The Prompt Layer (Micro-Behavior): This layer structures the underlying LLM prompt to fit the chosen strategy. It gathers the raw textual data such as prior answers, conversation history, and peer critiques and injects them directly into the model’s token context window.

By combining two-stage transitions with a two-layered environment, I believe the agents in some ways externalize behaviors internalized inside frontier LLMs.

Context After All?

As mentioned before, we know there are several familiar ways to influence LLM behavior.

  • Training determines what a model knows.
  • Sampling affects how broadly or conservatively it explores possible continuations.
  • Context determines what information is immediately available while the model is generating a response.

I thought that architecture may belong on that list as a separate behavioral lever. But does it?

The LoCAL project emerged from the desire to see if intelligence might arise not just from larger models, but from the way multiple models interact with one another. If changing the architecture produces different behaviors, then architecture itself must be an independent variable.

But architecture never reaches inside the model. It does not alter the weights established during training, and it does not change the mathematics of token selection. Every mechanism — the message bus, skills cards, distributed memory, routing policies, peer critiques — ultimately influences the model through the same channel: context.

The routing layer determines what information arrives at an agent. The message bus determines which agents can influence one another. Distributed memory determines which past experiences remain available. Different mechanisms, certainly, but all of them eventually materialize as tokens inside a context window.

But concluding that it was ‘all context after all’ feels incomplete.

I wonder if what gives architecture its power is not that it introduces additional levers. It has the possibility to externalize processes that frontier models perform internally. A large model silently constructs context, selects strategies, recalls relevant information, and critiques its own reasoning within the hidden dynamics of its network. Those mechanisms are difficult to observe and even harder to control.

LoCAL moves some of those processes into the environment itself. Memory retrieval becomes a visible interaction with distributed memory. Strategy selection becomes an explicit policy. Critique becomes a message on the bus. Context is no longer assembled implicitly inside a model but emerges from the collective activity of many agents. The benefit is that these processes become explicit. Viewed this way, the architecture is exposing and reorganizing pieces of that intelligence into structures that can be inspected, modified, and shared.

Viewed this way, the important question is not whether intelligence can be externalized (you can argue that LoCAL does that). The key is how much of this can we make visible.

Which made me think maybe LoCAL was about externalizing the LLM internals and making it less opaque. I’ve taken LoCAL1 to its conclusion. I think it might be time for LoCAL2?

[You can see the code for LoCAL1 here: https://github.com/rkoike88/LoCAL




Comments

Post a Comment