Introducing Pearls: Scaling Agent Memory from Local Repos to Distributed Knowledge Meshes

What if we replaced “beads” with “pearls”, by using a network-aware database that supported 3-way reconciliation without Dolt? Where would it be better?

Gemini Prompt

If you’ve been building with Beads (bd), you already know why git-native, version-controlled issue tracking was a massive step forward for AI coding agents.

Before Beads, agents relied on ephemeral markdown files or flat TODO lists that melted during context compaction. Beads fixed this by bringing persistent, relational task memory directly into your repository, using Dolt to handle cell-level 3-way SQL merges so agents could work on task branches alongside feature code.

Beads was designed for the local developer loop: one developer (or a few agent instances) working inside a single Git repository.

But what happens when you scale beyond a single repo? What happens when your architecture evolves from a local coding assistant into a cloud-native swarm of autonomous micro-agents?

Enter Pearls (pl).

What is Pearls?

Pearls: A distributed knowledge graph for multi-agent swarms, powered by version-controlled 3-way reconciliation.

Where Beads strings together flat SQL task records along a local wire, Pearls layers rich, interconnected semantic graph structures around a shared, version-controlled core.

Instead of sitting on top of Dolt’s SQL engine, Pearls is built on TerminusDB–a revision-controlled document graph database built in Rust. It takes the Git-for-Data paradigm you love in Beads and elevates it from flat relational tables to a native JSON-LD knowledge mesh.

The Paradigm Shift

Beads (bd)

  • Focus: Local-first CLI tool for single-repo contexts.
  • Engine: Dolt (Relational SQL).
  • Data Model: Flat SQL rows and foreign key junction tables.
  • Topology: Embedded local binary bound to the Git repository lifecycle.

Pearls (pl)

  • Focus: Cloud-native multi-agent swarm orchestration across distributed meshes.
  • Engine: TerminusDB (Document Graph / JSON-LD).
  • Data Model: Succinct bit-compressed RDF triples and JSON-LD document trees.
  • Topology: Networked service mesh nodes running in sidecars, containers, or cloud clusters.

Why Build Pearls?

We didn’t set out to replace Beads; we built Pearls because multi-agent systems hit a structural ceiling when forced into relational SQL engines running on local disk.

1. From Relational Tables to Native Graph Dependencies

In Beads, modeling complex tasks requires mapping directed graphs over SQL tables using foreign keys and junction tables.

In Pearls, tasks, reasoning traces, tool outputs, and dependency trees are native JSON-LD knowledge nodes. Agents can query deep, multi-hop relationships (“Find all open tasks blocking X down 5 levels, along with the reasoning logs of the agents assigned to them”) instantly using native GraphQL or WOQL queries without constructing recursive SQL CTEs:

query { Task(id: "pearl-a1b2") { title status blocked_by { title assignee reasoning_trace { context_blob } } } }

2. Built for Cloud-Native Agent Swarms

Beads shines as an embedded, zero-ops binary inside a developer’s terminal. But cloud-hosted agent swarms operating as asynchronous microservices need a networked service layer.

Pearls operates as a networked document service running in sidecars, containers, or Kubernetes clusters. Agents interact with pl instances over high-speed HTTP/REST or GraphQL APIs, enabling continuous, daemonized background execution.

3. Git-Style Delta Synchronizations Across Agent Nodes

TerminusDB handles multi-node collaboration using an asynchronous Git remote model (clone, push, pull, fetch) over HTTP.

When an agent in a swarm forks a reasoning path to explore a feature, it creates a local branch on its node. Once validated, it executes a push, triggering TerminusDB’s 3-way delta reconciliation engine. The receiving node computes structural graph diffs down to individual RDF triples/JSON-LD fields, automatically merging non-conflicting edits and flagging true graph collisions.

The pl Developer Experience

We kept the CLI ergonomics close to bd. The new pl command gives agents and developers the exact same speed and familiarity:

# Initialize a new TerminusDB Pearl graph node

pl init

# Check graph state and ready work pl status

# Branch a task graph for a sub-agent to explore a hypothesis

pl checkout -b reasoning/agent-beta-branch

# Commit new graph nodes (tasks, context, tool outputs)

pl commit -m "Attached sandbox execution traces to task-104"

# Fetch and 3-way merge remote agent branches across the mesh

pl pull origin main pl merge reasoning/agent-beta-branch

Feature Comparison

  • Primary Focus
    • Beads (bd): Local coding agents and Git repo issue tracking.
    • Pearls (pl): Cloud-native multi-agent swarm orchestration.
  • Underlying Storage Engine
  • Data Representation
    • Beads (bd): Flat SQL rows with foreign key links.
    • Pearls (pl): Succinct, bit-compressed RDF triples and JSON-LD trees.
  • 3-Way Merge Mechanism
    • Beads (bd): Cell-level SQL row merges via Prolly Trees.
    • Pearls (pl): Delta-layer graph triple merges.
  • Runtime Architecture
    • Beads (bd): Embedded local CLI executable.
    • Pearls (pl): Federated HTTP nodes / Service mesh architecture.
  • Interfaces
    • Beads (bd): CLI and SQL queries.
    • Pearls (pl): CLI, GraphQL, WOQL, and REST APIs.

When to Use Which?

  • Use Beads (bd) if: You are building software locally with AI coding assistants (like Claude Code, Cursor, or Windsurf), and you want a zero-dependency, zero-ops issue tracker embedded directly inside your Git repository.
  • Use Pearls (pl) if: You are orchestrating distributed, multi-agent swarms running across cloud infrastructure where agents need to share, branch, and 3-way merge complex semantic knowledge graphs in real time.

Beads gave our agents persistent memory inside our repos. Pearls gives them a distributed nervous system.

Leave a comment

Blog at WordPress.com.

Up ↑