Personal Context Blueprint — The Lab

Lesson 1 of 6 · Module 1 · Foundations

Begin with utility, not biography.

5 min

Learning objective

Define the real work a context repository should improve before deciding what it should remember.

Do not begin by asking what an AI could know about you. Begin by naming work that improves when context survives: carrying a project between agents, generating a resume from reviewed evidence, remembering why a decision was made, or adapting advice to a real constraint.

Downstream use is a filter. If a detail never changes support, it probably does not deserve the maintenance cost or privacy risk of becoming durable context.

Design test

What should become easier because this repository exists?

Good: “Resume drafts should use reviewed work evidence.”
Weak: “Store everything about me.”

Knowledge check Which is the strongest starting point for a personal context repository? A list of every fact the agent could possibly remember One real task that becomes easier when context survives A transcript archive covering every conversation

Lesson 2 of 6 · Module 1 · Foundations

Give every agent a short front door.

6 min

Learning objective

Design a concise entry point that tells an agent where context lives and what rules take precedence.

The repository needs one compact map—llms.txt—that explains where context lives and which instructions take precedence. An agent reads that map first, then opens only the files relevant to the current task.

This progressive-disclosure pattern prevents a large repository from becoming a giant prompt. It also lowers accidental exposure: a project question does not require loading health, finances, or relationship context.

Minimal llms.txt

# Context map

1. Read AGENTS.md and active constraints.
2. Open only the relevant module index.
3. Prefer recent, sourced records.
4. Ask when the repository is silent.

Knowledge check What is the main job of llms.txt in this architecture? Store a compressed copy of every personal record Orient the agent and route it to the smallest relevant context Replace all project and area indexes

Lesson 3 of 6 · Module 1 · Foundations

Separate capture from maintained knowledge.

6 min

Learning objective

Keep raw imports and quick capture visibly distinct from context the system is allowed to trust.

Brain dumps, transcripts, exports, and imported documents are raw material. They may be incomplete, outdated, or written for another purpose. Keep them in an inbox or import lane instead of silently treating them as facts.

Maintained records are different: they have a clear scope, provenance, privacy tier, confidence level, and review path. An agent can compare raw material against existing context, surface conflicts, and propose a durable edit for the human to inspect.

Two-lane workflow

_imports/meeting-notes.txt   → raw evidence
inbox.md                     → unprocessed capture
projects/example.md          → reviewed context
log.md                       → record of the change

Knowledge check How should an imported transcript be treated at first? As evidence awaiting review and compilation As confirmed personal context As a replacement for all existing records

Lesson 4 of 6 · Module 2 · Trustworthy context

Make consequential claims inspectable.

6 min

Learning objective

Use metadata to show where a claim came from, how certain it is, and when it should be reviewed.

A sentence can sound equally confident whether it came from the person, a document, an old conversation, or the model’s inference. Metadata makes those differences visible.

Privacy, source, confidence, freshness, and review status are not administrative decoration. They tell future agents whether a claim may be used, repeated, questioned, or treated as stale.

Durable entry header

privacy: private
source: self
confidence: confirmed
updated: 2026-07-19
review_after: 2026-10-19
needs_review: false

Knowledge check Why should durable claims carry source and confidence metadata? To make Markdown look more technical To let future agents distinguish evidence from inference To remove the need for human review

Lesson 5 of 6 · Module 2 · Trustworthy context

Use questions to correct the model.

6 min

Learning objective

Build a correction loop that exposes uncertainty, contradiction, staleness, and overconfident interpretation.

An AI can produce a coherent but wrong portrait for a long time. After meaningful updates, ask it for both insights and questions. Those questions reveal where the agent is uncertain, where records conflict, and where your words may have been interpreted too broadly.

Human review works best through readable diffs. You do not need to hand-edit every file; you need to see what changed before the system quietly relies on it.

Correction prompt

Show the proposed diff. Then tell me:
1. What became newly visible?
2. What might you have misunderstood?
3. Which claim is stale, inferred, or contradictory?
4. What should I answer before this becomes trusted context?

Knowledge check What should an agent return after a meaningful context update? Only a confident summary A hidden rewrite of the relevant files A readable diff plus questions about uncertainty and conflict

Lesson 6 of 6 · Module 3 · Maintenance

Extend deliberately.

6 min

Learning objective

Add modules, lookup surfaces, and automation without turning the boot path into an indiscriminate archive.

New needs should usually become a module with its own purpose, privacy default, index, template, and entry in llms.txt. If agents repeatedly copy the same fields across records, add a compact lookup surface instead of another narrative summary.

Automations come last. First prove that the manual update loop produces trustworthy context. Then automate capture, freshness checks, or compiled indexes without weakening review and provenance.

Extension checklist

1. Name the downstream use.
2. Set the module’s privacy default.
3. Add INDEX.md and a record template.
4. Link it from llms.txt.
5. Test with synthetic context.
6. Review before adding automation.

Knowledge check When should automation be added? Before the manual workflow has been tested After the manual trust and review loop works reliably Whenever the repository gains a second file

Context Blueprint

Begin with utility, not biography.

Give every agent a short front door.

Separate capture from maintained knowledge.

Make consequential claims inspectable.

Use questions to correct the model.

Extend deliberately.

You understand the architecture. Now make it yours.

Complete all six lessons to begin the capstone.

What should this context make easier?

Which parts deserve their own lane?

How should people and agents maintain it?

Own the files. Change the system.

Keep an informal record of what you completed.

Memory becomes useful when it can disagree with you.