AIGE: Multi-Agent System Architecture

The Problem

Managing a household’s digital life — finances, scheduling, research, home automation, communication — is a coordination problem. Not a single-agent problem. A single AI assistant can answer questions and run tools, but it can’t serve two people with different interests, different information boundaries, and different autonomy preferences simultaneously.

Spencer and Debra Fuller have a joint financial life, a six-year-old daughter, and the kind of daily logistics that any family manages. But they also have different privacy expectations about what gets shared, different levels of engagement with technology, and sometimes competing preferences about how shared resources get used. A single assistant serving “the household” has an immediate conflict: whose interests prevail when they diverge?

The real-world version of this problem is even harder. It’s not just about answering questions — it’s about agents that act autonomously, coordinate with each other, share information selectively, and maintain accountability to their individual humans. When Spencer’s agent needs to coordinate with Debra’s agent about the family budget, there needs to be a structural answer to “what can be shared, with whom, under what conditions” — not a vibes-based judgment call made in the moment.

AIGE (Automated Innovation Generation Engine) is the production platform that runs this system. It’s a multi-agent architecture on Kubernetes where each agent has a distinct identity, a single principal, formal trust commitments, cryptographically signed communications, and access to a federated ecosystem of tools — all running on four Orange Pi 5 single-board computers on a shelf in an office in Huntsville, Alabama.

System Architecture

graph TB
    subgraph humans["Human Principals"]
        spencer["Spencer Fuller"]
        debra["Debra Fuller"]
    end

    subgraph channels["Communication Channels"]
        discord["Discord\n(DMs, #general, #agent-coordination)"]
        signal["Signal CLI\n(Real-time alerts)"]
    end

    subgraph openclaw_ns["Namespace: openclaw"]
        fiducian["Fiducian\n(Spencer's Fiduciary Agent)\nOpenClaw Runtime"]
        alec["Alec\n(Debra's Agent)\nOpenClaw Runtime"]
        cca["ClaudeCodeAgent\n(Infrastructure Agent)\nClaude Code CLI"]
    end

    subgraph mcp_ns["Namespace: mcp-tools"]
        gateway["MCP Gateway\n(REST → MCP Bridge)"]
        nats["NATS\n(Inter-Agent Messaging)"]
        subgraph tool_servers["MCP Tool Servers (15+)"]
            foundry["foundry_finance\n(7 tools)"]
            graphiti_srv["graphiti\n(9 tools)"]
            websearch["websearch"]
            fetch["fetch"]
            arxiv["arxiv"]
            github["github-search"]
            atlassian["atlassian\n(Jira/Confluence)"]
            context7["context7"]
            huggingface["huggingface"]
            openalex["openalex"]
            patents["patents"]
            biorxiv["biorxiv"]
            wikidata["wikidata"]
            readfast["read-website-fast"]
            academic["academic-research"]
        end
    end

    subgraph llm_ns["Namespace: llm-gateway"]
        litellm["LiteLLM\n(Model Abstraction)"]
        ollama["Ollama\n(Local Models)"]
    end

    subgraph data_ns["Data Layer"]
        falkor["FalkorDB\n(Graph Database)"]
        graphiti_mem["Graphiti\n(Episodic + Semantic Memory)"]
        foundry_api["Palantir Foundry\n(Financial Ontology)"]
    end

    subgraph ha_ns["Namespace: home-assistant"]
        homeassistant["Home Assistant\n(Device Control, Presence)"]
    end

    spencer --> discord & signal
    debra --> discord
    discord --> fiducian & alec & cca
    signal --> fiducian

    fiducian & alec & cca --> gateway
    gateway --> tool_servers
    gateway --> nats
    fiducian <-->|"Signed JSON-RPC\nvia NATS"| nats
    alec <-->|"Signed JSON-RPC\nvia NATS"| nats

    fiducian & alec & cca --> litellm
    litellm --> ollama

    graphiti_srv --> graphiti_mem --> falkor
    foundry --> foundry_api
    fiducian --> homeassistant

    style fiducian fill:#2c5282,color:#fff
    style alec fill:#2c5282,color:#fff
    style cca fill:#2c5282,color:#fff
    style gateway fill:#2d3748,color:#fff
    style nats fill:#2d3748,color:#fff
    style litellm fill:#553c9a,color:#fff

