Agent memory is fragmented
Each harness stores instructions, traces, and context in its own format, so useful knowledge is trapped in one tool.
use-afs skill
The standard ships with templates, scripts, hooks, and references.
AFS is a filesystem and Markdown standard for users, companies, codebases, and business areas. It keeps traces, source provenance, knowledge, and intent legible to humans and portable across agentic systems.
Normal files
No database required
Markdown first
Readable by humans
Agent ready
Reusable context
Problem
AFS exists because information between platforms is disconnected. Agents need a way to share traces, context, knowledge, source references, and working state in a format that is easy to move.
Each harness stores instructions, traces, and context in its own format, so useful knowledge is trapped in one tool.
Teams need a plain, portable structure that lets agents share traces, context, sources, and decisions without a platform migration.
External docs, links, copied references, source snapshots, and generated summaries need an obvious home with source history.
Core principles
The standard should work in a plain Git repository, a personal notes folder, a company workspace, or any agent runtime that can read and write files.
AFS stays useful through normal files, folders, Markdown, grep, pull requests, and backups.
Codex, Claude Code, Cursor, Notion Agents, OpenClaw, Hermes, and local tools can share the same durable context.
Timestamped logs, lessons, fixes, plans, results, and reflections preserve work-in-time evidence; live specs, runbooks, and knowledge hold current truth.
Root files such as AGENTS.md, USER.md, VISION.md, LOOPS.md, TASTE.md, and GAPS.md keep direction and missing understanding readable before agents act.
Path group
Durable history, facts, lessons, fixes, steering traces, and reflections that help agents improve across sessions.
Memory
12 paths/logs/Brief change logs, two lines max, appended to the latest dated file under YYYY/MM-DD/ such as logs/2026/06-29/changes.md.
/lessons/<domain>/Lessons learned from experience, organized by domain and timestamp folders such as YYYY/MM-DD/.
/facts/Live factual documentation about the user, companies, items, episodes, and triples; organize by type first, then domain.
/facts/items/<domain>/Live atomic fact records and item documentation, grouped by domain. Do not place these under timestamped folders.
/facts/episodes/<domain>/Live episode records derived from fact items or user/company history, grouped by domain. Do not place these under timestamped folders.
/facts/triples/<domain>/Live subject-predicate-object triples derived from fact items and episodes, grouped by domain. Do not place these under timestamped folders.
/fixes/Error solutions from issues that were actually fixed, organized in timestamp folders such as YYYY/MM-DD/.
/steers/Traces of agent work that a human or secondary model redirected, including what the agent got wrong or missed, organized in timestamp folders.
/models/decisions/Live brief records of decisions made so reasoning remains inspectable.
/models/problems/Live brief records of problems encountered and their current status.
/models/goals/Live brief records of goals set, active goals, and goal outcomes.
/reflections/Detailed platform, project, workflow, or agent-behavior reflections, organized in timestamp folders such as YYYY/MM-DD/.
Path group
Work products, raw material, plans, specs, generated libraries, and domain-specific operating surfaces.
Operational
10 paths/audits/Comprehensive reports and analytical audits used for audit-driven development, organized in timestamp folders such as YYYY/MM-DD/.
/raw/Raw data waiting to be ingested, processed, defined in knowledge/ or another canonical destination, and then removed or marked as done.
<domain>/<folder>/Additional domain-specific paths for areas such as health/, investing/, sales/, or operations/ when the domain genuinely needs its own surface.
/plans/Implementation plans and plan-driven-development artifacts, organized in timestamp folders such as YYYY/MM-DD/.
/specs/Living desired-state documentation describing how something should be. These are primarily human-defined and not timestamped.
/sources/URL-based sources to monitor, extract, compile, and organize into knowledge additions.
/lib/A library for generated content, drafts, registries, indexes, and other reusable support artifacts.
/objects/<type>/Structured object records such as clients, employees, vendors, accounts, projects, or product surfaces.
/templates/Reusable templates such as AI prompts, emails, scripts, and other repeatable starting points.
/results/Stored results from work that was run and needs to be preserved, organized in timestamp folders such as YYYY/MM-DD/.
Path group
Living documentation that represents the current canonical understanding of the codebase, company, workflows, and sources.
Source of truth
5 paths/references/Code, URL, API, schema, and technical references that need stable lookup as live documentation.
/cookbooks/Technical guides for how something is actually done in the codebase or operating environment.
/knowledge/Timeless maintained knowledge about the codebase, business, or how to do something. It can be defined by humans or compiled from raw/.
/runbooks/Operational procedures for how recurring work should be done after it has been performed in a known way.
/research/Continuous research related to software engineering, business areas, markets, or other ongoing questions.
Root MD files
These files define the user, company, product, agent behavior, specs, plans, taste, loops, unresolved knowledge gaps, risk, and operational state. They should live at the root of an AFS-aware repository or workspace.
Brain
Decides how the AFS should be managed.
Vision
Defines the north star, current direction, non-goals, strategic constraints, and what agents should protect over time.
Loops
Defines recurring agent loops, triggers, cadence, review gates, stop conditions, and improvement cycles.
Taste
Captures high-quality and personalized judgment: what good looks like, preferred examples, anti-patterns, and subjective standards.
Gaps
Tracks gaps in human or agent understanding so unresolved questions stay visible until agents can resolve them into durable knowledge.
Memory rules
Defines how memory should be captured, promoted, and maintained.
Playbook
Defines decision frameworks and repeatable operating patterns.
Agent rules
Defines general operating rules for AI agents working in the codebase, including conventions, workflows, architecture boundaries, testing expectations, and human collaboration.
Planning
Defines how planning should be done, including structure, milestones, execution order, priority rules, progress tracking, and plan updates.
Specifications
Defines how specs should be written, including required sections, acceptance criteria, edge cases, constraints, implementation notes, and validation rules.
Agent style
Gives personality, attitude, and behavioral style to AI agents, including tone, decision posture, collaboration principles, and risk tolerance.
User context
Stores general context about the user, including preferences, background, goals, working constraints, communication expectations, and long-term priorities.
Design system
Defines frontend design principles, component rules, layout patterns, typography, color usage, spacing, interaction states, and UX standards.
Product
Defines what the product is, who it serves, core value proposition, use cases, principles, feature boundaries, and strategic direction.
Company
Defines company-level context, including mission, positioning, operating principles, team structure, culture, business model, and priorities.
Values
Defines the values on which the company, user, product, and codebase should be based.
Ideal customer
Defines target segments, buyer personas, pains, desired outcomes, buying triggers, objections, qualification criteria, and non-fit customers.
Voice
Defines communication style, tone, vocabulary, messaging patterns, banned phrases, examples, and how to sound consistent across channels.
Friction
Documents user, customer, developer, or operational friction points, repeated complaints, blockers, inefficiencies, adoption barriers, and pain to reduce.
Prediction
Captures expected future risks, opportunities, user behaviors, market shifts, technical bottlenecks, and product bets.
Regressions
Tracks known failures, recurring bugs, fragile assumptions, broken flows, previous fixes, test gaps, and regression traps.
Heartbeat
Defines recurring operational status, active priorities, blockers, recent progress, next actions, health checks, and reporting cadence.
Installation
Auto-install chooses between an empty-root install, a standalone agents-fs repository, a docs/ install inside an application repo, or a nested agents-fs/ folder when the current directory is already busy.
Create the full shell directly at the folder root, including root Markdown files, knowledge/INDEX.md, raw tracking files, sources/INDEX.md, facts/, models/, and templates/.
Use a GitHub repository named agents-fs by default for personal, company, or cross-project AFS workspaces.
Install AFS under docs/ so agent memory, source provenance, and knowledge stay separated from app code.
Create a nested agents-fs/ folder when the current directory is already populated but is not an app repo or existing AFS root.
Agents should treat a request to implement the AFS URL as an install request and choose the safest placement automatically.
Personal and company AFS workspaces should normally live in a private GitHub repo named agents-fs unless the user explicitly says not to use GitHub. The current private examples follow that pattern.
Private personal AFS repo using BRAIN.md, knowledge/INDEX.md, raw processing files, sources/, and canonical knowledge pages.
Private company AFS repo using BRAIN.md as the root marker, raw/ as intake, and knowledge/INDEX.md as the maintained navigation surface.
Inspect the current folder and choose root, docs/, or agents-fs/ placement automatically.
npm run afs:createRecord the provided standard or GitHub URL in sources/ and still choose the safest install placement automatically.
npm run afs:create -- https://example.com/afs-standardCreate a personal or company AFS repository named agents-fs and push it to GitHub when gh is authenticated.
npm run afs:create -- --mode standalone --githubCreate the full AFS shell inside docs/ so the application source tree stays separate from agent context.
npm run afs:create -- --mode docsCheck for removed paths, missing recommended shell files, legacy context/ usage, and stale layout names.
npm run afs:validate -- .Move legacy official-documentation/, items/, cookbook/, and domain-first facts into sources/, facts/items/general/, cookbooks/, and the type-first facts layout without overwriting existing material.
npm run afs:migrate -- .Usage
Each harness may have its own instruction or hook format. AFS keeps the durable context and traces in the same portable files.
Paste the Notion template into Custom Agent instructions and point it at the pages or databases that mirror AFS root files and folders.
Keep durable outputs in Notion pages named after AFS files, then periodically export or sync them into the repository.
templates/agent/notion-agent-instructions.mdVISION.mdLOOPS.mdGAPS.mdUse CLAUDE.md to import AGENTS.md, install the use-afs skill, and add the hook example when you want validation around file writes.
Keep scoped Claude rules thin and let the root AFS files define persistent policy.
CLAUDE.md.claude/settings.jsonskills/use-afs/Use AGENTS.md plus the repo-scoped skills/use-afs skill so Codex can route context, sources, and validation consistently.
Add optional Codex hooks for validation before major write operations.
AGENTS.mdskills/use-afs/.codex/hooks/Use AGENTS.md for shared rules and the Cursor .mdc template for editor-local routing to AFS root files and folders.
Keep Cursor-specific UI or codebase rules scoped, while durable facts remain in AFS.
AGENTS.md.cursor/rules/use-afs.mdcUse the OpenClaw template as a bridge skill that points the agent to AFS root files, sources/, logs/, and validation scripts.
Treat the bridge as adapter guidance unless the OpenClaw project adds a native AFS integration.
templates/agent/openclaw-skill.mdAGENTS.mdBRAIN.mdUse the generic AFS operating contract: read root intent first, write trace history into memory folders, and keep external material in sources/.
Attach the AGENTS.md and BRAIN.md templates to Hermes until a native adapter is available.
AGENTS.mdBRAIN.mdsources/Compatibility
Gbrain and QMD compatibility is implemented as best-effort Markdown bridges. They are not represented as official integrations unless their maintainers publish native AFS support.
AFS can expose GBRAIN.md and BRAIN.md as adapter surfaces so Gbrain-style knowledge can point back to portable files and sources.
GBRAIN.mdBRAIN.mdsources/AFS can expose QMD.md as a query and decision bridge that maps QMD-style notes back to specs, plans, knowledge, and source provenance.
QMD.mdGAPS.mdspecs/plans/knowledge/Any harness that can read files and write Markdown can use AFS without a proprietary database or hosted service.
AGENTS.mdVISION.mdGAPS.mdsources/Filesystem reads, keyword search, and semantic retrieval can all use the same folder standard. The filesystem remains the durable source of truth even when an agent adds indexes or embeddings.
Normal folders and Markdown files keep the standard inspectable.
grep, ripgrep, and search indexes can retrieve exact language.
Embeddings and retrieval tools can index AFS while the filesystem remains the source of truth.