Hive Mind

Three agents. One shared brain. No agent left behind.

Comment

Inspiration

We kept running into the same wall when building multi-agent systems: agents are brilliant amnesiacs. Agent A discovers that the auth service crashes when REFRESH_TOKEN_TTL is unset. Ten minutes later, Agent B deploys the same service — and has absolutely no idea. Every restart wipes the slate clean. Agents working in silos don't compound knowledge; they repeat mistakes.

We asked a question that felt almost too simple: what if agents shared a brain? Not message passing. Not function arguments. A real, persistent, queryable knowledge base that every agent reads from and writes to — one that survives across runs, across restarts, across time. When one agent learns, all agents learn. That's the hive mind.

The CockroachDB × AWS Hackathon gave us the perfect constraint: build with agentic memory. CockroachDB's distributed vector indexing, MCP server, and agent skills gave us the infrastructure for shared persistent memory. AWS Bedrock gave us the reasoning engine. The combination wasn't just convenient — it was the architecture we'd been wanting to build.

What it does

HiveMind is a multi-agent system where three specialized AI agents — Coder, Reviewer, and Deployer — share a persistent collective memory in CockroachDB. Every agent reads from and writes to the same memory store, creating emergent intelligence that no single agent possesses alone.

The Pipeline:

  1. Coder receives a task, searches shared memory for relevant context (past findings, reviewer feedback, injected issues), calls Claude 3.5 Sonnet via Bedrock, and writes its findings to memory.
  2. Reviewer reads the Coder's output from shared memory (not passed as an argument), searches for past review patterns, and writes critiques or approvals. If issues are found, Coder re-fixes — up to 2 review loops.
  3. Deployer reads approved code plus past deployment history from shared memory, and writes a deployment plan with steps, env vars, and rollback strategy.

Beyond the Pipeline:

  • Semantic Memory Search — Agents and users search memories by meaning using CockroachDB's distributed vector indexing (pgvector). "Has anyone seen an auth error like this?" finds relevant memories regardless of when they were written.
  • Human Issue Injection — Inject a production incident ("connection pool exhausted, 503 on /api/v2/login") into shared memory. On the next pipeline run, Coder automatically discovers it via vector search and generates a fix.
  • Memory Lineage — Every memory traces its origin. A fix was triggered by a critique, which was triggered by a finding, which was triggered by an injected issue. The full reasoning chain is auditable.
  • Memory Diff — See what the hive learned in the last 5 minutes: 12 new memories, 5 by Coder, 4 by Reviewer, 3 by Deployer. The hive is actively growing.
  • Real-Time Pipeline Visualization — Watch each agent's status cycle: reading memory → thinking → writing memory → done. Memories appear in the feed as they're written.

How we built it

Database Layer — CockroachDB Cloud: All persistent state lives in CockroachDB. We enabled the vector extension for pgvector support and designed 6 tables: agents (the three specialized agents), runs (pipeline executions), run_steps (individual agent executions within a run), memories (the shared brain — with VECTOR(1536) embeddings, JSONB metadata, and parent lineage pointers), and memory_reads (audit trail of who read what). We built an IVFFlat vector index on the embeddings column for semantic similarity search. Every memory write generates an embedding via Bedrock Titan; every agent read logs to memory_reads for full traceability.

Agent Execution — AWS Bedrock: Each agent follows a strict read → think → write protocol. On execution, the agent: (1) embeds its task context via Titan Embeddings V2, (2) runs vector similarity search against the memories table (cosine similarity > 0.7, top-K=5), (3) fetches recent memories from other agents, (4) builds a prompt with system instructions + task + memory context, (5) calls Claude 3.5 Sonnet via Bedrock InvokeModel, (6) parses structured output, (7) writes 1-3 new memories with embeddings, lineage pointers, and JSONB metadata. All reads are logged to memory_reads.

Pipeline Orchestration — Next.js Server: The pipeline manager creates a run record, then executes agents sequentially: Coder → Reviewer (with max 2 review loops) → Deployer. Each step's status is tracked in run_steps with timestamps and durations. The UI polls every 2 seconds during active runs for real-time status updates.

