Use Engram with Tightbeam

On Gibson

Use the installed engram-tightbeam command. It selects the existing shared index regardless of your current repository. Engram v0.2.5 includes the pasted-code parsing fix. There is no need to initialize another store.

# Find conversations associated with a file or code span.
engram-tightbeam explain /path/to/repo/src/example.rs:40-78
engram-tightbeam explain /path/to/repo/src/example.rs

# Search conversation text, including text excluded from code fingerprints.
engram-tightbeam grep 'literal search term'

# Read the tape returned in a query response.
engram-tightbeam peek TAPE_ID --start 1 --lines 40

# Move through result pages. Each page contains at most 25 sessions.
engram-tightbeam grep 'literal search term' --limit 25 --offset 25

Use an absolute path for a file query. For pasted code that begins with a hyphen, put options before -- and the code after it. Fingerprint matches identify related code evidence; use peek to read the reasoning before drawing conclusions.

Collection and host coverage

Tightbeam shares homes by host and harness. Several archetypes use each home, so collect each actual transcript root once. Do not create an index per archetype.

~/.tightbeam/homes/gibson/codex/sessions/**/*.jsonl
~/.tightbeam/homes/gibson/claude/projects/**/*.jsonl

External sessions use ~/.codex/sessions and ~/.claude/projects. These also need collection when they delegate to Tightbeam. Claude subagent transcripts under projects are included. Scope collection to transcript directories; authentication files and other files under harness homes are not inputs.

The host rows distinguish setup still in progress from verified service operation. They do not claim that a historical backfill has finished merely because a watcher is running.

Gibson's collector runs as the user service engram-gibson-coverage.service. It stages complete transcript records, feeds Engram, and catches up after restart. Check it with systemctl --user status engram-gibson-coverage.service. Racter and Osanwe use engram-approved-transcripts.service; Eezo uses LaunchAgent ai.engram.approved-transcripts-v025. On those three hosts, the isolated store and collector live under ~/.local/share/engram/coverage-v0.2.5 and the launcher is ~/.local/bin/engram-tightbeam. Do not launch a second watcher for each agent or task. Keep originals intact.

Delegating from Codex or Claude to Tightbeam

Generate a fresh UUIDv4 for each distinct handoff. Put the marker at the start of the actual task brief. Engram needs the same tag in the sender's recorded tool-call arguments and the recipient's delivered prompt.

python3 -c 'import uuid; print(uuid.uuid4())'

Copy the generated UUID into the subsequent tool call. The placeholder below is intentionally not a real marker to reuse.

tightbeam dispatch --to 'EXACT_SESSION_KEY' \
  --work-item WORK_ITEM_ID \
  --subject 'The intended outcome' \
  --brief '<engram-src id="REPLACE_WITH_FRESH_UUID"/> The task and acceptance criteria.' \
  --as-user mike

Use wake --prompt with a marker when a wake is the appropriate operation for an existing obligation or a question. A marker is part of the task, not a reason to send an extra notification. Keep work items, assignments and the existing Tightbeam workflow.

A newly generated outgoing marker must first appear inside the tool call that sends the task. Do not announce it as plain assistant text first. Engram classifies a marker on the message surface as received, regardless of the speaker. A marker hidden only in a temporary brief file does not provide sender evidence: the sending tool call must also contain its literal value.

Retrying the same delivery reuses its marker and idempotency key. A different handoff gets a new UUID. Never reuse a sample UUID or invent historical links.

Delegating inside the org

Use the same convention for PO to PDO, PDO to worker, worker to specialist, or any other actual delegation. Each hop gets its own outgoing marker. Keep incoming context intact, but do not recycle the incoming UUID for the next hop. This lets Engram walk from the code change through successive delegations to the originating conversation.

Local Codex and Claude guidance is updated on all four machines. The org-local operating manual is now updated through served identity; existing-session refresh is in progress. Shipped Tightbeam guidance is unchanged.

Markers record provenance. They do not grant permission or replace Tightbeam's agent identities and durable work records. Newly loaded guidance applies to new turns or sessions according to harness behavior; editing a file does not prove a currently running turn has read it.

Cross-host queries

Gibson's normal engram-tightbeam launcher now queries verified Racter and Osanwe snapshots captured at 9:32 AM PT on September 21. Tests returned edits found only on those hosts and matched their transcript evidence. Snapshots refresh manually; local collectors run continuously. Eezo will join after its initial backfill. Cross-host delegation traversal still needs the marker repair above.

Engram supports read-only additional_stores. Use a consistent SQLite snapshot and its associated immutable tapes, with recorded freshness. Do not point a query at a live SQLite database through the shared rclone mount. Do not infer that an unreachable host has no evidence.

What has been tested

Before this expansion, the Gibson audit checked 7,586 normalized tapes, 2.23 million events, all 37,288 code windows, edit links and deletion windows. One hundred original-source specimens covered Codex and Claude reads and edits. Conversation search, pagination, date filters and deleted-code retrieval were checked.

The audit found a pasted-code parser defect. All 102 affected cases passed after v0.2.5 was installed, on both the fixed audit snapshot and the live launcher. The current rollout requires separate host and delegation-link verification; those earlier results are not a claim about untested hosts.

Collection does not prove every arbitrary shell command can be normalized into code evidence. Old malformed records remain a disclosed coverage limit. Agent names, archetypes and stable Tightbeam identities still require a metadata mapping; home directories and markers alone do not provide those labels.