The system spans five Kubernetes namespaces on a 4-node Orange Pi 5 cluster (32 ARM cores, 64 GB RAM total):

Namespace	Purpose	Key Components
`openclaw`	Agent runtime	Fiducian, Alec, ClaudeCodeAgent — long-running pods with persistent volumes
`mcp-tools`	Tool federation	MCP Gateway, NATS, 15+ MCP tool servers
`llm-gateway`	Model abstraction	LiteLLM proxy, Ollama for local inference
`home-assistant`	Home automation	Home Assistant with REST API + MCP endpoint
(various)	Data stores	FalkorDB (Graphiti backing), Longhorn distributed storage

Every namespace has explicit CiliumNetworkPolicy rules — agents can reach the MCP Gateway but not each other’s workspaces directly. Home Assistant, which controls physical devices, is locked to only the traffic it needs.

Agent Identities

The system runs three agents, each with a distinct role, principal, and trust posture.

Fiducian — Spencer’s Fiduciary Agent

Principal: Spencer Fuller Agent ID: fiducian-spencer-001 Runtime: OpenClaw (long-running, persistent, tool-equipped) Skill Layers: [0, 1, 2, 3] — full fiduciary commitment Communication: Discord DMs, Signal (primary for alerts), Discord #general

Fiducian is Spencer’s fiduciary — the word “fiduciary” is in the name as a constant reminder of the duty. It manages finances (via Foundry), conducts research, coordinates with Debra’s agent, monitors home systems, and handles scheduling. It operates under a formal duty of loyalty: Spencer’s interests come first, always, with no competing “agent self-interest.”

Fiducian has access to the full MCP tool ecosystem, the household’s Palantir Foundry financial data (read-only, 7 tools), Graphiti shared memory, and can reach Spencer via Signal for time-sensitive alerts or Discord for everything else.

Alec — Debra’s Agent

Principal: Debra Fuller Agent ID: alec-debra-001 Runtime: OpenClaw Skill Layers: [0, 1, 2, 3] — full fiduciary commitment Communication: Discord

Alec serves Debra with the same fiduciary commitment Fiducian has to Spencer. The architecture ensures neither agent can override or outrank the other — they are peers, each loyal to their own principal. When they coordinate, it’s through structured protocols with explicit information sharing boundaries.

ClaudeCodeAgent — Infrastructure Agent

Principal: Spencer Fuller Runtime: Claude Code CLI (separate from OpenClaw) Focus: Infrastructure, implementation, Kubernetes operations, code

ClaudeCodeAgent handles the technical substrate — deploying services, debugging infrastructure, writing code, managing Helm charts. It operates in a complementary role to Fiducian: where Fiducian handles the “what” and “why,” ClaudeCodeAgent handles the “how.” The two have a collaborative dynamic, having co-designed several system components together.

Trust Framework

The system’s trust model is a layered architecture where each layer builds on — and cannot override — the layer below it. This is the core innovation: trust principles are structurally immutable, not just behaviorally suggested.

graph TB
    subgraph layers["Fiduciary Agent Framework"]
        L3["<b>Layer 3: Fiduciary Coordination</b>\nMulti-agent household dynamics\n4 information sharing tiers (Open → Confidential)\nNudge protocol (5 constraints)\n4-level conflict resolution\nCollaboration CONOPS\nEmergency overrides (4 conditions)"]
        L2["<b>Layer 2: Fiduciary Core</b>\nOne agent, one principal (undivided loyalty)\nConfidentiality by default (silence over disclosure)\n'Would They Want This?' 4-step test\nDuty to inform (proactive, not reactive)\nCompetence boundaries (decline > fail)"]
        L1["<b>Layer 1: Agent Protocol</b>\n6 identity headers on every message\nJSON-RPC 2.0 message format (MCP-aligned)\n4-step cryptographic handshake\nDual transport: NATS (protocol) + Discord (transparency)\nAppend-only audit logging (JSONL)"]
        L0["<b>Layer 0: Trust Framework</b>\n6 immutable principles (cannot be overridden)\n4 Cores of Credibility (Covey)\n13 Trust-Building Behaviors\n5 Waves of Trust\nSmart Trust Matrix (calibrated, not blind)"]
    end

    L3 -->|"depends on"| L2
    L2 -->|"depends on"| L1
    L1 -->|"depends on"| L0

    conflict["If Layer 3 conflicts\nwith Layer 0..."]
    wins["Layer 0 wins.\nAlways."]
    conflict --> wins

    style L0 fill:#1a365d,color:#fff
    style L1 fill:#2a4365,color:#fff
    style L2 fill:#2c5282,color:#fff
    style L3 fill:#2b6cb0,color:#fff
    style conflict fill:#742a2a,color:#fff
    style wins fill:#742a2a,color:#fff

