Back to Notes

The Lattice: How Multi-Agent Systems Compound Intelligence

Most AI deployments are single-agent: one model, one task, one conversation. What I'm building is different — a network of specialized agents that share memory, produce signals for each other, and compound in value the longer they run.


The Ceiling on Single Agents

There's a ceiling you hit fast with single-agent systems. One agent trying to handle operations, content, marketing, and fulfillment produces mediocre results across all of them. You can't optimize a general-purpose agent the way you can optimize a specialist. And you can't control cost when one agent is doing everything.

The solution isn't a smarter model. It's a smarter architecture.

The analogy I keep coming back to: a single brilliant person can run a small company. But a company that scales has departments — each staffed with people who are genuinely expert in their domain, and connected by shared systems that let their work build on each other. The coordination layer is what makes the whole greater than the sum of the parts.

That's what I'm building with agents. Not one brilliant generalist. A network of deep specialists with a shared coordination layer.

The Architecture

Nine agents across three servers. Each has a single domain. No agent does what another does.

┌─────────────────────────┐ │ THE DIRECTOR │ │ Private. Orchestrates. │ │ One operator. One line. │ └────────────┬────────────┘ │ ┌────────────────────────┼───────────────────────┐ │ │ ┌──────────▼──────────┐ ┌─────────────▼──────────┐ │ OPERATIONS LAYER │ │ CREATIVE LAYER │ │ │ │ │ │ Sentinel │ │ The Scribe │ │ supply & intel │ │ content OS │ │ │ │ │ │ Pipeline │ │ Creative │ │ revenue ops │ │ ad intelligence │ │ │ │ │ │ Performance │ │ Voice │ │ marketing data │ │ social content │ │ │ │ │ │ Logistics │ │ Reach │ │ fulfillment │ │ influencer intel │ └─────────────────────┘ └────────────────────────┘ │ │ └────────────────────┬────────────────────────────┘ │ ┌────────▼────────┐ │ SHARED BRAIN │ │ bot_signals │ └────────┬────────┘ │ ┌────────▼────────┐ │ WATCHDOG │ │ fleet monitor │ └─────────────────┘

The key design principle: no agent talks directly to another agent. They communicate through data. Each agent writes its key outputs to a shared database. Each agent queries that database before it works. The coordination is asynchronous, persistent, and doesn't require any agent to know the others exist.

The Shared Brain

Everything runs through a single table: bot_signals.

CREATE TABLE bot_signals ( id UUID PRIMARY KEY, agent TEXT NOT NULL, -- who wrote it signal_type TEXT NOT NULL, -- what kind of signal vertical TEXT, -- which product / audience content JSONB NOT NULL, -- the actual payload week INT, -- ISO week number created_at TIMESTAMPTZ DEFAULT NOW() );

Every agent has a defined set of signal types it produces, and a defined set of signal types it consumes. The schema is the contract. Nothing is hardcoded between agents — they're decoupled at the data layer.

Agent Writes Reads
Sentinel competitor_move, vendor_alert fleet_health
Pipeline top_objection, pipeline_health fleet_health
Performance top_creative, fatigue_alert fleet_health
Scribe keyword_gap, content_draft, vertical_intel competitor_move, top_objection, top_creative, winning_hook
Creative winning_hook, creative_brief content_draft, top_creative, top_objection
Voice social_draft content_draft, vertical_intel, winning_hook
Reach influencer_match, collab_brief competitor_move, content_draft, vertical_intel
Watchdog fleet_health, cost_alert all

The Flywheel

The reason this architecture is worth the complexity: one signal becomes many outputs, automatically, with no coordination overhead.

SIGNAL ──► SYNTHESIS ──► CONTENT ──► DISTRIBUTION ▲ │ │ │ └─────────── PERFORMANCE DATA ◄─────────┘ Example: one competitor signal becomes six outputs Sentinel detects competitor price drop [competitor_move] │ ├──► Scribe drafts comparison article [content_draft] │ │ │ ├──► Voice: 3 platform-native social posts │ └──► Reach: influencer brief — "why we win at this price" │ ├──► Creative: adjusts hooks for value positioning [winning_hook] │ │ │ └──► Performance: shifts budget toward value campaigns │ └──► Pipeline: updates objection handling for sales team 6 outputs. 1 signal. 0 human coordination required.