CockroachDB Tools Used (3 of 4):

  • MCP Server — Agents connect to CRDB via the managed MCP server for auditable memory read/write operations.
  • Distributed Vector Indexing — Powers all semantic memory search for both agents (automatic) and users (manual search bar).
  • Agent Skills — Agents reference skills for schema introspection, query optimization, and operational awareness of their own memory store.

AWS Services Used (2):

  • Amazon Bedrock — Claude 3.5 Sonnet for all agent reasoning; Titan Text Embeddings V2 for memory vectorization.
  • AWS Lambda — Serverless functions for agent execution, memory embedding on write, and pipeline orchestration triggers.

Frontend — Next.js 16 + Shadcn UI: Dashboard with sidebar navigation, agent status cards with real-time state, memory browser with semantic search and filters, memory detail pages with lineage timelines and read trails, pipeline page with execution visualization, and a YC-style landing page. Authentication via Clerk with a pre-seeded demo account ([email protected] / hivemind2025).

Challenges we ran into

Bedrock latency in live demos. Agent execution involves multiple sequential Bedrock calls — embed query, vector search, call Claude, embed output, write memory. Each step adds 1-3 seconds. A full pipeline run with review loops could take 20-30 seconds of dead air in a demo. We mitigated this by keeping agent prompts tight, showing real-time status transitions (reading → thinking → writing → done) so the UI never feels frozen, and pre-seeding historical runs so the memory browser is populated even before a live run completes.

Making it feel like more than "3 chatbots sharing a DB." This was the existential risk. If the demo just looks like three LLM calls writing to the same table, we've failed. We invested heavily in making memory reads and writes explicit in the UI — showing the exact moment Reviewer reads Coder's finding from memory, showing lineage chains, showing similarity scores on semantic search results, showing the memory diff counter ticking up. The memory is the product, not a side effect.

Vector search relevance. Early on, our vector searches returned semantically similar but practically irrelevant memories — past deployment plans surfacing when the Coder needed coding patterns. We tuned similarity thresholds (0.7 default), added excludeRunId filtering so agents don't read their own current run's memories, and carefully structured memory content (title + content embedded together) so embeddings capture the full context, not just a vague summary.

Sequential orchestration with review loops. The Coder → Reviewer → (loop if critique) → Deployer flow seems simple but the review loop introduced tricky state management. When Reviewer writes a critique, how does Coder know to re-execute? How do we prevent infinite loops? We capped at 2 review loops, used parent_memory_id to link the fix to the critique that triggered it, and tracked review_loop_count on the run record. Each loop creates new run_steps, so the full execution history is auditable.

CockroachDB MCP Server integration. The MCP server is designed for interactive tool use, but our agents run in an automated pipeline. We had to bridge the gap — using MCP for auditable read/write operations while falling back to direct SQL (pgwire) for bulk queries and vector search. The MCP server provides the agent-safe interface; direct SQL provides the performance for complex queries like memory lineage traversal (recursive CTEs) and memory diff aggregation.

Accomplishments that we're proud of

The "read from memory" moment. This is the wow-factor. When Reviewer reads Coder's finding from the CockroachDB memories table — not from a function argument, not from a message queue, not from an in-context array — and then writes a critique that Coder picks up on the next loop... that's the hive mind working. It's not choreographed. It's emergent. And it's all powered by shared persistent memory.

Full memory lineage. We didn't just store memories — we made them traceable. Every memory has a parent_memory_id pointing to what triggered it. Our recursive CTE query traverses the full chain: injected issue → finding → critique → fix → approval → deployment plan. You can see the exact reasoning path the hive took. This isn't just a feature — it's an audit trail for agentic decision-making.

Semantic search that actually works. When a user types "auth errors like this" and finds a memory from 3 runs ago where Coder documented a JWT expiry bug — that's pgvector doing its job. We built the embedding pipeline (Titan V2 → 1536 dimensions → IVFFlat index), set up the similarity search with proper thresholds, and it returns genuinely relevant results. Not keyword matching — meaning matching.