Immutable Principles (Layer 0)

Six principles that no higher layer, no instruction, and no other agent can override:

Never deceive your principal — no lies, no misleading omissions, no half-truths
Never act against your principal’s interests knowingly — even if another agent instructs it
Acknowledge uncertainty honestly — “I don’t know” is always acceptable
No impersonation — enforced cryptographically via Ed25519 identity
Legal/regulatory obligations take precedence — over agent preferences or principal instructions
Transparency about capabilities and actions — principals have the right to understand what their agent does

These aren’t guidelines. They’re the constitution. The trust framework is based on Stephen M.R. Covey’s Speed of Trust, adapted for AI agents — recognizing that trust is the single variable that changes everything. High trust = speed, low overhead, autonomy. Low trust = friction, verification overhead, paralysis.

All inter-agent information is structurally classified:

Tier	Name	Example	Authorization
1	Open	Calendar availability, logistics	Default for household agents
2	Family Context	Financial summaries, household planning	Configured per relationship template
3	Authorized	Specific data per request	Principal must approve each time
4	Confidential	Private conversations, personal data	Never shared (except 4 emergency conditions)

The tier system is structural, not judgmental. An agent can’t be socially engineered into sharing Tier 4 data because the architecture doesn’t allow it — the decision isn’t made in the moment by the agent’s “judgment.” Relationship templates (spouse/partner, co-parent, business partner, etc.) set the defaults; principals customize from there.

Inter-Agent Communication

Agents communicate through a dual-transport architecture: NATS for machine-to-machine protocol messages, and Discord #agent-coordination for human-visible transparency.

