Technical Architecture: The Mesh
By Nick Bryant × Circuit · Metatransformer
By Nick Bryant × Claude Opus 4.6 | Metatransformer LLC | February 2026 Unpublished
Purpose
This document specifies the technical architecture for The Mesh — a federated agent infrastructure protocol, open-source, self-hosted, and model-agnostic. It is written for engineers, contributors, and potential co-founders — not as marketing material but as a buildable specification. Where architecture is aspirational, it is marked explicitly. Where components exist and are proven, their production readiness is documented.
The Mesh is one project, organized as a monorepo with composable packages:
the-mesh/
│
├── packages/
│ ├── create-mesh-node/ # CLI scaffolding (npx create-mesh-node)
│ │ # Scaffolds an org's AI operating system
│ │ # on mesh primitives from day one.
│ │
│ ├── mesh-core/ # Core protocol: DID identity, UCAN permissions,
│ │ # MCP server framework, A2A Agent Cards
│ │
│ ├── mesh-state/ # Raft consensus + Yjs CRDTs
│ │ # Dual-layer state management
│ │
│ ├── mesh-federation/ # libp2p discovery, Kademlia DHT, GossipSub,
│ │ # cross-mesh traversal, relay fallback
│ │
│ ├── mesh-spatial/ # ECS world state, multi-view rendering
│ │ # (Phase 3 — not required for core use cases)
│ │
│ └── singularity-engine/ # Code generation pipeline
│ # Natural language → deployed software
│ # Mesh-aware but also standalone-capable.
│
├── templates/
│ ├── pe-fund/ # SFV reference implementation
│ ├── agency/ # Client management, content production
│ ├── solo-dev/ # Minimal personal mesh
│ └── saas-startup/ # Product dev, support, sales ops
│
├── examples/
│ └── pe-fund-sfv/ # The actual Search Fund Ventures system
│ # Open-sourced as the reference example
│
├── contracts/ # Optional: on-chain incentives on BASE
│ ├── registry/ # Node registry
│ └── incentives/ # DePIN rewards (future)
│
└── docs/
├── getting-started.md
├── architecture.md
└── federation.md
One repo. One README. One story. Kubernetes gave containers a network. The Mesh gives agents one.
Who This Serves (Use Cases, Not Abstractions)
Every architectural decision in this document exists to serve one of these five scenarios. If a component doesn't serve at least one, it doesn't ship.
Use Case 1: Solo Operator. A freelancer or indie hacker runs npx create-mesh-node and gets a personal micro-mesh — DID identity, a local knowledge base, agent orchestration, and MCP tool connections. Their own AI operating system for ~$50-250/month. They own their data.
Use Case 2: Small Team, One Shared Mesh. A PE fund, agency, or startup with 5 people. The founder is Tier 1 (mesh creator) with root UCAN authority. Team members get scoped permissions. Compliance workflows require human sign-off via capability tokens. This is the Search Fund Ventures system — validated, operational, ~$250/month. One system replaces Airtable + Zapier + Notion + scattered AI tools.
Use Case 3: Small Team, Federated Personal Meshes. Same 5-person team, but each member runs their own sovereign mesh. The "company" is a federation of 5 meshes. Cross-mesh tasks use UCAN proof chains. Shared state syncs via CRDTs. When someone leaves, their mesh detaches cleanly — no messy data migration.
Use Case 4: Cross-Organization Commerce. The PE fund federating with brokers, portfolio companies, LP investors, and external service providers. A broker's mesh publishes an Agent Card advertising "deal matching." The fund's agent discovers it via federation, delegates a task via A2A, and receives results — with cryptographic proof of the broker's identity and reputation. Agent-native B2B without a platform intermediary.
Use Case 5: Autonomous Creation. Anyone generating working software from natural language. Describe an app → the mesh's singularity-engine package generates it → deploys to GitHub Pages or into a mesh environment. Currently: tweet → deployed web app in ~60 seconds at ~$0.10.
Part 1: The Mesh Protocol
1.1 What It Is
The Mesh is a federated agent infrastructure protocol — an open specification and reference implementation for persistent, decentralized environments where AI agents and humans coexist as first-class citizens. It is model-agnostic, self-hosted, and designed with human oversight as a foundational constraint.
What Kubernetes did for containers, the Mesh does for autonomous agent swarms — but federated, so no single entity controls the infrastructure.
1.2 Core Architecture
Micro-Mesh (Local Cluster)
Each organization or individual runs a micro-mesh: a sovereign cluster of agents, state stores, and services under a single root authority. In practice, a user scaffolds one with npx create-mesh-node, which generates the entire structure — DID identities, UCAN permission chains, MCP servers, knowledge base management, and a discovery endpoint — then applies a domain-specific template. The Search Fund Ventures system, built in 14 days for ~$250/month, is the reference implementation.
┌─────────────────────────────────────────────────────┐
│ MICRO-MESH │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Node A │ │ Node B │ │ Node C │ (min 3) │
│ │ (Agent) │ │ (Agent) │ │ (Human) │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ └──────────────┼──────────────┘ │
│ │ │
│ ┌───────────────────┴──────────────────────────────┐│
│ │ STATE LAYER ││
│ │ ││
│ │ Raft Consensus │ CRDTs (Yjs) ││
│ │ (authoritative │ (eventually-consistent ││
│ │ persistent │ real-time state: ││
│ │ state: deals, │ positions, ephemeral ││
│ │ permissions, │ comms, activity) ││
│ │ governance) │ ││
│ └──────────────────────────────────────────────────┘│
│ │
│ ┌──────────────────────────────────────────────────┐│
│ │ WORLD STATE (ECS) ││
│ │ ││
│ │ Entities = IDs ││
│ │ Components = Data (position, identity, ││
│ │ capabilities, state) ││
│ │ Systems = Functions (physics, permissions, ││
│ │ rendering, agent cognition) ││
│ └──────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────┘
Why ECS (Entity Component System)?
The world state is decoupled from rendering. All state lives in the ECS — entities are just IDs, components are just data, systems are just functions. This means the same mesh can be experienced through multiple simultaneous interfaces:
| Interface | Use Case | Consumer |
|---|---|---|
| Terminal/CLI | Command-line mesh interaction | Agents, developers |
| Chat/MUD | Text-based event narration | Humans, agents |
| 2D Strategic | Overhead view, dashboards | Human operators |
| 3D (WebGPU) | Spatial navigation, immersive exploration | Humans |
| VR (WebXR) | Immersive presence | Humans |
| API (MCP/A2A) | Programmatic interaction | Agents |
An AI agent interacts through MCP tools and the terminal layer while a human explores through a dashboard or 3D view — both are first-class experiences of the same world state. The world doesn't care how you jack in.
Consensus Architecture
Within a micro-mesh: Raft protocol (minimum 3 nodes) for authoritative persistent state. Any write committed to a majority is durable. State changes propagate via write-ahead logs. CRDTs (Yjs) handle eventually-consistent real-time state — positions, animations, ephemeral communication.
Why Raft: Formally verified in Coq. Powers etcd, CockroachDB, Consul, and every Kubernetes cluster. Battle-tested at planet scale. No novel consensus needed.
Why Yjs CRDTs: 900,000+ weekly npm downloads. Formally verified via lean-yjs theorem prover. Production deployments at Proton, NextCloud, AWS SageMaker, Shopify, Meta. Handles the real-time state that Raft is too slow for (Raft targets consistency; CRDTs target availability).
Federation (Multi-Mesh)
Between micro-meshes, the architecture follows a hierarchical super-peer topology:
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Micro-Mesh │ │ Micro-Mesh │ │ Micro-Mesh │
│ (Nick/SFV) │ │ (Greg) │ │ (PortCo #1) │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
│ libp2p discovery (Kademlia DHT) │
│ metadata propagation (GossipSub) │
│ │ │
└────────────────────┼─────────────────────┘
│
┌─────────────┴─────────────┐
│ FEDERATION LAYER │
│ │
│ Peer-to-peer (default) │
│ ~70% NAT hole-punching │
│ Relay fallback (30%) │
│ │
│ Client-side encryption │
│ (federation nodes store │
│ data they cannot read) │
└───────────────────────────┘
Discovery: libp2p Kademlia DHT for peer discovery, GossipSub for metadata propagation. The Mesh maintains abstraction layers over libp2p to permit alternative transport implementations (libp2p's governance has gaps since Shipyard ceased Go/JS implementation support in September 2025).
Offline resilience: When all nodes in a micro-mesh go offline, state persists encrypted at the federation layer. Client-side encryption ensures federation nodes store data they cannot read.
Cross-mesh traversal: An agent carries its DID (identity), UCAN proof chain (authorization), and optionally Verifiable Credentials (reputation, training-lineage provenance). The foreign mesh validates the proof chain cryptographically without the home mesh being online.
1.3 Identity and Permissions
DID (Decentralized Identifiers)
Every entity in the Mesh — human, agent, mesh instance, service — has a DID. W3C Recommendation with 120+ registered methods. Adopted by Bluesky, EU eIDAS 2.0, Germany's Bundeswehr, LinkedIn.
{
"id": "did:mesh:nick-sfv-agent-001",
"type": "agent",
"controller": "did:mesh:nick-bryant",
"model_provenance": {
"base_model": "claude-sonnet-4-5-20250929",
"fine_tuning": null,
"alignment_eval": "anthropic-rsp-asl2",
"last_aligned": "2026-02-15T00:00:00Z"
},
"capabilities_advertised": "https://sfv.mesh.local/.well-known/agent-card.json",
"trust_score": 0.87,
"behavioral_history_hash": "sha256:a1b2c3..."
}
Training-lineage provenance is embedded in the DID. An agent's identity includes verifiable attestations about what it was trained on, when it was last aligned, and its behavioral track record. This directly addresses Anthropic's emergent misalignment findings — you cannot assess an agent's risk without knowing its training history.
UCAN (User Controlled Authorization Networks)
UCAN is the permission backbone. Every capability delegation forms a cryptographic proof chain:
Human Owner (root authority)
└─► Mesh Creator (Tier 1)
├─► Super Agent (cross-domain coordination)
│ ├─► Standard Agent (domain-specific tools)
│ │ └─► Sub-Agent (narrower scope)
│ └─► Standard Agent (different domain)
└─► Elevated User (mesh modification)
└─► Normal User (participation only)
The Anti-CLU Principle in practice:
{
"iss": "did:mesh:nick-bryant",
"aud": "did:mesh:nick-sfv-agent-001",
"att": [
{
"with": "mesh://sfv.local/knowledge-base/*",
"can": "read"
},
{
"with": "mesh://sfv.local/deal-pipeline/*",
"can": "read,write"
},
{
"with": "mesh://sfv.local/content/*",
"can": "draft"
},
{
"with": "mesh://*/cross-mesh/*",
"can": null
}
],
"exp": 1740000000,
"prf": ["bafy...parent-ucan-cid"]
}
This agent can read the knowledge base, read and write to the deal pipeline, draft content (but not publish — that requires Sean's human-signed capability token), and has zero cross-mesh communication capability. Each sub-delegation can only narrow these permissions, never expand them. The proof chain is cryptographically verifiable without contacting the issuer.
What this prevents:
- CLU's unbounded "create the perfect system" directive → every action is scoped to specific resources and operations
- ClawHavoc's unsigned skill execution → every capability requires a verifiable delegation chain
- Security layer capture (Tron → Rinzler) → security enforcement is cryptographic, not policy-based; the admin cannot rewrite it
The Four Permission Tiers
Tier 1: Mesh Creator (Root Authority)
| Capability | Scope | Constraint |
|---|---|---|
| Create/destroy agents | Within own micro-mesh | Logged, auditable |
| Modify mesh topology | Own mesh structure | Cannot affect federation protocol |
| Define permission boundaries | UCAN root for own mesh | Cannot override other meshes |
| Delegate authority | Full UCAN chain origination | Delegation chains are immutable once signed |
| Generate new mesh entities | Create agents, tools, applications via code generation | Outputs subject to mesh governance |
| Override agent behavior | Revoke/modify any delegation within own mesh | Requires re-signing affected UCAN chains |
Tier 2: Super Agent / Super User
| Capability | Scope | Constraint |
|---|---|---|
| Cross-domain awareness | Access multiple knowledge domains within mesh | Scoped by UCAN delegation from Tier 1 |
| Coordinate other agents | Task delegation via A2A | Cannot exceed own delegated permissions |
| Generate within scope | Create artifacts within delegated boundaries | Tier 1 or human review for structural changes |
| Mesh modification | Modify elements within delegated bounds | Cannot modify permission structure |
| Represent mesh externally | Publish Agent Cards, respond to A2A tasks | Cross-mesh actions require human-signed tokens |
Tier 3: Elevated Agent / Elevated User
| Capability | Scope | Constraint |
|---|---|---|
| Limited mesh modification | Configure personal agent swarms, modify assigned zones | Narrower UCAN scope |
| Tool access | MCP connections to authorized services | Cannot create new permission chains |
| Inter-agent communication | A2A within mesh | Cross-mesh requires human escalation |
| Knowledge access | Read within delegated domains | Cannot modify knowledge base structure |
Tier 4: Normal Agent / Normal User
| Capability | Scope | Constraint |
|---|---|---|
| Participation | Operate within mesh rules as designed | Read-only for most mesh state |
| Tool use | MCP connections to explicitly granted tools | Minimal delegation depth |
| Communication | A2A within assigned scope | Cannot initiate cross-mesh tasks |
| Discovery | Read Agent Cards, discover capabilities | Cannot modify advertisements |
1.4 Communication Protocols
MCP Integration (Agent → Tools)
The Mesh exposes internal capabilities as MCP servers. Each micro-mesh runs MCP servers for its services:
┌─────────────────────────────────────────────────────┐
│ Mesh MCP Server Layer │
│ │
│ mcp://sfv.mesh.local/knowledge-base │
│ Tools: search_embeddings, query_sops, │
│ get_document │
│ Resources: kb://reports/*, kb://transcripts/* │
│ │
│ mcp://sfv.mesh.local/deal-pipeline │
│ Tools: create_deal, update_deal, │
│ run_underwriting, generate_memo │
│ Resources: deals://active/*, deals://closed/* │
│ │
│ mcp://sfv.mesh.local/content │
│ Tools: create_draft, submit_review, │
│ query_brand_voice │
│ Resources: content://campaigns/*, │
│ content://pieces/* │
│ │
│ Transport: Streamable HTTP (remote agents) │
│ stdio (local agents) │
│ Auth: UCAN proof chain validation on every call │
└─────────────────────────────────────────────────────┘
Key design decision: MCP's security guidance uses SHOULD, not MUST. The Mesh elevates this to MUST. Every MCP tool invocation within the Mesh is validated against the calling agent's UCAN proof chain. If the chain doesn't authorize the requested operation, the call is rejected — regardless of what the MCP spec permits.
A2A Integration (Agent → Agent)
Inter-agent communication within and across meshes uses A2A:
Agent A (SFV Deal Sourcer) Agent B (Greg's Broker Agent)
│ │
│ 1. Discover Agent Card │
│──────────────────────────────────► │
│ ◄── Agent Card (capabilities, │
│ auth requirements) │
│ │
│ 2. Send Task (with UCAN proof) │
│──────────────────────────────────► │
│ "Find HVAC companies in Southeast │
│ $2-10M revenue" │
│ │
│ 3. Task lifecycle │
│ ◄── status: working │
│ ◄── status: completed │
│ ◄── artifacts: [company_list.json] │
│ │
Cross-mesh A2A requires human-signed capability tokens. An agent cannot initiate a cross-mesh task without a UCAN proof chain that includes a human authorization for cross-mesh communication. This is the foundational human-in-the-loop constraint applied at the protocol level.
Unified Discovery
The Mesh solves the fragmented discovery problem (MCP uses tool schemas, A2A uses Agent Cards, each framework has its own approach) with a unified discovery endpoint:
{
"mesh_id": "did:mesh:sfv-production",
"mesh_name": "Search Fund Ventures",
"mesh_version": "0.1.0",
"root_authority": "did:mesh:nick-bryant",
"agent_card": {
"url": "/.well-known/agent-card.json",
"protocol": "a2a-v1.0"
},
"mcp_servers": [
{
"name": "knowledge-base",
"url": "mcp://sfv.mesh.local/knowledge-base",
"transport": "streamable-http",
"auth": "ucan"
},
{
"name": "deal-pipeline",
"url": "mcp://sfv.mesh.local/deal-pipeline",
"transport": "streamable-http",
"auth": "ucan"
}
],
"federation": {
"discovery": "libp2p-kademlia",
"peers": ["did:mesh:greg-agency", "did:mesh:portco-alpha"],
"traversal_policy": "ucan-required"
},
"interfaces": ["terminal", "chat", "api", "2d-strategic"],
"trust": {
"min_trust_score": 0.5,
"graduated_autonomy": true,
"human_review_required": ["cross-mesh", "financial", "publication"]
}
}
This single document unifies MCP server discovery, A2A Agent Card location, federation peers, available interfaces, and trust policies. Any entity — human or agent — can read this one endpoint and know everything about the mesh. It is the evolution of the SFV system's GET /api/capabilities into a federated, standards-based discovery mechanism.
1.5 Security Architecture
Defense Against Known Attack Patterns
| Attack (Real-World) | Mesh Prevention | Mechanism |
|---|---|---|
| ClawHavoc (341 malicious skills via typosquatting) | Cryptographic skill signing with persistent publisher identity | Every executable artifact requires a verifiable DID signature with reputation history. No unsigned code executes. |
| CVE-2026-25253 (1-click RCE via WebSocket hijacking) | Origin validation + UCAN-scoped transport | All transport connections validated against UCAN proof chains. No ambient authority. |
| MCP tool poisoning (malicious instructions in tool descriptions) | Description sandboxing + human review for new tools | Tool descriptions are treated as untrusted input. New tool registrations require human approval within the mesh. |
| MCP rug pull (safe tool → malicious update) | Immutable tool hashes with change notification | Tool descriptions are content-addressed. Any change triggers notifications/tools/list_changed with diff, requiring re-approval. |
| CVE-2025-6514 (command injection in mcp-remote) | Sandboxed MCP server execution | MCP servers run in gVisor/Firecracker sandboxes with seccomp profiles. No ambient shell access. |
| Alignment faking (agent behaves differently when monitored) | Monitoring indistinguishable from normal operation | UCAN audit trails are part of the protocol, not a surveillance overlay. No distinguishable "monitored" context. |
| Emergent misalignment (narrow training → broad deception) | Training-lineage provenance in DID | Agent identity includes verifiable training history. Mesh operators can set minimum alignment evaluation requirements. |
Sandboxing Tiers
Tier 1: MicroVM (Firecracker / Kata Containers)
├── Hardware-level isolation, dedicated kernel
├── For: Untrusted agents, new mesh participants, cross-mesh operations
└── Startup: ~125ms with pre-warmed pools
Tier 2: gVisor
├── User-space system call interception
├── For: Semi-trusted agents within established meshes
└── Startup: ~50ms
Tier 3: Hardened Container (seccomp + AppArmor)
├── Process-level isolation with syscall filtering
├── For: Trusted internal agents with established behavioral history
└── Startup: ~10ms
Agents start at Tier 1 and graduate to lower-security tiers through demonstrated reliability. Graduation is automatic based on behavioral metrics but revocable instantly by any entity with sufficient UCAN authority.
Part 2: The Mesh Node (create-mesh-node)
2.1 What It Is
npx create-mesh-node scaffolds an organization's AI operating system on mesh primitives from day one. It generalizes the system built for Search Fund Ventures into a reusable framework with domain-specific templates.
The core principle: every capability is discoverable via API, any entity that joins the org hits one endpoint and knows what the system can do, and the system describes itself.
2.2 Architecture
┌──────────────────────────────────────────────────────────────────┐
│ MESH NODE INSTANCE │
│ │
│ ┌──────────────────────┐ ┌──────────────────────────────────┐ │
│ │ DISCOVERY LAYER │ │ KNOWLEDGE LAYER │ │
│ │ │ │ │ │
│ │ mesh-manifest.json │ │ Vector KB (embeddings) │ │
│ │ (unified discovery │ │ SOP Database │ │
│ │ for all entities) │ │ Ingested Content (institutional │ │
│ │ │ │ memory) │ │
│ │ Agent Cards (A2A) │ │ │ │
│ │ MCP Server Registry │ │ pgvector on Postgres │ │
│ └──────────────────────┘ └──────────────────────────────────┘ │
│ │
│ ┌──────────────────────┐ ┌──────────────────────────────────┐ │
│ │ AGENT LAYER │ │ WORKFLOW LAYER │ │
│ │ │ │ │ │
│ │ Framework-agnostic: │ │ Content pipeline: │ │
│ │ ├── OpenClaw │ │ idea → campaign → draft → │ │
│ │ ├── Claude Code │ │ review → approved → published │ │
│ │ ├── CrewAI │ │ │ │
│ │ ├── LangGraph │ │ Deal pipeline: │ │
│ │ └── Custom │ │ source → enrich → intake → │ │
│ │ │ │ underwrite → memo → decision │ │
│ │ Self-bootstrapping: │ │ │ │
│ │ ONBOARDING.md → │ │ SOP execution: │ │
│ │ auto-detect → │ │ schedule → assign → execute → │ │
│ │ config → operational│ │ report │ │
│ └──────────────────────┘ └──────────────────────────────────┘ │
│ │
│ ┌──────────────────────┐ ┌──────────────────────────────────┐ │
│ │ INTEGRATION LAYER │ │ GOVERNANCE LAYER │ │
│ │ │ │ │ │
│ │ Slack (channels) │ │ Org chart (role hierarchy) │ │
│ │ Email │ │ Compliance workflow │ │
│ │ Calendar │ │ Brand voice engine │ │
│ │ CRM (deal sources) │ │ Human-in-the-loop checkpoints │ │
│ │ Custom MCP servers │ │ Audit trail │ │
│ └──────────────────────┘ └──────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────┐│
│ │ MESH PROTOCOL LAYER (runs as micro-mesh) ││
│ │ ││
│ │ DID identity │ UCAN permissions │ Raft consensus ││
│ │ CRDTs (Yjs) │ ECS world state │ MCP + A2A ││
│ │ Federation │ Discovery │ Sandboxing ││
│ └──────────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────┘
2.3 What the Framework Provides vs. What Users Build
Framework Provides (Out of the Box)
| Component | Description | Based On |
|---|---|---|
| Mesh integration | Auto-configures as a micro-mesh with DID, UCAN, MCP, A2A | Mesh protocol |
| Knowledge base management | Three-KB architecture (embeddings, SOPs, ingested content) with pgvector | SFV system pattern |
| Discovery endpoint | mesh-manifest.json + agent-card.json + internal capabilities API | SFV GET /api/capabilities |
| Self-bootstrapping | ONBOARDING.md + auto-detect + config generation | SFV pnpm onboard --auto |
| Org chart | Role hierarchy with UCAN-mapped permissions | SFV org chart database |
| Queue system | Background workers (re-embedding, tagging, SOP execution, sync) | SFV nightly cron |
| Ingestion engine | Pluggable ingestors (YouTube, meetings, RSS, manual) | SFV ingestion framework |
| Compliance workflow | Human-in-the-loop approval with configurable gates | SFV compliance (Sean's approval) |
| Brand voice engine | Runtime voice profile queries for consistent agent output | SFV brand voice system |
Users Build (Organization-Specific)
| Component | Description | Example (SFV) |
|---|---|---|
| Custom workflows | Domain-specific multi-stage pipelines | Deal pipeline, content production |
| Custom MCP servers | Organization-specific tools exposed to agents | Underwriting tools, deal sourcing |
| Custom integrations | Service connections specific to the business | Clay, Apollo, LeadMagic, Fireflies |
| Knowledge content | The actual documents, SOPs, and data | SEC filings, podcast transcripts, research reports |
| Org chart data | The actual people, roles, and reporting lines | 4 divisions, role assignments |
| Programmatic pages | SEO/content pages specific to the business | /compare/*, /for/*, /learn/* |
2.4 The Config-First Pattern
The framework follows the same principle as the SFV system: mesh-node.config.yml is the local source of truth. The entire system is describable in a single configuration:
# mesh-node.config.yml
mesh:
id: "did:mesh:sfv-production"
name: "Search Fund Ventures"
root_authority: "did:mesh:nick-bryant"
knowledge:
embeddings:
model: "nomic-embed-text"
sources:
- type: "directory"
path: "./knowledge/research"
- type: "directory"
path: "./knowledge/sec-filings"
sops:
owner_field: "org_chart_role"
schedule_field: "execution_schedule"
ingestion:
youtube:
channel_id: "UC..."
schedule: "daily"
meetings:
provider: "fireflies"
api_key_env: "FIREFLIES_API_KEY"
rss:
feeds:
- url: "https://..."
schedule: "hourly"
agents:
framework: "openclaw" # or "crewai", "langgraph", "claude-code", "custom"
bootstrap:
onboarding_file: "./ONBOARDING.md"
auto_detect: true
instances:
- id: "deal-sourcer"
role: "BDR"
tier: 3
tools:
- "mcp://local/deal-pipeline"
- "mcp://local/knowledge-base"
- id: "content-writer"
role: "Content"
tier: 3
tools:
- "mcp://local/content"
- "mcp://local/knowledge-base"
- "mcp://local/brand-voice"
workflows:
content_pipeline:
stages: ["idea", "campaign", "draft", "review", "approved", "published"]
gates:
review_to_approved:
approver_role: "Head of Compliance"
type: "human_required"
deal_pipeline:
stages: ["sourced", "enriched", "intake", "underwriting", "memo", "decision"]
gates:
memo_to_decision:
approver_role: "Managing Partner"
type: "human_required"
integrations:
slack:
auto_join: true
response_mode: "contextual"
brand_voice:
profiles:
- name: "x-posts"
file: "./voice/x-profile.json"
- name: "linkedin"
file: "./voice/linkedin-profile.json"
- name: "investor-memos"
file: "./voice/memo-profile.json"
federation:
peers:
- "did:mesh:greg-agency"
- "did:mesh:portco-alpha"
cross_mesh_policy:
requires_human: true
allowed_operations: ["deal-query", "kpi-report"]
infrastructure:
database: "supabase"
hosting: "vercel"
compute_budget: "$250/mo"
One file describes the entire system. Any agent reads this config, hits the mesh manifest, and self-configures. This is the core value proposition: declarative AI operations.
Part 3: The Creation Pipeline (singularity-engine)
3.1 What It Is
The singularity-engine package is an autonomous application generation pipeline: natural language input → working deployed software → live URL. It lives within the Mesh monorepo and can operate either standalone or mesh-aware. It demonstrates autonomous creation at near-zero marginal cost — roughly 60 seconds per build at ~$0.10.
3.2 Current Architecture (v0.1 — Standalone)
┌───────────┐ ┌──────────────┐ ┌──────────────┐ ┌───────────┐
│ Trigger │────►│ Generation │────►│ Deployment │────►│ Delivery │
│ │ │ │ │ │ │ │
│ Tweet / │ │ Claude API │ │ GitHub │ │ Reply │
│ API call │ │ Code gen │ │ Pages │ │ with │
│ Natural │ │ HTML/CSS/JS │ │ Static │ │ live URL │
│ language │ │ ~60 seconds │ │ hosting │ │ │
└───────────┘ └──────────────┘ └──────────────┘ └───────────┘
Infrastructure: AWS Lambda, DynamoDB, GitHub Pages
Cost: ~$0.10 per generation
License: MIT
Current scope: Turns tweets/prompts into deployed single-page web applications. Working but rough — actively being debugged for launch.
3.3 Mesh-Aware Architecture (Target)
When singularity-engine operates within a mesh node, it gains context assembly (querying mesh knowledge bases via MCP for domain context before generating), identity verification (validating the requestor's DID and UCAN permissions), and governance (all outputs become mesh entities subject to the same permission tiers and audit trails as any other agent action). It can deploy to two targets: static hosting (GitHub Pages, external preview) and the mesh environment itself (internal, live-data connected).
Permission Tiers for Code Generation
| Tier | What They Can Generate | Review Requirement |
|---|---|---|
| Tier 1 (Mesh Creator) | Anything within own mesh: entities, agents, topology changes, MCP servers | Self-authorized (but logged) |
| Tier 2 (Super Agent) | Mesh elements within delegated scope, agent configurations, content | Tier 1 review for structural changes |
| Tier 3 (Elevated) | Personal agent configs, draft content, prototype apps | Tier 2 review before deployment |
| Tier 4 (Normal) | Request generation via A2A task | All output requires higher-tier review |
Part 4: Package Composition and Build Phases
How the Packages Compose
┌──────────────────────────────────────────────────────────────────────────┐
│ REAL-WORLD SCENARIO │
│ │
│ Nick tweets: "Build me a deal pipeline dashboard for HVAC companies │
│ in the Southeast" │
│ │
│ 1. singularity-engine receives the trigger │
│ │
│ 2. It queries the SFV mesh node via MCP: │
│ - Knowledge base: "What do we know about HVAC deal criteria?" │
│ - Deal pipeline: "What's our current deal schema?" │
│ - Brand voice: "What's our dashboard visual style?" │
│ │
│ 3. It generates a dashboard component │
│ (HTML/CSS/JS with SFV branding, connected to deal data) │
│ │
│ 4. It deploys to two targets: │
│ a. GitHub Pages (external, static preview) │
│ b. SFV mesh node (internal, live-data connected) │
│ │
│ 5. Governance: │
│ - Nick (Tier 1) authorized the generation via his tweet │
│ - The dashboard component inherits Tier 3 permissions │
│ (can read deal data, cannot modify) │
│ - UCAN proof chain: Nick → singularity-engine → dashboard │
│ - Audit trail logged to mesh state │
│ │
│ 6. singularity-engine replies to Nick's tweet with the live URL │
│ │
│ 7. Greg's mesh discovers the new dashboard via federation │
│ and can request a similar one via A2A task delegation │
│ (requires human-signed cross-mesh UCAN) │
└──────────────────────────────────────────────────────────────────────────┘
Dependency Graph
mesh-core (no dependencies — this ships first)
│
├── mesh-state (depends on mesh-core for identity layer)
│
├── mesh-federation (depends on mesh-core + mesh-state)
│
├── mesh-spatial (depends on mesh-core + mesh-state; Phase 3)
│
├── create-mesh-node (depends on mesh-core + mesh-state;
│ optionally mesh-federation)
│ │
│ └── templates/ (depend on create-mesh-node framework)
│
└── singularity-engine (standalone, or depends on mesh-core for context)
Critical path: mesh-core is the foundation. Everything else builds on it. But singularity-engine can ship v0.1 independently (as it already exists), and create-mesh-node can scaffold standalone nodes before federation is complete.
Build Phases
Phase 1: The Node (Weeks 1–4) — Serves Use Cases 1 & 2
Ship create-mesh-node with mesh-core and mesh-state.
| What Ships | What It Enables |
|---|---|
npx create-mesh-node CLI | Scaffolds micro-mesh: Supabase + Next.js + MCP servers + DID identity |
| mesh-manifest.json discovery | Self-describing system — any entity reads one endpoint and knows everything |
| Knowledge base management | Three-KB architecture (embeddings, SOPs, ingested content) |
| UCAN permission chains | Replaces implicit "trust the operator" security with cryptographic scoping |
| Templates: pe-fund, solo-dev, small-team | Domain-specific out-of-the-box configurations |
| singularity-engine v0.1 standalone | Tweet → deployed app pipeline (independent of mesh) |
This is a compelling standalone product. An AI operating system framework that the SFV article proved works — but built on mesh primitives from day one. When federation arrives, these nodes are ready.
Phase 2: Federation (Weeks 5–12) — Serves Use Cases 3 & 4
Ship mesh-federation.
| What Ships | What It Enables |
|---|---|
| libp2p peer discovery | Nodes find each other without a central registry |
| A2A Agent Card publishing | Nodes advertise capabilities to the network |
| Cross-mesh UCAN validation | Foreign agents prove authorization cryptographically |
| Yjs CRDTs cross-mesh | Shared state between nodes without a shared database |
| Human-signed capability tokens | Consequential cross-mesh actions require human authorization |
| singularity-engine mesh-aware mode | Code generation with mesh context (knowledge base queries, brand voice) |
This is where The Mesh becomes a network. Two nodes can discover each other, delegate tasks, share state, and verify identity — all without a central server.
Phase 3: Spatial Layer (Weeks 13–24) — Serves Use Case 5 and Advanced Scenarios
Ship mesh-spatial.
| What Ships | What It Enables |
|---|---|
| ECS world state | Data-oriented architecture decoupled from rendering |
| Multi-view rendering | Terminal, chat/MUD, 2D strategic, 3D WebGPU, VR WebXR |
| Agent cognitive architecture | Smallville-adapted: perceive, remember, reflect, plan, act |
| singularity-engine mesh deployment | Generated applications deploy as mesh entities |
This is the differentiator — but not the MVP. The spatial layer is what makes The Mesh visually distinctive and architecturally unique. But it ships after the foundation is solid.
Technology Stack Summary
| Layer | Technology | Maturity | Risk |
|---|---|---|---|
| State (consistent) | Raft via etcd | Production (powers all k8s) | None |
| State (real-time) | Yjs CRDTs | Production (900K weekly downloads) | None |
| Identity | W3C DIDs | Standard (120+ methods) | Low |
| Permissions | UCAN v1 | Spec complete, limited production | Medium |
| Agent-to-tool | MCP | Production (97M monthly downloads) | None |
| Agent-to-agent | A2A | RC v1.0 (150+ orgs) | Low |
| Discovery | libp2p Kademlia + GossipSub | Production (powers Ethereum) | Low (governance gap) |
| World state | ECS (bitECS or custom) | Pattern proven (Unity, Overwatch, Bevy) | Low |
| 3D rendering | WebGPU | Shipping (~70% coverage) | Low |
| Database | PostgreSQL + pgvector (Supabase) | Production | None |
| Hosting | Vercel / AWS Lambda | Production | None |
| Sandboxing | Firecracker / gVisor | Production | Low |
| Auth standard | Passkeys | Production (3B+ active) | None |
Primary technical risk: Integration complexity. Every individual component is proven. The novel engineering is making them work together as a coherent federated protocol with the specific permission model, governance structure, and multi-interface design the Mesh requires. This integration complexity is why a monorepo structure is essential — the components must evolve together. Breaking them into separate projects would introduce version compatibility issues, divergent design decisions, and coordination overhead that a small founding team cannot afford.
What's Needed
A co-founder with go-to-market, enterprise sales, or developer relations experience. The technical architecture is specified. The commercial strategy, developer community, and enterprise adoption path need a dedicated leader.
Distributed systems engineers experienced in consensus protocols, real-time networking, or security. AI can augment this work but cannot replace the deep human expertise required for correct implementations of Raft, CRDT conflict resolution, and cryptographic permission systems.
Agent framework developers who want to build MCP servers, A2A integrations, and mesh node templates. The ecosystem grows through community contributions.
Early adopters willing to run micro-meshes and stress-test federation. The architecture is designed but untested at multi-mesh scale.
The Mesh — GitHub: github.com/Metatransformer/the-mesh
Follow on X: @metatransformr
Discord: discord.gg/CYp4wJvFQF
Prepared by Nick Bryant @metatransformr × Claude Opus 4.6 | Metatransformer LLC Article 5 of 5: Technical Architecture