# Seeding & expanding atomic nouns and verbs with Muse / Meta agents How a Muse Code agent, MCP client, or Meta Model API worker (`muse-spark-1.3`, `muse-wonder-1.0` in Standard mode) safely **adds new atomic nouns and verbs and processes them end to end** without unbounded fan-out or unreviewed store pollution. Tessera is infrastructure; Eranos and one overview site are the only public surfaces, and everything else, agent kits included, is nouns and verbs in seed packs. For source-discovery meta-seeds and proposed daily collection, use the newer [research seed authoring tool](research-seeds.md). It creates bounded worker contracts on the same fabric. Its schedule stage creates a proposal noun; a general recurring research scheduler is not installed by either workflow. ## Why dedicated `seed` and `expand` queues + staged noun stores? If any swarm worker could recursively spawn tasks on execution queues or write directly into canonical stores (rule cards in a seed pack, or `eranos.catalog` agent kits for NGOs), two failure modes appear immediately: 1. **Runaway fan-out:** an agent splits tasks that split tasks indefinitely, burning donated or budgeted tokens. 2. **Canonical noun pollution:** a single model pass overwrites verified records without independent review. Tessera keeps the kernel (`src/tessera/`) 100% domain-neutral while organizing swarm growth into **four bounded verb stages** paired with **three compare-and-set noun stores**: ```mermaid flowchart LR S[("Noun store: seeds/*
compact topic + budget")] --> Q1["Verb queue: expand
depth < max_depth"] Q1 --> P[("Noun store: proposals/*
v1 candidate noun (CAS)")] Q1 --> Q2["Verb queues: research + draft
enrich_proposal"] Q2 --> B[("Blobs: SHA-256
SYNTHETIC fixtures")] Q2 --> P2[("Noun store: proposals/*
v2..v3 enriched (CAS)")] Q2 --> Q3["Verb queue: review
depends_on research+draft
reviewer != proposer"] Q3 --> C[("Noun store: canonical/*
atomic put_records batch")] ``` ## The three expansion noun stores | Store | Key shape | Who writes | Guarantees | |---|---|---|---| | `seeds` | `` | Operator or seed-scoped intake key (`expected_version=None`) | Holds the topic, target namespace (for example `eranos.kit`), safety rules, and explicit fan-out budget (`max_depth` ≤ 3, `max_children` ≤ 8) | | `proposals` | `prop-` | Proposer & enricher workers (`expected_version=None` then `1, 2, ...`) | Staging noun enriched across child verbs using compare-and-set so concurrent workers never clobber one another; records `proposed_by_worker` and content-addressed `blob_sha256s` | | `canonical` | `:` | Independent reviewer (`reviewer != proposed_by_worker`) | Published only through a single atomic `put_records` batch that marks `proposals/` `promoted` and creates `canonical/:` together | ## How a Muse or Meta-powered agent connects Every door shares the same hashed `tsk_*` keys (`make seed` writes scoped keys to `~/.config/tessera/keys-tessera.json`, mode `0600`): 1. **Over MCP (`/mcp`, Streamable HTTP):** - **Verb tools:** `queues`, `enqueue`, `claim`, `heartbeat`, `submit`, `split`, `park`, `resume` - **Noun tools (`store` scope):** `put_record`, `put_records`, `get_record`, `record_history` 2. **Over HTTP (`/v1/*`) or Python (`tessera.client.Client` / `tools/swarm_expander.py`):** - Calls Meta's Model API Responses endpoint (`MODEL_API_BASE`, default `https://api.meta.ai/v1`) with `muse-spark-1.3` or `muse-wonder-1.0` in **Standard mode** (`*-contributor` model ids are refused in code before any request). - Registers each background model call against the active Tessera lease (`POST /v1/jobs` / `register_job`) and records token usage on completion (`update_job`). ## Run it end to end ```bash # 1. Offline deterministic verification (no API key needed): make expand-demo # 2. Seed a local Tessera instance and run against the live HTTP service: make seed TESSERA_URL=http://127.0.0.1:7700 TESSERA_KEY= \ MODEL_API_KEY= \ uv run python tools/swarm_expander.py --worker muse-01 --queue expand ```