Resources // TERSE

Cookbook

Small, task-shaped recipes — each one a complete pattern you can lift into a prompt or a store today. All of them follow the same grammar: state in a store, read with ? queries, change by declaration. New to the syntax? Start with the cheatsheet.

R1Session memory in 20 lines

Give a chat assistant durable memory with nothing but a store and three habits: orient at start, capture as you go, recall by name. This is the terse-memory pattern, minimized.

memory.terse
# Profile
## Preferences
tone(direct; no filler)
code style(lang: python; types: strict)
## Facts
works at(company: "Northwind"; role: platform lead)
timezone(tz: "America/Los_Angeles")

# Sessions
## 2026-07-30
"Debugged the billing retry loop; root cause was a
stale cache key. Prefers fixes over workarounds."

// each session: orient first, then capture as you learn
? Profile [DEPTH 2]                  // orientation read
## Facts
allergic to(yaml anchors) [MERGED]    // capture without clobbering
Why it works: silence preserves means every capture is additive by default — the agent never rewrites the whole memory to add one fact. "Forget that conversation" is a precise operation: ## 2026-07-30 [REMOVED].

R2A support queue an agent can work

The queue is the file. Humans read it in a code editor; agents triage, annotate, and resolve with surgical patches. Order is state — [FIRST] is literally moving a case to the top of the pile.

queue.terse
# Cases
## 4412 outage(priority: high; open; billing; auth)
reporter(name: "Ada Reyes"; phone: "555-0100")
"""
Night shift lost auth to the billing API.
"""
## 4406 password reset(priority: low; open)

// the agent's triage loop:
? Cases.* [WHERE Its.priority == "high"]       // what's burning?
? Cases.* [CONTAINS "billing"]                 // related history?

// escalate, annotate, resolve — three one-line patches:
## 4406 password reset [FIRST]
## 4412 outage
root cause(stale session signing key)
## 4412 outage(+resolved; -open)
Every mutation is idempotent — replaying the same declaration is safe. That makes agent retries harmless instead of state-corrupting.

R3A claim-tracking sidecar for RAG

Instead of extracting facts into a vector soup, keep a legible ledger next to your index: every claim cites a source, contradictions get flagged rather than overwritten, and syntheses compound. This is the terse-brain pattern, in one screen.

claims.terse
# Raw
## q3 earnings memo(registered: 2026-07-12; kind: memo)
## analyst call transcript(registered: 2026-07-20; kind: transcript)

# Claims
churn fell in q3(confidence: 0.9; source: @Raw.q3 earnings memo)
expansion drove growth(confidence: 0.7; source: @Raw.analyst call transcript; disputed)

# Synthesis
## retention story(born: 2026-07-21)
"Churn improved but the growth driver is contested —
see disputed claim before citing."

// the queries that make it useful:
? Claims.* [WHERE Its HAS disputed]            // what's contested?
? Claims.* [REFERENCES]                        // claims + their sources
Why it works: @ references are parser-known, so a claim can't silently cite a source that isn't registered — dangling refs surface as warnings, not as hallucinations three prompts later.

R4Two agents, one store

A researcher and a writer share state without trampling each other. Each owns a container; each writes by declaration; neither ever needs to re-emit the other's work.

agent A — researcher writes
# Findings
latency spike(service: checkout;
  p99 ms: 2400; when: 2026-07-29)
rollback correlation(confidence: 0.8) [MERGED]
agent B — writer reads & files
? Findings.* [WHERE Its.confidence > 0.7]

# Report
## incident summary [APPEND]
"""
Checkout p99 spiked to 2.4s on 07-29,
correlated with the rollback.
"""
The contract is structural: A only declares under # Findings, B only under # Report, and silence preserves guarantees neither touches state it doesn't mention. No locks, no merge conflicts — just kind-scoped, name-addressed writes.

R5An append-only run log with a cheap tail

Long-running agents need a journal that grows forever but reads cheaply. Placement directives keep entries ordered; [LAST n] tail-peeks without loading the history into context.

runlog.terse
# Log
## Records
run 0041(op: ingest; when: 2026-07-30T09:14; ok) [LAST]
run 0042(op: lint; when: 2026-07-30T09:31; findings: 2) [LAST]

// tail-peek so the agent can mint the next id
// without reading 4,000 records:
? Log.Records.* [LAST 5]
? Log.Records.* [WHERE Its.op == "lint"; LAST 3]
? Log.Records.* [WHEN 2026-07-30]
Why it works: sibling order is state, so [LAST] is an assertion, not a hope — reapplying it is idempotent, and out-of-order entries are exactly the kind of drift a lint pass catches.
Have a pattern of your own? The spec is Apache-2.0 and the repo takes recipes. Want these running against a live store? Wire up terse-mcp in five minutes.