A Practical Architecture for Multi-Computer Intranet-Based AI Systems with Shared Models, Shared Vaults, and Sovereign Agent Coordination
DOI:
John Swygert
January 22, 2026
Abstract
This paper extends the “Local Multi-Agent LLM Castle on Consumer Hardware” architecture into a multi-node local intranet system, enabling multiple computers within a home or private physical space to function as a single sovereign AI castle. The architecture allows five or more local machines to operate as coordinated nodes sharing models, agents, memory, and workspaces without external cloud dependency, per-agent billing, or API key sprawl. Each node fulfills a distinct structural role—interactive inference, background indexing, long-running synthesis, memory consolidation, or publishing preparation—while remaining bound by the same upstream/downstream discipline and stewardship rules defined in the original paper. This supplement introduces node roles, intra-castle networking patterns, synchronization strategies, fault tolerance principles, and phased deployment paths for expanding from a single-machine castle into a resilient local AI intranet. The result is a system that approaches cluster-level capability using consumer hardware while preserving authorship, continuity, and control.
1. Purpose And Scope
The first paper demonstrated that a single consumer machine can host a stable, local, multi-agent AI system without cloud dependency. This second paper answers the natural next question:
What happens when we connect multiple local machines together — intentionally, cleanly, and without turning the system into enterprise chaos?
The purpose of this supplement is to show that:
- multiple computers can be unified into one logical castle
- each machine can serve a specialized structural role
- agents can cooperate across nodes without credential explosion
- performance can scale horizontally without violating sovereignty
This is not about data centers, Kubernetes, or cloud orchestration.
This is about homes, studios, workshops, and labs.
2. The Castle Expands: From Tower to Keep
In the single-machine model, the castle consists of:
- one engine room (LLM)
- one vault (workspace)
- multiple stewards (agents)
In the multi-node model:
- each computer becomes a tower
- all towers sit inside one keep
- the keep is defined by the local intranet
Crucially:
The castle boundary is physical and network-local, not logical and abstract.
No public IP exposure is required. No cloud authentication is required. No vendor is required to stay alive.
3. Node Roles (Structure Prevents Chaos)
Multi-computer systems fail when every machine tries to do everything.
This architecture explicitly rejects symmetry.
Each node has a role, not just resources.
3.1 Primary Inference Node (The Engine Tower)
- Hosts the primary LLM endpoint
- Handles interactive agent requests
- Optimized for GPU inference and responsiveness
- Typically the most frequently used machine
This node is the voice of the castle.
3.2 Background Compute Node(s) (The Mill Towers)
- Handle long-running tasks:
- embedding generation
- document indexing
- batch transformations
- cross-project synthesis
- Can run CPU-heavy or memory-heavy workloads
- Do not need fast interactivity
These nodes are the muscle.
3.3 Memory & Index Node (The Archive Tower)
- Maintains vector stores, indices, summaries
- Provides retrieval services to other agents
- Rarely interacts directly with the user
This node is the memory of the castle.
3.4 Steward / Publishing Node (The Gatehouse)
- Packages finalized content
- Generates exports, metadata, DOI stubs
- Interfaces with downstream systems (WordPress, repositories)
- Can remain offline except when publishing
This node is the boundary keeper.
3.5 Optional Experimental Node (The Workshop)
- Used for testing new agents, models, or workflows
- Can be wiped or rebuilt without risk
- Prevents experimental chaos from contaminating the main vault
This node is the sandbox.
4. The Intranet As The Wall
The defining feature of this architecture is that the local intranet is the wall.
4.1 Trust Boundary
All nodes:
- live on the same physical network
- are owned by the same steward
- are not exposed to the public internet
This drastically simplifies:
- authentication
- threat modeling
- credential management
Within the castle:
Trust is assumed, discipline is enforced.
5. Shared Vault Strategies (One Castle, One Memory)
A multi-node system must not fracture its memory.
There are three viable patterns, listed from simplest to most robust.
5.1 Central Vault Node (Recommended First Step)
- One machine hosts the authoritative workspace
- Other nodes mount it via:
- SMB / NFS
- mapped network drives
- File permissions enforce read/write rules
Advantages:
- simple
- transparent
- easy to reason about
Tradeoff:
- single physical point of storage
5.2 Mirrored Vaults With Sync Discipline
- Each node has a local copy of the vault
- Synchronization occurs on defined schedules
- Conflicts resolved by:
- timestamps
- steward rules
- role precedence
This introduces complexity but improves resilience.
5.3 Tiered Vault (Hot / Warm / Cold Storage)
- Active projects live on fast local NVMe
- Archives live on secondary nodes
- Cold storage nodes preserve history
This mirrors human memory more closely and scales well.
6. Agent Coordination Across Nodes
Agents do not migrate between machines.
Agents remain logically centralized but physically distributed in execution.
6.1 Control Plane vs Execution Plane
- One orchestration layer issues tasks
- Tasks are dispatched to nodes based on role
- Results are written back to the shared vault
This prevents:
- duplicate reasoning
- conflicting authority
- emergent chaos
6.2 Message Passing Without Cloud
Communication can occur via:
- shared files (task manifests)
- lightweight local message queues
- simple REST calls inside the intranet
No external brokers are required.
7. Concurrency And Load Distribution
With multiple machines, concurrency becomes a design choice, not a constraint.
7.1 What Stays Centralized
- primary LLM inference (unless deliberately replicated)
- final editorial authority
- canonical memory
7.2 What Scales Horizontally
- embeddings
- indexing
- summarization
- batch rewriting
- cross-project analysis
This avoids VRAM exhaustion while still multiplying output.
8. Failure Containment (Why Multi-Node Is Safer)
A single machine failure in a monolithic system is catastrophic.
In a multi-node castle:
- the engine tower can fail, but memory survives
- a background node can crash without halting work
- experimental failures remain isolated
This is architectural antifragility without enterprise overhead.
9. Local Security Without Enterprise Overhead
Security is achieved through placement and discipline, not bureaucracy.
9.1 Physical Security
- machines are physically local
- storage is not exposed to third parties
9.2 Network Security
- intranet only
- no public endpoints
- optional firewall rules between nodes
9.3 Process Discipline
- agents write only where allowed
- diffs instead of overwrites
- logs everywhere
OAuth, SSO, and identity providers are optional future gates, not internal requirements.
10. Deployment Phases (From One Tower To Five)
Phase 1 — Two-Node Castle
- Node A: primary inference + agents
- Node B: background compute
Goal: prove separation of concerns.
Phase 2 — Three-Node Castle
- Add memory/index node
- Begin persistent retrieval
Goal: continuity across projects.
Phase 3 — Four-Node Castle
- Add publishing/gatehouse node
- Formalize downstream boundary
Goal: protect authorship.
Phase 4 — Five-Node Castle
- Add experimental/workshop node
- Accelerate innovation safely
Goal: sustainable evolution.
11. Why This Beats Any Commercial Offering
Commercial AI platforms:
- meter every interaction
- centralize control
- collapse upstream and downstream
- monetize dependence
This architecture:
- costs nothing per interaction
- scales with hardware you already own
- preserves authorship
- creates compositional intelligence, not rented cognition
Once the castle exists locally, one output channel to ChatGPT or Grok becomes a strategic interface — not a dependency.
The local system does the work.
External models become discussion partners, not labor.
This is where the real leverage appears.
12. Long-Term Implications
A local multi-node AI castle is:
- a personal research institute
- a private studio
- a sovereign archive
- a continuity engine beyond any platform
As software packaging improves, this architecture does not become obsolete — it becomes the substrate those packages must respect.
13. Conclusion
Extending a local multi-agent AI system into a multi-computer intranet does not require cloud orchestration, enterprise tooling, or external authentication frameworks. It requires role clarity, boundary discipline, and shared memory. By treating multiple local machines as towers within a single castle, creators gain horizontal scalability, fault tolerance, and sustained output without surrendering sovereignty. This architecture transforms consumer hardware into a unified cognitive system — one that grows stronger with time, not more entangled.
Appendix A — The Rule That Still Governs Everything
AI upstream.
Publication downstream.
Authority never drifts.
That rule remains unchanged, no matter how many towers are added.
Appendix B — The Real Superpower
The superpower is not speed.
The superpower is continuity without dependence.