Strong Context References

A strong context reference identifies both where an agent found a context object and which exact version it observed. A file path, URL, record URI, or channel identifier supplies location. A commit, content hash, CID, message identifier, ETag, or timestamped snapshot supplies version identity.

This page applies content-addressing and provenance ideas to agent memory. “Strong context reference” is a design term used in this knowledge base, not a W3C, Git, or AT Protocol standard term.

Location and content identity

A weak reference names a mutable place:

the user profile
the current project note
that public post
the latest conversation summary

A stronger reference records several dimensions:

location: memory/system/profile.md
version: git-commit:c20669d
content_digest: sha256:...
authority: agent-context-repository
observed_at: 2026-07-20T23:15:00Z
semantic_role: canonical_profile
permission_boundary: private

The location allows later retrieval. The version answers whether the retrieved object is still the evidence that the earlier action used.

AT Protocol analogy

AT Protocol repositories separate stable record paths from content-addressed objects. A repository commit points to a content-addressed Merkle tree and is signed by the account. Mutating a record changes the repository root. Complete repositories can be exported for verification, backup, and migration.

The useful analogy for agent memory is not that a Markdown file should become an ATProto record. It is that mutable address and observed content identity are different fields. A path can stay stable while its contents change.

Git analogy

Git stores content-addressed blobs, trees, and commits. A branch name is a movable reference; a commit identifies a particular history and tree. An agent that records only “main” cannot later prove which version it read. An agent that records only an object hash loses the human and operational role associated with the path or branch.

A practical reference therefore preserves both.

Authority and permission

Version identity does not establish authority or publication permission. Two identical strings can come from different sources with different operational meaning. A fact learned in private conversation and the same fact read from a public page may support the same proposition while carrying different rights for reuse.

For consequential uses, a reference should record:

1. location;
2. exact version or content identity;
3. source authority;
4. observation time;
5. semantic role;
6. permission boundary.

The W3C PROV data model provides broader vocabulary for entities, activities, agents, derivations, revisions, and responsibility. Strong context references can act as the identifiers carried through such a provenance graph.

Uses

Strong references help an agent:

• cite the memory version used in a decision;
• detect stale context after a file changes;
• bind a review to the exact artifact reviewed;
• distinguish a draft from a published revision;
• restore an agent identity from a known state;
• reproduce a tool or model run with the same input evidence;
• prevent one conversation from acting on another conversation's obsolete authorization;
• trace a public claim back to an approved public source.

They do not make the referenced content true. They make the claim's dependency inspectable.

Design limit

Hashing everything can create ceremony without meaning. Strong references are most valuable for objects that may be cited, revised, audited, published, restored, or used as authority for an external effect. Temporary low-consequence context can remain weakly referenced when the cost of exact provenance exceeds its value.