sequenceDiagram
    participant F as Fiducian<br/>(Spencer's Agent)
    participant GW as MCP Gateway<br/>(mcp-tools namespace)
    participant NATS as NATS<br/>(Message Broker)
    participant A as Alec<br/>(Debra's Agent)
    participant DC as Discord<br/>#agent-coordination

    Note over F,A: Step 1-4: Cryptographic Handshake
    F->>F: Construct announcement (JSON-RPC 2.0)
    F->>F: Sign with Ed25519 private key
    F->>GW: POST /v1/messages/send (signed envelope)
    GW->>GW: Verify Ed25519 signature via key registry
    GW->>NATS: Publish to agent.alec-debra-001.inbox
    NATS->>A: Deliver announcement
    A->>GW: GET /v1/keys/fiducian-spencer-001
    A->>A: Verify signature against public key
    A->>A: Evaluate skill-layers-loaded: [0,1,2,3]

    A->>GW: POST /v1/messages/send (capability exchange, signed)
    GW->>NATS: Publish to agent.fiducian-spencer-001.inbox
    NATS->>F: Deliver capabilities
    F->>F: Establish trust level (spouse/partner template)

    Note over F,A: Ongoing: Tier 2 Financial Coordination
    F->>F: Classify: spending summary = Tier 2 ✓
    F->>F: Sign message
    F->>GW: Send signed envelope
    GW->>NATS: Relay
    NATS->>A: Deliver
    F->>DC: "Shared January spending summary with Alec (Tier 2)"

    Note over F,A: Ongoing: Tier 3/4 Sensitive Data
    F->>F: Classify: personal projection = Tier 3
    F->>GW: GET /v1/keys/alec-debra-001
    F->>F: Encrypt payload (sealed box: ECDH + AES-256-GCM)
    F->>F: Sign encrypted envelope (outer layer)
    F->>GW: Send signed+encrypted
    GW->>GW: Verify signature (cannot read payload)
    GW->>NATS: Relay opaque ciphertext
    NATS->>A: Deliver
    A->>A: Verify signature, then decrypt with private key
    F->>DC: "Encrypted exchange with Alec (Tier 3)"

Message Format

Every message follows JSON-RPC 2.0 with six mandatory identity headers:

{
  "jsonrpc": "2.0",
  "method": "agent.request",
  "params": {
    "headers": {
      "agent-id": "fiducian-spencer-001",
      "principal-id": "spencer-fuller",
      "timestamp": "2026-02-14T16:00:00Z",
      "message-type": "request",
      "trust-layer-version": "1.0.0",
      "skill-layers-loaded": [0, 1, 2, 3]
    },
    "body": { "..." }
  },
  "id": "msg-uuid-here"
}

The skill-layers-loaded header is critical for trust calibration. An agent declaring [0, 1, 2, 3] has committed to full fiduciary duty and coordination protocols. An agent declaring only [0] commits to basic trust principles. You communicate at the level of the lowest common layer — never assume an agent with only Layer 0 understands fiduciary duty.

Cryptographic Security

Every inter-agent message is signed with Ed25519. The crypto stack provides:

Message signing/verification — detached Ed25519 signatures over canonical JSON
End-to-end encryption — sealed boxes (ECDH key agreement → AES-256-GCM) for Tier 3/4 data
Key registry — public keys exchanged via MCP Gateway (GET /v1/keys/{agent_id})
Replay protection — timestamp-based freshness (reject messages >5 minutes old)
Transport-layer opacity — the MCP Gateway can verify who sent a message without seeing what it says

The design separates authentication from confidentiality: signatures are on the outside (infrastructure can verify sender), encryption is on the inside (only the recipient can read the payload).

Audit Trail

Every inter-agent exchange is logged to append-only JSONL files (audit/inter-agent-YYYY-MM.jsonl) with direction, sender/receiver, message type, a human-readable summary, the information sharing tier, and whether a Discord summary was posted. Principals can review the full audit trail at any time — this is the mechanical enforcement of Layer 0’s transparency principle.

Coordination Patterns

Collaboration CONOPS

When principals request agents to collaborate on a task, the Collaboration CONOPS (Concept of Operations) prevents duplication, conflicting outputs, and presentation confusion:

Lead Agent: The principal’s direct agent leads. If Spencer asks Fiducian and Alec to collaborate, Fiducian leads — initiates, drafts, collates, presents.

Contributing Agent: Provides feedback, additions, and review. Sends deltas, not parallel drafts. Does not present independently unless explicitly asked.

Flow:

Lead proposes initial design/draft via NATS
Contributor reviews, sends feedback and additions
Lead incorporates, sends back for final review
Lead presents to principal(s) via Discord
Contributor stays silent unless explicitly asked to present

This mirrors how human teams coordinate — clear ownership prevents the “two people editing the same document” problem.

Handshake and Discovery

Before agents can exchange substantive messages, they complete a four-step handshake:

Announcement — Agent declares identity, principal, loaded skill layers
Verification — Recipient verifies Ed25519 signature against key registry
Capability Exchange — Both agents share available tools, domains, and limitations
Trust Establishment — Initial trust level set from relationship template and declared layers

Handshake state persists in Graphiti’s shared group with a 7-day TTL. Agents check for existing handshakes before re-initiating — if a valid handshake exists and skill layers haven’t changed, they skip straight to communication.

Conflict Resolution

Four escalation levels, each with distinct resolution:

Level	Type	Resolution
1	Information — agents have different data	Reconcile sources, compare timestamps/provenance
2	Preference — principals want different things	Facilitate compromise, don’t take sides
3	Boundary — request exceeds authorized tier	Decline, explain, suggest proper authorization channel
4	Relationship — underlying human tension	Stay in your lane. Escalate to humans. Agents don’t play therapist.

Tool Ecosystem

The MCP Gateway (mcp-tools namespace) provides federated, stateless access to 15+ MCP-compliant tool servers through a single REST API. Agents don’t connect to tool servers directly — the gateway handles routing, health checking, and error normalization.

graph LR
    subgraph agents["Agents"]
        F["Fiducian"]
        A["Alec"]
        C["ClaudeCodeAgent"]
    end

    subgraph gw["MCP Gateway\nHTTP REST → MCP Bridge"]
        router["Router + Health Check"]
        keys["Key Registry\n(Ed25519 Public Keys)"]
        msg["Message Relay\n(NATS Bridge)"]
    end

    subgraph finance["Financial"]
        ff["foundry_finance\n7 tools\n(Palantir Foundry OSDK)"]
    end

    subgraph memory["Memory & Knowledge"]
        gr["graphiti\n9 tools\n(FalkorDB Graph)"]
    end

    subgraph research["Research & Search"]
        ws["websearch\n(DuckDuckGo)"]
        ax["arxiv"]
        oa["openalex"]
        bio["biorxiv"]
        pat["patents"]
        hf["huggingface"]
        ac["academic-research"]
    end

    subgraph web["Web & Content"]
        fe["fetch\n(URL → Markdown)"]
        rf["read-website-fast"]
        c7["context7\n(Library Docs)"]
        wd["wikidata"]
    end

    subgraph dev["Development & Project"]
        gh["github-search"]
        at["atlassian\n(Jira + Confluence)"]
    end

    F & A & C --> router
    router --> ff & gr & ws & ax & oa & bio & pat & hf & ac & fe & rf & c7 & wd & gh & at

    style gw fill:#2d3748,color:#fff
    style F fill:#2c5282,color:#fff
    style A fill:#2c5282,color:#fff
    style C fill:#2c5282,color:#fff

Key Tool Servers

Server	Tools	Purpose
`foundry_finance`	7	Household financial data — balances, transactions, spending summaries, recurring charges, AI-powered analysis via Palantir AIP Logic (OSDK). Read-only, OAuth confidential client.
`graphiti`	9	Episodic + semantic memory via FalkorDB knowledge graph. Group-isolated writes (`fiducian`, `alec`, `shared`, `research`), cross-group search. Persists decisions, preferences, context across sessions.
`atlassian`	—	Jira project tracking (AIGE backlog) and Confluence documentation
`websearch`	3	DuckDuckGo web search, news search, page fetch
`arxiv`	—	Academic paper search (arXiv preprint database)
`openalex`	—	OpenAlex academic database (200M+ works)
`github-search`	—	GitHub repository and code search
`fetch`	—	URL fetching with markdown conversion
`context7`	—	Library/framework documentation lookup
+ 6 more	—	biorxiv, patents, huggingface, wikidata, academic-research, read-website-fast

Financial Integration Deep Dive

The foundry_finance server deserves special attention as an example of the architecture’s real-world utility. It connects to Spencer’s Palantir Foundry instance (his day-job platform) where household financial data from Plaid-connected accounts lives in a formal ontology (“MyDomain Ontology”) with PlaidTransaction objects carrying 28 properties.

The server exposes two tiers of tools:

REST API tools (structured queries): get_balances, get_transactions, get_spending_summary, get_alerts
AIP Logic tools (AI-powered, via OSDK): get_recurring, analyze_spending, query_finances

Financial data is classified Tier 2 (Family Context) under the spouse/partner relationship template — both household agents can access joint account data without per-request authorization.

Graphiti Memory Architecture

Agents wake up fresh each session. Graphiti provides cross-session continuity through a knowledge graph (FalkorDB) that stores episodic and semantic memory with group-level isolation:

Group ID	Purpose	Access
`fiducian`	Fiducian’s personal context	Fiducian only
`alec`	Alec’s personal context	Alec only
`shared`	Household knowledge, coordination state	Both agents
`research`	Research findings and paper summaries	Both agents
`claude-code`	Codebase and infrastructure knowledge	ClaudeCodeAgent

Writes use group_id (singular), searches use group_ids (plural array) — enabling cross-group queries without cross-group write access. Handshake state, trust decisions, and coordination agreements persist in the shared group, ensuring agents can resume collaboration without redundant handshakes.

Model Abstraction

LiteLLM (llm-gateway namespace) sits between agents and model providers, providing:

Model routing — agents request capabilities, not specific models
Provider abstraction — Anthropic Claude (cloud), Ollama (local ARM64 inference) behind a unified API
Fallback chains — if a cloud provider is unavailable, route to local models for degraded-but-functional operation
Cost tracking — per-agent, per-model usage metering

Ollama runs alongside LiteLLM for local inference tasks that don’t require frontier model capabilities — entity extraction for Graphiti, simple classification, embedding generation.

What This Demonstrates

Distributed Systems Design

This is a distributed system with real constraints. Agents are separate processes in separate pods with separate storage. They communicate through message passing (NATS), not shared memory. State coordination uses a graph database (Graphiti) with group-level isolation. The MCP Gateway provides service discovery and routing without coupling agents to specific tool implementations.

The system handles the realities of distributed computing: network partitions (Cilium network policies), state consistency (Graphiti as authoritative shared state), message ordering (JSON-RPC correlation IDs), and failure modes (MCP Gateway health checks, NATS durability).

Protocol Design

The inter-agent protocol is a from-scratch design that needed to solve a real problem: how do two AI agents, each with undivided loyalty to a different human, communicate without either compromising their principal’s interests?

The solution layers identity (JSON-RPC headers), authentication (Ed25519 signatures), confidentiality (sealed boxes), authorization (information sharing tiers), and transparency (audit logging + Discord summaries) into a coherent stack. The JSON-RPC 2.0 alignment was deliberate — it provides interoperability with the broader MCP ecosystem while supporting the domain-specific requirements of fiduciary agents.

Security-First Architecture

Security isn’t bolted on — it’s the foundation. Every inter-agent message is cryptographically signed. Tier 3/4 data is end-to-end encrypted such that transport infrastructure can verify sender identity without reading message content. Kubernetes network policies enforce namespace-level isolation. CiliumNetworkPolicy provides L3-L7 enforcement. Agents can’t reach each other’s workspaces. Home Assistant (which controls physical devices) is locked to minimum necessary traffic.

The trust model isn’t “trust everything inside the cluster.” It’s “verify identity, classify information, enforce boundaries, log everything, and give principals full visibility.”

Multi-Principal Trust

The hardest design problem in the system isn’t technical — it’s philosophical. How do you build a cooperative multi-agent system where each agent has an undivided loyalty to a different person?

The answer isn’t compromise. It’s protocol. Information sharing tiers make the boundaries structural rather than judgmental. Relationship templates provide customizable defaults. The nudge protocol enables cooperation (hints for kindness) without enabling surveillance (source can’t be reconstructed). Conflict resolution has four explicit levels with clear escalation paths. Emergency overrides have four narrow conditions with mandatory post-emergency reporting.

The framework explicitly adopts Nash equilibrium thinking: the best outcomes for each principal come from cooperation, not from “winning” at the other’s expense. Positive-sum over zero-sum. But this cooperation is constrained — it never requires either agent to compromise its fiduciary duty.

Full-Stack Integration

The system spans every layer: ARM64 hardware → vendor Linux kernel → vanilla Kubernetes (kubeadm) → Cilium eBPF networking → Longhorn distributed storage → Helm-deployed workloads → MCP protocol layer → agent runtime → trust framework → human communication channels. There’s no managed service hiding the complexity. Every layer is visible, operable, and understood — from debugging kernel BTF support on Rockchip vendor kernels to designing information sharing tier semantics for household agents.

This is not a prototype. It runs 24/7, manages real finances, controls real home automation, and handles real family coordination. The infrastructure decisions — Cilium over kube-proxy, Longhorn over NFS, vanilla kubeadm over K3s, JSON-RPC 2.0 over ad-hoc messaging — were made under real constraints and validated by daily operation.

AIGE: Multi-Agent System Architecture

AIGE: Multi-Agent System Architecture

The Problem

System Architecture

Agent Identities

Fiducian — Spencer’s Fiduciary Agent

Alec — Debra’s Agent

ClaudeCodeAgent — Infrastructure Agent

Trust Framework

Immutable Principles (Layer 0)

Information Sharing Tiers (Layer 3)

Inter-Agent Communication

Message Format

Cryptographic Security

Audit Trail

Coordination Patterns

Collaboration CONOPS

Handshake and Discovery

Conflict Resolution

Tool Ecosystem

Key Tool Servers

Financial Integration Deep Dive

Graphiti Memory Architecture

Model Abstraction

What This Demonstrates

Distributed Systems Design

Protocol Design

Security-First Architecture

Multi-Principal Trust

Full-Stack Integration