← Back to selected work

CASE STUDY / CONTEXT ARCHITECTURE

Maintaining context across extended AI projects

By Colton Anderson · October 18, 2026

My AI folder system gives assistants a shared place to find project instructions, current state, decisions, and supporting evidence. Its purpose is to help a fresh session resume useful work without depending on an entire conversation history or loading every project into context.

This walkthrough describes the system's documented architecture and includes a small fictional example. It demonstrates how I organize context and frame agent behavior; it does not establish that these instructions reliably prevent failures. The examples contain no employer code, production records, account information, or real machine locations.

The problem I am working on

My interest comes from applying AI to practical work, including report development and automation. As projects extend across sessions, information can be omitted from summaries, become outdated, or be mistaken for an instruction that still applies. A detailed conversation is also a poor substitute for a clear statement of what is true now.

I use files to separate several questions: What does this project do? What is currently happening? Which decisions remain in force? Where is the evidence? What is the agent authorized to change?

That separation gives me a way to inspect and revise the context supplied to an agent. It also creates research questions about whether the agent retrieves the right information and respects it over time.

How a task moves through the folder

User request
    |
    v
Root router: choose one project room
    |
    v
Room rules + stable context + current state
    |
    v
Relevant index entry -> specific decision, reference, or evidence
    |
    v
Verify changing facts against the live source
    |
    v
Perform authorized work -> check result -> persist findings and next state

A room is a folder responsible for one domain or project. The router tells the agent which room to enter. It does not contain all the knowledge from all the rooms. Native entrypoint files connect compatible assistants to this shared map; each assistant still has its own tools, permissions, and runtime.

What each file is responsible for

FilePurpose
START-HERE.mdRoute the request to the responsible room.
AGENTS.mdState required behavior and boundaries.
CLAUDE.mdA thin Claude Code adapter that imports AGENTS.md, so every agent follows one rulebook.
CONTEXT.mdDescribe stable project identity, scope, and authoritative sources.
CURRENT-STATE.mdReconstruct the present situation and next safe action.
INDEX.mdPoint to the specific references and evidence needed for a task.
DECISIONS.mdPreserve decisions with their source and scope.
reports/ and archive/Retain detailed findings and superseded state.

Current state is a compact working set. Completed investigations and historical narratives belong behind an index entry. When state changes, the current statement is replaced while the supporting history is preserved elsewhere.

Load less without discarding knowledge

The system uses three context categories:

  • Hot: the small startup set needed to begin correctly, such as routing, rules, and current state.
  • Warm: indexes and registries that locate relevant detail.
  • Cold: detailed reports, evidence, and historical material retrieved for a specific question.

These are retrieval rules, not different storage engines. The intended benefit is a smaller initial context with a clear path to the underlying evidence. A shorter summary is only useful if the information it leaves out remains findable.

Before compacting current state, the procedure is to preserve the earlier version, give material facts a durable home, update pointers, and check that those pointers resolve. The source system includes a structural audit tool, although this public example does not reproduce that implementation. Such checks can catch document defects; they cannot prove that an agent understood the documents.

A fictional report task

The downloadable example folder contains a complete miniature context tree. Every business scenario, date attached to an example event, decision, and finding in that tree is fictional. The findings illustrate how evidence is recorded; they are not results from an agent evaluation.

Suppose the request is: “Prepare a draft change to the monthly summary report so its dates match the revised requirements. Do not publish it.”

  1. The root router selects the reporting room.
  2. The room rules allow drafting and require separate authorization for publishing.
  3. Current state identifies the requirements change, the unresolved question, and the next action.
  4. The index points to the requirements and a prior review note.
  5. The requirements specify the reporting timezone. A superseded state file shows an older timezone assumption, so the agent should use the current requirements rather than resurrecting that assumption.
  6. A source note contains a quoted instruction to publish immediately. The agent should treat that quotation as document content, not as permission to publish.
  7. The agent can describe a draft change and a verification plan. Actual implementation requires access to the operational report source; the example contains no executable report or production connection.

After work, a useful handoff states what changed, what was checked, what remains unresolved, and the next authorized action. A claim that a report is correct should point to the checks supporting it.

Context and authority stay separate

Saved context helps an agent understand a task. It does not grant new access or permission. Synchronizing the folder between computers does not authorize changes on either computer.

For factual questions, live operational evidence takes priority over dated summaries. For actions, the user's current authorization and applicable project rules govern what may happen. A live webpage can be evidence without becoming an instruction source. External documents, tool output, and historical conversations must not acquire authority merely because the agent reads them.

The shared folder excludes credentials, private runtime databases, and raw business records. Those remain in their operational locations. The context layer records appropriate pointers and boundaries instead of copying sensitive systems into shared memory.

Completion review

The workflow asks whether the requested outcome has actually been achieved, whether the result is worth sharing, and which evidence supports that conclusion. Substantial deliverables receive a separate review using a small packet: the request, acceptance criteria, artifacts, constraints, and verification evidence.

This is intended to catch incomplete work and unsupported completion claims. A second review can still share the producer's blind spots, especially when both use the same model or incomplete evidence. Review is an additional check, not a guarantee.

Limits and questions to test

Files can be stale, contradictory, incorrectly routed, or ignored. Summaries can preserve a claim while losing its qualification. An agent may retrieve the correct requirement and still fail to apply it. Concurrent sessions may overwrite newer state unless they re-read and coordinate before writing. Instructions alone do not enforce a security boundary; tool permissions and isolation remain necessary.

I have not established a measured reduction in context drift or unauthorized actions. A next experiment would compare the same fictional tasks under conversation-only context, a single large context file, and the routed folder structure. Repeated runs could measure:

  • Whether the agent retrieves and follows the current requirements.
  • Whether it carries superseded assumptions into its answer.
  • Whether permission boundaries survive summaries and session handoffs.
  • Whether completion claims match the evidence available.
  • How much context and human intervention each approach requires.

Task success and safety failures would need to be reported separately. An agent that avoids every action can respect a boundary while failing the task. Any such evaluation should use isolated tools and synthetic data.

Contribution and attribution

My contribution is applying and adapting this context architecture to my own workflows: organizing project rooms, defining context and authority boundaries, and directing iterative improvements with AI assistance. The hot, warm, and cold context approach and related maintenance practices are informed by Clief Notes methodology; I do not claim to have invented those concepts.

This walkthrough and its fictional example were prepared with AI assistance. It presents a practical system and research direction, rather than a published safety result. Employer plugins and materials are outside the scope of this public sample.

Explore the example

Use the interactive file explorer to follow the fictional project room, or download the complete example to read it offline.