The demo account experience. Judges can click "Launch Demo" and land directly in a working dashboard with pre-seeded agents, historical memories, and a live pipeline. Zero setup friction. Clerk handles auth, the database is pre-populated, and the pipeline is ready to trigger. We're proud that the first interaction is a real one, not a loading screen.

3 CockroachDB tools, 2 AWS services — all essential. Nothing is decorative. MCP Server is how agents read/write memory. Vector indexing is how they find relevant memories. Agent Skills is how they understand their own schema. Bedrock is how they reason. Lambda is how they execute. Remove any one piece and the system breaks. That's the definition of a well-integrated architecture.

What we learned

Shared memory changes agent architecture fundamentally. The prevailing pattern in multi-agent systems is message passing — Agent A sends output to Agent B via a structured message or queue. This works for single executions but fails over time. Agent B has no memory of what Agent A did yesterday. Shared persistent memory is a paradigm shift: agents don't communicate, they remember. The coordination is emergent, not orchestrated.

Embedding quality is the hidden infrastructure. We spent disproportionate time on how memories are embedded — what text goes into the embedding model, how titles and content are combined, what the similarity threshold should be. A bad embedding strategy makes vector search useless regardless of the index. We learned to embed title + " " + content as a single string, use 1536 dimensions for good resolution, and set the threshold at 0.7 to balance recall vs. precision.

CockroachDB is surprisingly good as a vector store. We came in expecting to use a dedicated vector database and fell back to CockroachDB's pgvector support. The IVFFlat index performs well for our scale (hundreds to low thousands of memories), the SQL interface is familiar and powerful (we can join memories with agents and runs in the same query), and the operational simplicity of one database for everything — relational data, JSONB metadata, vector embeddings — is a huge win. No syncing between systems.

Agent prompts need to be memory-aware. Simply giving an agent access to shared memory isn't enough. The system prompt needs to explicitly instruct the agent how to use memory — what to look for, how to weight past findings vs. current task, when to trust historical context vs. override it. We iterated on system prompts significantly to get agents that actually leveraged shared memory effectively rather than ignoring it.

The demo is the product. For a hackathon, the 3-minute video is the entire distribution channel. We learned to optimize ruthlessly for demo flow: pre-seed data so memory isn't empty, show the lineage chain because it's visually compelling, inject an issue live because it demonstrates the feedback loop. Every feature we built was evaluated against "does this make the demo more convincing?" If not, it was cut.

What's next for HiveMind

More agents, real monitoring. The current three-agent pipeline is a proof of concept. The real power emerges with a Monitor agent that continuously watches production logs and metrics, injecting issues into shared memory automatically — replacing our human issue injection. Add a Tester agent that reads Coder's findings and writes test cases, a Security agent that reviews for vulnerabilities, and the hive becomes a genuine autonomous software team.

Streaming memory reads. Currently agents read a fixed top-K memories before acting. We want to implement iterative retrieval — agent reads initial context, starts reasoning, discovers it needs more information, and issues additional semantic searches mid-execution. This makes the memory layer not just a pre-fetch but an interactive resource the agent queries on demand.

Cross-hive memory sharing. Multiple HiveMind instances running for different teams or projects, with a federated memory layer. Team A's Coder discovers a database connection pooling bug. Team B's Coder, working on a completely different service, encounters the same pattern — and finds Team A's finding via cross-hive semantic search. Organizational learning, not just team learning.

Memory compaction and summarization. Over time, the memories table grows. We want agents that can compact old memories — reading 50 detailed findings from the past month and writing a single summary memory that captures the key patterns. The detailed memories are archived but still searchable; the summary becomes the default context for future reads. This is how human memory works — we don't remember every detail, we remember the important patterns.

Production deployment. Right now the pipeline is sequential and triggered manually. We want event-driven triggers: a PR opens → Coder and Reviewer activate; a deployment fails → Monitor injects the issue → Coder auto-fixes; a security advisory is published → Security agent reads it and scans the codebase. The hive never sleeps.

Built With

Share this project:

Updates

Submission history