Scry is most honestly understood in relation to the other approaches to the agent context problem — not as the only answer, but as one shape among several. This page is that comparison.
Eight categories below, each classified peer, adjacent, or subordinate against scry’s marker contract, with named systems and the precise place each one is genuinely strong or genuinely limited. The classification key sits at the top; a summary at the bottom names where the alternatives are strongest and where the marker contract has the clearest edge.
Scry’s answer is a marker contract with three marker types. @scry.entry declares an artifact and carries the curated fields (id, summary, tags, applies, seeded questions) an indexer pulls into a queryable cache. @scry.anchor turns any code comment or in-file point of interest into a named, queryable location — a primitive for making arbitrary in-file locations findable. @scry.bind is the typed edge — implements, depends_on, supersedes — that makes the graph bidirectional. The agent queries the cache by structured fields, not by similarity. Authoring is deliberate; every marker is part of the file under version control.
Justification:RAG returns nearest-neighbour chunks by embedding similarity; the marker contract can use embeddings as one ranking signal among structured fields. RAG-as-implementation is fine; RAG-as-substitute confuses retrieval with curation.
Retrieval-Augmented Generation: chunk the corpus, embed each chunk with a model (OpenAI text-embedding-3, Voyage, BGE, etc.), store vectors in an index, and at query time embed the query and return the nearest-neighbour chunks as additional context to the LLM.
FAISS (Meta, library), pgvector (Postgres extension), Pinecone, Weaviate, Chroma, Qdrant, Milvus, LanceDB, ElasticSearch’s dense_vector, OpenAI Assistants File Search, LlamaIndex and LangChain retriever abstractions sitting atop any of the above.
Similarity in embedding space is treated as a proxy for relevance. The corpus is not curated; the index is the curator, by way of the embedding model’s learned geometry.
Production RAG against a frozen index is deterministic — the same query returns the same chunks. The honest weakness is not raw non-determinism but the opacity of the ranking and the silent sensitivity to embedding-model upgrades: change the embedding model and the same query returns different chunks without anything in the system saying so. A marker contract can use embeddings as one ranking signal among structured fields. Scry’s own scry__file_fts is full-text; a future tier could embed marker summaries and add nearest-neighbour lookup. RAG is a mechanism the marker contract can absorb, not an alternative shape of the same answer.
Justification:Code intel names what exists and where; the marker contract names what something is and why. Different layers. They compose.
Tooling that indexes a codebase by symbol — what functions exist, where they’re defined, where they’re called, what types they have — so an editor or search UI can jump to the right place.
workspaceSymbol, definition, references, hover.“What exists” is answered at the level of program structure — symbols, definitions, types, references — not the level of intent, decision, or lesson.
An agent often needs both. A marker can bind to a symbol that LSP resolves, and code intel can be the substrate a marker-aware agent uses to follow implements edges into the implementation.
Justification:The closest paradigm match to scry. Scry is, viewed sideways, a knowledge graph whose nodes are in-file YAML markers and whose edges are implements / depends_on / supersedes references. The difference is location: scry’s graph lives in the source, not in a sidecar store.
Represent the corpus as nodes (entities, files, concepts) and typed edges (depends-on, implements, supersedes) in a graph database; query with a graph language.
Curated or extracted typed relationships between things. Querying becomes graph traversal (“which lessons are bound to specs that this PR’s files implement?”) rather than similarity.
implements / depends_on) are materialized at write time as committed in-file markers. An agent typically authors the marker — the hallucination surface is real — but it is paid once, on a reviewable, correctable, supersede-able artifact, and the graph is stable across reads thereafter.Joern’s CPG and GraphRAG are genuinely doing similar work for different problems. GraphRAG is the most direct prior art for “structured graph above raw retrieval, queryable by an agent.” Scry’s bet against it is the location bet — in-source vs sidecar — not a claim that structured curation is novel.
Justification:The projects most likely to be named in the same sentence as scry. The line worth drawing precisely: agent-memory frameworks are the right tool for memory of interaction; the marker contract is the right tool for memory of artifact.
Libraries and services that give an LLM agent durable, structured memory across sessions — facts, preferences, prior decisions — separate from the model’s context window.
ConversationBufferMemory, ConversationSummaryMemory, persisted via Redis / SQLite / Postgres. Lighter-weight than Letta; bring-your-own discipline.Treat memory as the agent’s self-managed substrate. The agent reads and writes via tools. Storage is typically a vector store, sometimes a graph, sometimes a JSON document the framework hands back on each turn.
Project-scoped fact recall. mem0’s positioning increasingly extends past chat into “memory for coding agents.” That is the line scry sits on. The distinguishing question becomes: does the memory live in the source tree (scry), or in a sidecar service (mem0)? A mature agent could use both, for different things.
Justification:Long context is the substrate inside which retrieval and curation operate. Scry decides what to include; the context window decides what fits. They compose.
Skip retrieval; put everything in the prompt. Rely on model context windows large enough to hold the relevant slice of the codebase or document set.
Curation is the model’s job at inference time. Stuff the window; let attention sort it out.
Justification:The marker contract is this pattern pulled apart into one marker per artifact, with a schema. Many CLAUDE.md files are scry markers waiting to be extracted.
Markdown files at known paths that agents are instructed to read at session start. The simplest possible solution; massively deployed.
CONVENTIONS.md.Pre-load fixed context. Curation is manual; format is freeform prose. Newer conventions support selective imports and hierarchical loading. This is a genuinely viable selection function, albeit a manually curated one.
Justification:Grep is the universal floor; the marker contract is the curated ceiling. Scry’s own scry_grep is body FTS underneath, with marker FTS above. They compose.
Search the source tree by literal or regex pattern. Fast; ubiquitous; the floor every agent already has.
GNU grep, ripgrep (rg), ag (the silver searcher), ack, OpenGrok, livegrep, Sourcegraph’s text search, SQLite FTS5, ElasticSearch BM25.
No curation; the corpus is the index. Find by token, not by meaning.
auth returns every file that contains the word, equally.implements from spec to code.JWT will not find a doc that only says “bearer token.”Justification:Same audience (long-horizon coding agents), same marketing language (“persistent, structured memory for coding agents”) — different layer. A task graph tracks what needs doing; the marker contract indexes what already exists. They compose; they do not substitute.
A dependency-aware issue tracker built for AI agents rather than humans. Tasks are nodes in a graph with typed edges (blocks, relates_to, duplicates, supersedes); ready-task detection falls out of the graph. Storage is a versioned SQL database so multiple agents on multiple branches can write concurrently without merge collisions.
Beads (bd). Dolt-backed (the version-controlled SQL database) in embedded or server mode; hash-based task IDs (bd-a3f8.1.1) sidestep the merge-collision problem that hits sequential IDs in multi-writer workflows. Targets Claude Code, Copilot CLI, Factory.ai and similar agents.
Treat agent context as the set of pending tasks and their dependencies. The agent queries the graph for the next ready task, marks progress, threads messages against tasks, and lets closed tasks compact away as “memory decay.” State the agent maintains about its own work is durable and queryable across sessions.
.beads/embeddeddolt/ (or an external Dolt server), not in the source files. Cloning the project clones the directory; understanding why the code looks the way it does still requires the artifact layer.The honest read is that beads and scry are complementary tools that share an audience. A mature coding-agent setup could plausibly run both: beads as the work queue, scry as the artifact index. The categories overlap in marketing copy and diverge in mechanics.
One convergence worth noting: beads and scry independently arrived at the same answer for stable identity under concurrent multi-agent writes. Beads mints hash-based task IDs (bd-a3f8); scry mints collision-checked hash-suffixed marker IDs (design.auth-flow~abcd1234) via scry_mint. Two tools built independently in the agent-tooling space, converging on the same ID design — observation, not endorsement, but it is a signal the shape of the problem rewards the shape of the answer.
Stated honestly, because a comparison page that hides them would not be the page it claims to be. The marker contract has three marker types — @scry.entry declares an artifact, @scry.anchor names a queryable point inside a file, and @scry.bind is the typed edge that makes the graph bidirectional — and each carries its own slice of the cost:
Marker discipline is the cost. A well-authored marker — summary, tags, weight — is what lets a file win the curated tier: the precise, ranked surface a future query lands on. An unmarked file, or a file whose marker fields have drifted out of sync with its contents, forfeits that. It loses the curated ranking signal; the marker no longer speaks for the file, so the file no longer competes where it should. This degradation is silent — it surfaces only to the agent that later queries the system and gets a worse answer than the corpus could have given.
What that doesn’t mean is that the file vanishes. Whether an unmarked file remains findable at all is an implementation choice, not a guarantee of scry-spec. An implementation that does full document indexing — indexing each file’s whole body, not only its marker — keeps the unmarked file present and full-text searchable; it simply competes on raw body text instead of on curated summary, tags, and weight. The reference scry implementation does exactly this: scry_grep runs full-text search over every indexed file body (scry__file_fts), so an unmarked file is still reachable, just uncurated. An implementation that indexed markers alone would not offer even that floor. The spec defines the curated tier; the fallback is something an implementation may choose to provide.
lessons, journal, memory, notes, preferences, conversations, internal, or whatever taxonomy fits the project — marked files of those kinds are indexed alongside designs and specs, and the agent queries them the same way. Letta, mem0, and Zep ship a managed interaction-memory product out of the box; scry covers the same ground if the project adopts a convention for it. A mature agent can use both, for different reasons.