Projects and standing instructions

When you find yourself retyping the same instructions in every chat (the same definitions, the same data caveats, the same notes on how a report should read), move them into files the agent reads every time. This page covers where those files live and how the agent uses them. For why this works and which files to write first, see Context engineering.

Projects

A project holds the files for a piece of work and the chats you run on it. Every chat in the project can read the project’s files, so a plan, a schema file or an example report you add once is there for every later chat.

Use one project per body of work, such as a recurring customer experience digest or a churn investigation, so its files and standing instructions stay specific to that work.

Your project’s files

• Your first project is created at sign-up, with the question you wrote as its goal. Open Projects in the app’s left navigation to see it and to start another.
• The File Manager, opened from the message box, shows the project’s files. Open any file there to read it beside the chat.
• Files the agent writes, such as a plan or a working file, go into the project’s files. Finished deliverables go into the Final Reports folder.
• To add a file of your own, such as a plan, a schema file or last month’s report, attach it in a chat and ask the agent to save it to the project. Then every later chat can read it.
• Not sure a file is there? Ask “Which files are in this project?”

AGENTS.md: standing instructions

A file named AGENTS.md at the top of the project is read as a standing instruction in every chat of that project. Think of the agent as a brilliant new analyst with no memory of yesterday: every chat starts cold. AGENTS.md is the brief you hand it each morning so it doesn’t have to relearn your business.

Use it for what’s always true in the project:

• what the company does and who the reader is
• key terms, and which Dimension or column answers which question
• data caveats (“ignore anything before March 2025; the export was incomplete”)
• how outputs should look

Keep it short

Frontier models follow roughly 150 to 200 instructions with reasonable consistency (Writing a good CLAUDE.md, HumanLayer, 2025), and everything in AGENTS.md is read in every chat. Aim well below that: a few dozen clear rules beat a long document, and the longer the file gets, the more any one rule gets lost. Keep only the instructions that are true for every chat in the project. Anything specific to one report belongs in that report’s analysis plan.

Signs the file needs trimming:

• it covers cases that come up in one report only
• nobody remembers why a rule is there
• rules contradict each other

A starting shape

An example of the kind of file that works. Replace each line with your own:

# About this project
We run a subscription meal-kit business. Reports go to the head of customer experience.

# Terms
- "Churn" means a cancelled subscription, not a skipped week.
- Use predicted_csat for satisfaction. Survey CSAT covers too few conversations.

# Data caveats
- Ignore conversations before March 2025; the export was incomplete.

# Outputs
- Lead with the finding, then the evidence.
- Every number gets its date range and the table it came from.

Let the agent maintain it

You don’t need to write or edit AGENTS.md by hand. Ask the agent: “Add a rule to AGENTS.md: churn means a cancelled subscription.” “Remove the rule about the email channel.” “Read AGENTS.md and tell me which rules contradict each other.”

Other useful files

AGENTS.md holds what’s true everywhere. Other files hold what’s true for one job. Context engineering describes each type in full.

File	Holds	Add it when
An analysis plan	The full instructions for a report you’ll run again: objective, fields, join keys, output structure	You’ll repeat an analysis. See Analysis plans.
A failure-modes file	Output habits you don’t want (too many bullets, charts carrying the story)	The output keeps drifting the same way
Report execution guidelines	How a report should look: charts, formatting, output expectations	You want the same presentation every run
A schema file	What your columns and Dimensions mean	The agent misreads a field
An ontology file	Your company’s vocabulary	Your terms are non-obvious or easy to misread. The agent can draft it from your website and past conversations.
A reference report	An example of the output you want	You want a specific shape
A skill	How to do one specific, repeated task	A process is worth packaging for you or your team

Tips

• Name files in your message, in reading order. The agent plans before it looks around, so tell it what to read.
• Show, don’t describe. A worked example of a good output steers the agent more than a paragraph about it.
• Let the agent edit the files. “Change the plan to cover May.” “Remove the section on email.”
• Keep heavy output in files. Ask the agent to write long intermediate summaries to a working file and build the report from it, so the chat stays readable.
• Start a fresh chat to run a finished plan. It keeps planning and running separate.
• Hand work over with a file. Ask the agent for a handoff file that captures what the chat has learned. A colleague attaches it in a new chat and picks up where you left off.

Where outputs land

Finished deliverables are saved in the project’s Final Reports folder, so you can find them among the working files. To share one, publish it to Artifacts from the File Manager, which gives you a link anyone can open and that you can revoke. See Reports, decks and sharing.

Related

• Context engineering: which files to write, in what order, and how to keep them lean
• Analysis plans: build a plan file step by step
• Quick answers and analysis plans
• Reports, decks and sharing