StackMap
Subscribe

okf-agent-memory vs Trellis

Git-native agent memory on Google's OKF v0.2: Markdown+YAML concepts in knowledge/, a zero-dep Go CLI/MCP with <300µs BM25 search, provenance and trust tiers. — versus — Spec, task and memory layer that lives in your repo: .trellis/ holds conventions, PRDs and journals, auto-injected each session — one workflow across 20 coding-agent platforms.

The curated verdict

Same in-repo, git-versioned memory idea: trellis holds conventions, PRDs and journals in .trellis/ and auto-injects them; OKF holds typed concepts with a link graph and lets the agent search rather than inject everything.

okf-agent-memoryTrellis
Stars54215k
Forks33820
LanguageGoTypeScript
LicenseMITAGPL-3.0
Last activityyesterday15 days ago
Topicsmemory, coding, knowledge-graphscoding, memory
Curated connections56

okf-agent-memory — the curator's take

Pick this when you want agent memory you can `git diff` and code-review: every concept is a Markdown file with provenance, trust tier and staleness metadata, and progressive-disclosure indexes keep loads small. It is lexical-only (BM25) by design — no embeddings, no API cost — so it wins on decisions, constraints and glossary-style facts, not on fuzzy semantic recall of past conversations. Skip it if you want automatic session capture (it is search-before-write, human/agent-authored) or memory shared across many repos; it is per-project and lives in the repo.

Trellis — the curator's take

Attacks the right problem — agents restart from zero every session — with the boring, durable fix: files in the repo, not a memory service. Team-shared specs are the real moat; one engineer's hard-won rules compound for everyone. It's opinionated though: the 4-phase loop (brainstorm → implement → check → update-spec) only pays if the team actually adopts the process — half-adopted, .trellis/ rots into stale paperwork. AGPL-3.0: fine to use, but check your company's license policy. Skip it for weekend projects; this is process overhead that needs a team to amortize.