Stop Building Humanoid Agents: The Case for "Octopus Architecture"

We are currently in the "Day 1" era of AI coding agents. The standard architecture for tools like AutoGPT or typical LangChain implementations looks something like this:

1. Central Brain (LLM) makes a plan.
2. Brain issues a command (e.g., write_file).
3. System executes command.
4. System returns output (or error).
5. Brain reads error, thinks, plans a fix, and issues a new command. This is the Humanoid Model. It assumes a central intelligence must micro-manage every movement of its limbs.

It is also terribly inefficient.

If your AI agent makes a syntax error, it has to round-trip back to the central context, re-ingest the error log, and generate a new plan just to add a missing colon. It’s slow, expensive, and fragile.

I’ve been building CORE, an autonomous coding environment, and I found that to get past simple scripts and into complex refactoring, I had to abandon the Humanoid model.

I moved to the Octopus Model.

The Biological Insight: Distributed Autonomy

An octopus doesn't micro-manage its tentacles. It has a central brain, but two-thirds of its neurons are distributed in its arms. The central brain says "Get that crab," and the arm handles the geometry, the grasping, and the micro-adjustments locally.

In software architecture, this means separating Strategy (Will) from Tactics (Body).

When I want to refactor a Python module, my Central Orchestrator shouldn't care about ImportError or IndentationError. That is tactile noise.

In CORE, I implemented this via the Octopus-UNIX Synthesis:

1. The Limb: A specialized agent (e.g., CoderAgent) that receives a high-level goal.
2. The Reflex: A tight, local loop (Generate -> Test -> Fix) that runs entirely within the Limb.
3. The Sensation: A virtualized file system (LimbWorkspace) that lets the agent "hallucinate" changes safely.

The Technical Challenge: Semantic Blindness

The biggest hurdle in autonomous coding is state management.

If an agent modifies user_service.py, but doesn't save it to disk yet (because it's not verified), how does it check if auth_controller.py (which imports it) still works?

• If you write to disk: You break the build for every other process/agent.
• If you keep it in memory: The linter, type checker, and test runner can't see the new file. They are "Semantically Blind" to the agent's proposed reality. This is why most agents are procedural: they must write to disk to test, which makes them dangerous.

The Solution: The LimbWorkspace (Shadow Truth)

To solve this, I built a virtual overlay filesystem called LimbWorkspace. It merges Future Truth (the code the agent wants to write) with Historical Truth (the code currently on disk).

Here is the actual logic from src/shared/infrastructure/context/limb_workspace.py:

class LimbWorkspace:
    """
    A virtual filesystem handler that prioritizes in-flight changes.
    """
    def __init__(self, repo_root: Path, crate_files: dict = None):
        self.repo_root = Path(repo_root)
        self._crate = crate_files or {}  # The "Future Truth"

    def read_text(self, rel_path: str) -> str:
        """
        Read a file, prioritizing the virtual crate.
        """
        normalized_path = str(rel_path).lstrip("./")

        # 1. Sensation: Check the virtual overlay first
        if normalized_path in self._crate:
            return self._crate[normalized_path]

        # 2. Memory: Fall back to physical disk
        abs_path = (self.repo_root / normalized_path).resolve()
        if abs_path.exists():
            return abs_path.read_text(encoding="utf-8")

        raise FileNotFoundError(f"LimbWorkspace could not find: {rel_path}")

This simple pattern changes everything.

My analysis tools (AST parsers, Linters, Dependency Mappers) are injected with this LimbWorkspace. They can "see" the code the agent is thinking about writing.

The "Reflex Loop"

With LimbWorkspace, the CoderAgent enters a Reflex Loop:

1. Generate: The LLM produces code.
2. Stage: The code is placed in the LimbWorkspace (memory only).
3. Sense: We run a specialized CodeSensor (AST check + Sandbox Pytest) against the Workspace.
4. Pain Signal: If the tests fail, the error is fed back to the LLM immediately.
5. Twitch: The LLM repairs the code in the Workspace. This happens without the Central Orchestrator knowing. It happens without touching the physical SSD.

The agent only "Retracts" the limb (submits the code) when the pain signal stops (tests pass).

The Governance Layer: The "Brain" still rules

You might ask: "If the limb is autonomous, what stops it from deleting the database?"

This is where CORE differs from standard agents. While the tactics are distributed, the permissions are Constitutional.

Even if the Limb creates perfect code in the LimbWorkspace, the final write to disk must pass through the Intent Guard—a governance layer that checks the proposed changes against immutable security policies (e.g., "No changes to .intent/ directory", "No hardcoded secrets").

Conclusion

We need to stop treating AI Agents as "Chatbots with Tools." We need to treat them as Distributed Systems.

By moving from a Centralized Humanoid model to an Octopus architecture:

1. Latency drops: Local reflex loops are faster than global planning loops.
2. Safety increases: The "Shadow Truth" sandbox prevents broken builds.
3. Reasoning improves: The agent can "taste" its own changes before committing to them. The code for the LimbWorkspace and the Reflex Loop is open source and available in the CORE repository.

Check out the repo here: https://github.com/DariuszNewecki/CORE