AI Context Document: A Template for Clear Project Briefs

An AI context document is a short, maintained project brief that tells an assistant what you are trying to achieve, which rules apply, what evidence to use, and where to start. It gives a new session enough information to continue the work without treating your entire chat history as the instructions.

You can keep the first version in a plain document. When decisions and progress change often, fenbs can maintain that work record outside the conversation so you can build the next brief from current information. The document is useful only when somebody checks that its contents still match the project.

What should the document include?

Include the facts that change the next action: the goal, the boundary of the task, agreed rules, useful sources, approved decisions, current state, and the next step. Explain any project term that an outsider could misunderstand. Put questions beside the person who can answer them rather than quietly filling in an answer.

Anthropic recommends organizing instructions into distinct sections and using clear boundaries between them in its prompting guidance↗ (opens in a new tab). You do not need a special file format to apply that idea. Consistent labels make it easier to inspect the record and notice a missing constraint.

• Goal: the outcome someone will review, with a practical definition of finished.
• Scope: what this session may change and what needs a separate request.
• Rules and decisions: instructions people approved, with their scope and reason.
• Sources: the current documents, files, or links that support the work.
• State and next step: what is complete, what was checked, what is uncertain, and the next action.

The wider context engineering guides explain how that brief fits alongside tools and source material. The document itself should remain easy for a person to review before an assistant acts.

Which template can you copy?

Copy the structure below, then replace every bracket with a concrete statement or an explicit unknown. Do not leave a section that sounds finished when it is still waiting for approval. A small complete brief is more useful than a polished form with ambiguous answers.

PROJECT: [name]
OWNER AND LAST REVIEW: [person; date]

GOAL
[Deliverable and how it will be reviewed]

THIS SESSION
[One task; allowed changes; stop conditions]

RULES
[Approved standing instructions and their scope]

DECISIONS
[Chosen approach; who chose it; reason; current status]

SOURCES
[Location; relevant section; version or review date]

CURRENT STATE
Completed: [verified work]
Checked: [check and result]
Uncertain: [what has not been confirmed]
Waiting on: [person and question]

NEXT STEP
[First action and the evidence needed]

OUTPUT
[Required format; what to report when stopping]

Keep the session task separate from the project goal. A project might be to improve a help center, while today’s task is to draft the billing article. If those become one vague instruction, the assistant may revise unrelated material or assume it should solve every outstanding problem.

An AI context capsule usually means a smaller package of the same essential facts. There is no universal capsule format: define the fields your team uses and make the contents understandable without the name. If you need to shorten an existing conversation, use the separate AI context compression guide.

What does a filled example look like?

Say a small design studio is rewriting a client onboarding guide. Its brief could state that the deliverable is a draft for an account manager to approve, the audience is first-time clients, and the source is the current onboarding checklist. It should also state whether the assistant can edit the live guide or only prepare proposed text.

• Goal: prepare a clear onboarding draft that matches the approved service.
• Rule: do not promise a delivery date that the account manager has not approved.
• Decision: the client chose a single contact person; explain the process around that choice.
• Current state: welcome section drafted; support contact confirmed; delivery wording still unapproved.
• Next step: rewrite the required-files section using the checklist, then flag any missing requirement.

That example deliberately distinguishes a confirmed contact from an unapproved promise. The assistant can draft around the known facts and leave a question where the evidence ends. It also gives the reviewer something specific to check instead of asking whether the whole conversation feels right.

A brief used by an assistant that can take actions needs especially clear scope; see context engineering for AI agents. fenbs can keep those approved decisions beside the active tasks through its shared work record.

How do you keep sources and instructions distinct?

Label a source as evidence to consult, rather than presenting every sentence inside it as an instruction. A customer email can show what somebody requested without giving the assistant permission to change the project. Ask the assistant to report conflicts between the source and an approved rule before it chooses an answer.

Give sources useful locations: a file path and heading, a document title and section, or a direct link. Anthropic describes using lightweight references to retrieve information when needed in its context engineering article↗ (opens in a new tab). This supports a brief that points to evidence without copying an entire archive.

Check that the assistant can actually access each source. A link in the document is not evidence that it was opened. Ask it to name the sources it used and identify anything unavailable. Keep sensitive material in the approved location and provide only the information the task needs.

How do you stop your document becoming stale?

Update it when a decision, check result, or next step changes. Review the current-state section before starting a new session. Keep the outcome of a failed check as carefully as a successful one: “draft reviewed for terminology; service commitments not approved” gives the next person a reliable boundary.

Replace obsolete instructions with the current answer and preserve the reason for the change in its proper record. Do not keep adding corrections to the bottom until the reader must reconstruct the truth. Our guide to AI context rot covers why growing context can become harder to use.

How to do this with fenbs

1. Create a free account and add the project on your kanban board. Write its goal and the outcome a person will review.
2. Add the active tasks with their plans and current state. Record a person’s approved choices in Decisions and rules, and put unresolved choices into open questions.
3. Follow Integrations to connect a supported AI app over MCP, a standard way for an assistant to use an outside tool. Ask it to read the project context first.
4. Use the template to check its starting brief, then have it save progress with completed work, actual check results, uncertainties, and the next step.

fenbs is useful when your document describes changing work shared across sessions. It does not import your chat history or replace a document editor for long reference documents. For a one-time question with no continuing project, a short document and the necessary sources may be enough.

How can you test whether the document works?

Give the document to a fresh session and ask for the goal, the rules that constrain the task, the first action, and the questions that require a person. Compare the answer with the actual project. If it invents an approval or cannot identify the source, revise the relevant field and try again.

Then inspect one small piece of work produced from it. A good restatement does not prove the assistant will follow every constraint. Check the result against the named evidence and update your document when a misunderstanding reveals a missing fact. The goal is a dependable start, followed by ordinary review.