How to Structure AI Projects With PARA

Keep Forte's four roles and do not rename them around a particular AI tool. What matters is that every folder has exactly one role, not that all four folders exist on day one.

workspace/
├── Projects/
├── Areas/
├── Resources/
└── Archives/

Projects contain finite work. Areas contain standing responsibilities. Resources contain reference material. Archives hold completed or inactive material from the other three categories.

Create Areas/ and Projects/ when the first real work needs them. Add Resources/ when the first reference material arrives, and Archives/ when the first Project finishes. An empty Archives folder tells an agent nothing.

Think of a four-room workshop: the active workbench, the standing operating rooms, the reference library, and labelled storage. The rooms clarify intent, although filesystem access controls still enforce security.

Do not build the complete tree on day one. Forte's method is designed to remain simple enough to maintain, and the same test applies to an agent workspace.

Areas/content-operations/
├── AGENTS.md
└── editorial-rules.md

The instructions file routes the agent. The working file owns the current rules. Add another file only when repeated use proves that it has a separate job and a clear owner.

A large empty hierarchy creates apparent order without improving the next task. It also gives stale material more places to hide.

The instructions file is a router, not a handbook. It should point to authority and define boundaries.

• Which files are authoritative?
• What may the agent read?
• What may it update?
• When must it stop and ask a person?

A useful router might say: read editorial-rules.md before drafting; treat decision-log.md as append-only; read Resources/research/ without editing it; place finite production work in Projects/; stop before publishing, sending, deleting, or changing an approved rule.

This follows the same principle as Set Up Implementation Rules: boundaries should be visible before execution starts.

A router states intent; it does not enforce it. Anthropic's documentation says Claude treats instruction files as context, not enforced configuration, and points to a PreToolUse hook when an action must be blocked regardless. Write the stop rule in the router, and enforce the ones that must never fail in the tool's settings.

The dangerous copy is often not the missing one. It is the old one that still looks official.

Give each material fact exactly one owner file. Other files should link to that owner instead of copying its contents.

If editorial-rules.md owns approved spelling rules, a Project brief can point to it. The brief should not repeat the list. When a rule changes, there is one place to update and one reason to review.

Apply this rule to instructions, statuses, dates, requirements, and definitions. A link is cheaper to maintain than a second source of truth. For a website repository, The AGENTS.md Book: Source of Truth and Read Order applies the same rule file by file.

Current rules tell an agent what to do. A decision log records why the rule exists.

Keep each entry small: date, decision, reason, and affected files. For example: Resources are read-only by default because source material must remain distinct from working interpretations.

The log prevents a future person or agent from removing a rule whose purpose is no longer obvious. It also makes disagreements easier to resolve because the reason sits beside the decision.

This is how finished work becomes reusable memory instead of forgotten output. The same principle appears in How to Turn Finished Projects Into a Reusable Knowledge System.

An Area continues. A Project must end.

Projects/website-refresh/
├── brief.md
├── status.md
└── acceptance-checks.md

The Project links to Area rules rather than copying them. brief.md owns the requested outcome. status.md owns the current state. acceptance-checks.md defines what done means.

When the checks pass, record the result and move the folder into Archives. Leaving completed work among active Projects forces every future agent to decide whether an apparently active folder is dead.

Resources may include source documents, research, examples, product manuals, or reference code. They can inform active work without owning its decisions.

Set the default permission: the agent may read Resources but may not rewrite them unless the task explicitly authorises a change.

When research produces a conclusion, put that conclusion in the Project or Area file that owns the decision. Keep the source intact and link back to it.

Folder clarity is not access control. A folder called Private inside a public repository is still public.

GitHub's repository documentation states that public repositories are accessible to everyone. Personal material should remain on the local machine and must never enter a public remote.

A private remote still needs suitable access controls and review. When local-only storage is required, state that boundary in the Area instructions and exclude the path from version control.

The durable layer is the folder shape, ownership model, and permission rules. The instruction filename is an adapter.

OpenAI's Codex workflow guidance describes AGENTS.md as persistent repository guidance. Anthropic's Claude Code documentation documents CLAUDE.md, nested instructions, and current AGENTS.md support with version and configuration conditions.

Keep one shared source where practical, then add the smallest compatibility file required by the installed tool. One trap is worth knowing: by default, Claude Code reads AGENTS.md only when no CLAUDE.md exists in the working directory or above it. If both files exist, it reads CLAUDE.md only, so a shared AGENTS.md should be imported from CLAUDE.md rather than assumed.

Check current product documentation before relying on a particular filename or loading rule.

Claude Code may change. Codex may change. Another agent may replace both. Projects, Areas, Resources, Archives, owner files, and explicit permissions remain understandable.

Run a real task through the workspace before adding more structure. Ask the agent to identify the active Project, applicable Area rules, readable Resources, writable files, stop conditions, completion test, and archive destination.

If it cannot answer from the files, improve the router or ownership links. Do not add another layer until the failure shows what is missing.

The goal is not a perfect directory tree. It is a small system that makes the next action, authority, and boundary obvious.