Markers in your files, indexed live, queryable cold.
The disk is the database. The SQL is the cache.
The preeminent problem in agentic coding and more broader agentic space in general is what is becoming known as the “agent context problem.”
Every point of information an agent could ever need in a future session can be captured — but what aspects of that knowledge to surface to an agent and how to surface it remain the lynchpin of the agent context problem. The scry marker specification attempts to address some of the surface of the agent context problem as it relates specifically to agentic coding.
<!-- @scry.entry id: design.auth-flow~9eb0fd7e kind: design status: active weight: 0.9 tags: - "topic:auth" - "auth" summary: > JWT auth middleware, validates bearer tokens. Also: JWT, bearer-token, auth-guard, refresh-flow. applies: adding protected endpoints, modifying auth seeded_questions: - "What is the JWT refresh flow?" - "JWT bearer token validation" @scry.entry.end -->
SELECT id, summary FROM scry__doc WHERE kind = 'design' AND id IN ( SELECT doc_id FROM scry__doc_tag WHERE tag = 'topic:auth' ) ORDER BY weight DESC; -- or, full-text: SELECT id, summary FROM scry__doc_fts WHERE scry__doc_fts MATCH 'JWT refresh flow' ORDER BY rank;
Scry markers are written for agents by agents. Every artifact an agent produces — a design, a spec, documentation, even a code file — carries a marker, written into the file itself and authored to be found: its summary, tags, and seeded questions shaped the way a later search will reach for them. Scry indexes those markers into a SQLite cache the next agent retrieves with a line of SQL — full-text-searched, deterministic, no LLM in the query path. The hard choice — which knowledge is worth surfacing — is made once, at write time, by the agent that did the work; recall is just a query against what was already judged worth keeping.
Reflection, a 100+ track autonomous substrate, runs scry in production. The numbers below are queried live from reflection’s own project.db at the time this page was deployed.
2,707
curated @scry.entry markers across 10,115 indexed files. 2,674 files carry their own marker; the remainder are body-indexed only.
17,663
tags on the corpus (3,716 unique), plus 8,415 seeded questions and 1,174 distinct topic: classifiers — each one a query an agent already shaped against future-itself.
198
markers minted by reflection’s wakes on a single day (2026-05-19). The graph grows by the work the system does, not by a separate documentation pass.
| kind | count | what it is |
|---|---|---|
| report | 2,013 | wake-report records — what happened in a session and why |
| internal | 267 | runtime fixtures — track wake files, control surfaces, contracts |
| design | 127 | current-truth design docs |
| pattern | 107 | canonical recipes — “the way to do Z” |
| spec | 54 | authoritative contracts |
| research | 41 | findings + sources from investigation wakes |
| code | 40 | code-file markers |
| task | 24 | discrete work items |
| lesson | 22 | “I tried X, here’s why it failed” |
| audit | 7 | conformance audits |
| milestone | 4 | phase markers |
Source: reflection — the 100+ track autonomous substrate that developed and runs scry. Numbers are a live snapshot at deploy time.
scry was built using the substrate that uses it. The corpus above is what reflection has accumulated, addressed against itself, and recalled from across wakes; it is also the corpus the next reflection wake will query before deciding what to do.
Paste an @scry.entry marker on the left. The parser runs in your browser — no network call, no LLM — and shows the structured row scry would insert into scry__doc. That row is what the next agent recalls with a single SQL query, in any wake, indefinitely.
The parser implements the same sentinel + comment-prefix-strip + YAML body rules as scry-parse. Edit the marker and the row updates live. The contract is plain enough that the entire scoped parser fits on this page; the production parser adds anchors, bindings, diagnostics, and FR-conformance coverage.
Below is the same marker / SQL pair as above, expanded into a shape you can copy and run. The marker lives at the top of the file; the SQL runs against the SQLite cache scry init created in your project.
# In agent/design/auth-flow.md <!-- @scry.entry id: design.auth-flow~9eb0fd7e kind: design status: active weight: 0.9 tags: ["topic:auth", "auth", "scope:runtime"] summary: > JWT auth middleware, validates bearer tokens. Also: JWT, bearer-token, auth-guard, refresh-flow. applies: adding protected endpoints, modifying auth seeded_questions: - "What is the JWT refresh flow?" - "JWT bearer token validation" @scry.entry.end --> # In a future wake, scry_sql: SELECT d.id, d.summary FROM scry__doc d JOIN scry__doc_tag t ON t.doc_id = d.id WHERE t.tag = 'topic:auth' AND d.status = 'active' ORDER BY d.weight DESC;
One row comes back, every time. No vector store. No re-rank. No LLM in the query path. The marker fields decided what would be found before any future agent went looking; the SQL is just the lookup that honors that decision.
Install the MCP server.
uv tool install scry-mcp
# or:
pip install scry-mcpAdd scry to your agent’s MCP config.
{
"mcpServers": {
"scry": {
"command": "scry-mcp"
}
}
}Initialize scry in your project.
cd path/to/your/project scry init
A project.db appears in the working directory; the watcher begins indexing markers as files are saved.
scry-spec v1.1 — the versioned Scry Marker Contract. Defines the three marker kinds (@scry.entry, @scry.anchor, @scry.bind), the required and optional fields, and the resolution rules for binding references. Versioned independently from any implementation.
SQL is scry’s answer, not the spec’s mandate — scry-spec defines the marker; scry is the implementation that makes it queryable. A different implementation could index the same marker corpus into embeddings and serve recall by similarity; RAG, in that sense, is a possible implementation of the marker contract rather than a peer alternative to it.