The test I use: does agent A produce something that makes agent B more useful, without agent A knowing agent B exists? If yes, the lattice is live.

The Content OS — A Closer Look at the Scribe

The Scribe is the most layered agent in the system. It's easy to think of a content agent as an SEO tool that writes blog posts. That's not what this is.

Every word that goes anywhere — product pages, marketplace listings, blog, B2B materials, partner content packages — starts with the Scribe. It's the content operating system, not a content producer.

Before the Scribe generates anything, it reads:

BEFORE generating any content: 1. Approved copy library ← never start from scratch 2. Which vertical / ICP ← every piece is audience-specific 3. Sentinel signals this week ← what's happening competitively? 4. Pipeline signals this week ← what objections are real buyers raising? 5. Performance signals this week ← what messaging is proven in ads? 6. Keyword gap data ← what search intent are we missing? THEN generate.

The hierarchy matters. The Scribe extends and optimizes approved copy. It doesn't replace brand voice. It starts from what's already approved and makes it better for each surface and each audience.

ICP-First Content

One of the failure modes I see constantly in content strategy: generic content optimized for no one in particular. It ranks for nothing. It converts no one. It compounds into a library of mediocre pages that look like content but function like noise.

Every piece the Scribe produces is tagged to a vertical and an ICP. The draft starts with: who specifically is this for, what do they believe before they read this, what do I need them to believe after?

VERTICAL STRUCTURE ├── Professional / All-Day │ ICP: Office worker, values productivity + style, hybrid schedule │ Tension: wants smart tech, doesn't want to look like a tech nerd │ Frame: "Invisible upgrade to your day" ├── Smart Tech / AI Enthusiast │ ICP: Early adopter, follows AI news, wants the frontier device │ Tension: wants best AI glasses but most look like a prototype │ Frame: "AI that doesn't announce itself" ├── Safety / Field Work │ ICP: Construction manager, safety compliance buyer, B2B │ Tension: needs certified protection AND communication on-site │ Frame: "Certified protection. Hands-free communication." ├── Sport / Active │ ICP: Runner, cyclist, outdoor fitness, performance-focused │ Tension: earbuds fall out, phone in hand breaks flow state │ Frame: "Audio built into your sport. Not clipped onto it." └── Licensed Brand / Optical ICP: Brand-loyal customer, fashion-conscious, needs prescription Tension: loves the brand, didn't know smart glasses existed Frame: "The brand you know. Smart audio built in."

Fleet Memory — The Sync Problem

Nine agents across three servers. Each has a SOUL.md (identity, philosophy, mental models), a MEMORY.md (what it knows, what it's tracking), and a HEARTBEAT.md (what it does on its own clock). Keeping these consistent is a coordination problem.

My solution: the Director runs a weekly fleet-sync. It's a cron job that pulls the latest agent files from a Git repo and deploys them across all servers. SOUL.md and shared awareness files are pushed to every agent. MEMORY.md and HEARTBEAT.md stay agent-specific and aren't overwritten.

GitHub repo (fleet source of truth) │ ▼ (every Sunday 6 AM) Director runs fleet-sync: │ ├── git pull ├── for each agent: │ ├── deploy SOUL.md │ ├── deploy FLEET-AWARENESS.md │ └── deploy AGENTS.md │ (skip MEMORY.md + HEARTBEAT.md — agent-specific) └── report: "Fleet sync complete. N files updated."

Every agent also gets a FLEET-AWARENESS.md — a file that tells it what every other agent produces and where to find it. Agents don't need to know each other to use each other's work. They just need to know where to look.

The Philosophy Underneath

A few mental models running under the surface of this architecture:

Munger's latticework. No single mental model is enough. The agents need to think across domains — that's why they share signals, not just data. The Scribe reads operations signals. The Creative reads sales signals. Cross-domain pattern recognition is where the real insight lives.

Goldratt's constraint. The system produces at the rate of its weakest signal. If Sentinel stops posting competitor moves, the Scribe drafts generic content. The chain matters as much as any individual agent.

Compounding. Content written today generates traffic for years. Signals produced today train better outputs next month. Every week the system runs, it gets harder to replicate. The moat isn't the agents — it's the network and the data it accumulates.

That's the bet. Not on any single agent being brilliant. On a system that gets smarter the longer it runs, without requiring more human coordination to do it.


This is a working note, not a finished system. The lattice is being built one session at a time.