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.