Stop Re-Explaining Your Business to AI

I recently built a private business context folder to help run my own business. It has become the foundation for almost everything I do with AI.

Before it existed, the truth about the business was spread across my head, Notion, websites, repositories, provider dashboards, old strategy documents, and past conversations. An AI could help with one task, but first I had to explain the business again. If I forgot an important detail, it filled the gap with a reasonable guess.

The fix was not one enormous company prompt. I built a small library of context documents with clear jobs. One file explains the brands. Another explains the audience. Another says which system owns which kind of fact. Every file records where its information came from, when it was reviewed, and what is still unsettled.

This guide shows you how to build the same kind of system for your business. You can also give the page to an AI that can read and write files, then ask it to walk you through the build.

What you are actually building

A business context system is a private, agent-readable layer between your raw sources and the work you ask AI to do.

It is not a copy of everything your business has ever produced. It is the smallest useful set of documents that helps an AI answer four questions before it starts:

1. What is true about this business?
2. Which source owns that truth?
3. How fresh is the information?
4. What is still a human decision?

That last question matters. A good context system does not turn uncertainty into confident prose. It makes uncertainty visible.

The finished folder should help an AI load only the files needed for the task. Writing a sales page might require your brand, customer, positioning, and voice context. Reviewing an active project might require priorities, the project record, and the live repository. It should not have to load your entire business history every time.

Why one giant document breaks

The tempting version is a file called everything-about-my-business.md.

It works for a week. Then pricing changes, a project ships, a brand decision is made, and half the document becomes hard to trust. Stable identity, current priorities, legal records, website copy, and experimental ideas all age at different speeds. They should not share one review cycle.

It also creates context bloat. Every time you give the AI the giant file, you use part of its limited working context on details that have nothing to do with the current task. The extra material can bury the instructions that matter, surface unrelated facts, and make it harder for the AI to prioritize the right information. Smaller, purpose-built files let it load only what the job needs.

A useful context system separates three layers:

Your context folder routes the AI to live state. It does not pretend that a Markdown snapshot can replace it.

The rules that make the system trustworthy

1. Give every fact an owner

Different systems own different kinds of truth. Your project manager might own deadlines. Your repository owns code. Your payment provider owns billing state. An executed agreement owns contract terms. Your context folder owns the stable synthesis and the map that tells an AI where to look.

Write this down. Otherwise, the AI will choose whichever copy is easiest to read, even when it is old.

2. Put status and freshness on every document

Use a small status vocabulary:

• canonical: you reviewed and confirmed the document or its governing decisions.
• working-canonical: evidence-backed and safe as the current working position, but not fully confirmed.
• draft: incomplete, exploratory, or waiting on a material decision.
• tracker: a changing operational record that must be refreshed from its live source.
• reference: a pointer to a different canonical resource.

Also include an owner, last-reviewed date, and review cycle. These fields stop a polished old document from masquerading as current truth.

3. Preserve disagreement

When two sources conflict, do not blend them into one smooth answer. Record the exact disagreement, compare dates and authority, and ask the person who owns the decision.

This is especially important for pricing, positioning, customer access, privacy, legal identity, public claims, and project status.

4. Keep sensitive material out

Do not store passwords, API keys, tokens, raw client transcripts, private financial records, or unnecessary personal information in the context folder.

The folder can say that credentials live in a password manager. It should not contain the credentials. It can route an AI to a restricted client source. It should not copy the source into a general business file.

5. Separate existence from state

A product document proves that the product has been discussed. It does not prove that the product is launched. A repository proves that code exists. It does not prove that the code is deployed. A submitted application is not an approval.

Teach the system to use exact lifecycle language. Planned, drafted, built, submitted, deployed, approved, and publicly available are different states.

Start with the minimum useful version

You do not need the full folder on day one. Start with eight files:

business-context/
├── AGENTS.md
├── README.md
├── BUILD-PLAN.md
├── core/
│   └── business-overview.md
├── audience/
│   └── customer-context.md
├── systems/
│   └── source-of-truth-map.md
└── governance/
    ├── source-register.md
    └── changelog.md

Here is the job of each file:

• AGENTS.md tells an AI how to use the folder, what to read for each kind of task, how authority works, and which safety boundaries never change.
• README.md explains the system to a human and shows the folder map.
• BUILD-PLAN.md records what is complete, what is drafted, what is blocked, and what should happen next.
• business-overview.md explains what the business is, who it serves, how it makes money, and which parts are still unsettled.
• customer-context.md captures the specific people, situations, decisions, objections, language, and evidence behind the audience model.
• source-of-truth-map.md says which system owns each kind of fact and what wins when copies disagree.
• source-register.md lists the actual source documents, databases, websites, repositories, and records used to build the context.
• changelog.md records material changes so future sessions can see what moved and why.

That is enough to stop rebuilding the business from zero in every conversation.

Expand when the work demands it

Once the foundation is useful, expand by decision surface. A thorough system may look like this:

business-context/
├── core/
│   ├── owner-or-founder.md
│   ├── brand-architecture.md
│   ├── operating-principles.md
│   └── glossary.md
├── brands/
│   └── one-file-per-brand.md
├── audience/
│   ├── customer-context.md
│   ├── buying-context.md
│   └── customer-language.md
├── strategy/
│   ├── positioning.md
│   ├── competitive-landscape.md
│   ├── messaging-angles.md
│   ├── content-strategy.md
│   └── goals-and-success-metrics.md
├── business/
│   ├── services.md
│   ├── products.md
│   ├── delivery-approach.md
│   ├── business-model.md
│   ├── proof-and-case-studies.md
│   └── priorities.md
├── surfaces/
│   ├── website.md
│   ├── email.md
│   ├── social-channels.md
│   └── sales-and-client-materials.md
├── systems/
│   ├── tools-and-stack.md
│   ├── repositories-and-projects.md
│   ├── workflows-and-automations.md
│   └── source-of-truth-map.md
├── governance/
│   ├── source-register.md
│   ├── decision-log.md
│   ├── changelog.md
│   └── review-schedule.md
└── templates/
    ├── context-document-template.md
    └── decision-entry-template.md

Do not create every file because it appears in the tree. Create a file when it owns a distinct decision surface that your work repeatedly needs. A solo consultant with one brand may need twelve files. A multi-brand business with several products and delivery systems may need thirty.

Use one contract for every context document

Consistency makes the folder easier for both people and AI to maintain. Start each context document with this shape:

---
title: [Document title]
status: draft
owner: [Person responsible for the truth in this file]
last_reviewed: YYYY-MM-DD
review_cycle: [weekly, monthly, quarterly, or event-driven]
---

# [Document title]

## Purpose

[What question this file answers and when an AI should load it.]

## Confirmed

[Facts or decisions supported by the authority order.]

## Working position

[Evidence-backed material that is useful but not fully confirmed.]

## Boundaries

[What this file does not prove, authorize, or contain.]

## Open questions

- [ ] [Decision, conflict, or missing source that still needs a human.]

## Sources

- [Source name, location, owner, and date checked]

Not every document needs every section. The metadata, purpose, boundaries, open questions, and sources should be hard to remove.

Build it in five passes

Pass 1: Inventory the business before writing

List the places where business truth currently lives. Common examples include:

• your own direct decisions and notes;
• project and task systems;
• product or service databases;
• contracts and official registrations;
• websites and sales materials;
• repositories and deployment providers;
• payment, email, CRM, and analytics systems;
• approved client deliverables;
• old strategy documents and transcripts.

For each source, record what it owns, who owns it, how often it changes, how the AI can access it, and what must never be copied.

The inventory will expose a useful truth: you probably do not have one source of truth. You have several sources with different jobs.

Pass 2: Build governance before the story

Create AGENTS.md, the source register, the source-of-truth map, and the build plan before asking the AI to write positioning or customer context.

This feels backward because governance is less exciting. It is also what keeps the exciting documents honest. The AI now knows where evidence should come from, how to label uncertainty, and when it must stop and ask.

Pass 3: Draft in small related groups

Work in batches of two to four documents. Good early batches are:

1. owner, operating principles, and brand architecture;
2. brand, customer, and buying context;
3. positioning, services, and business model;
4. tools, workflows, and source-of-truth boundaries.

Before each batch, have the AI re-read the build plan and re-fetch the exact sources needed for those files. Do not let it finish an incomplete document from memory just because the prose sounds plausible.

Pass 4: Review decisions, not paragraphs

Do not spend your review time line-editing every sentence. Ask the AI to show you:

• facts it treated as confirmed;
• working positions it inferred from evidence;
• conflicts between sources;
• missing decisions that change the result;
• claims that could become public;
• facts that will go stale quickly.

Confirm or correct those items first. Then promote a document from draft to working-canonical or canonical.

Pass 5: Make maintenance part of the system

The folder becomes useful through use, not through one perfect setup session.

Give stable documents a monthly or quarterly review cycle. Refresh priorities and project state weekly or before use. Verify prices, deployments, approvals, legal state, and public availability in their live systems whenever the answer matters.

When a material decision changes, update the owning document and add a short changelog entry. If you keep correcting the AI on the same point, that is a sign the context system needs an update.

The authority order

Write an authority order into AGENTS.md. A practical default is:

1. The owner's current direct instruction or confirmation.
2. A confirmed canonical context document.
3. The live system that owns the fact.
4. A working-canonical context document.
5. A linked source document.
6. Historical notes, transcripts, memory, or inference.

You may swap steps two and three for some facts. Current payment state should come from the payment provider. A durable brand decision may come from the canonical context document. The important thing is to define the boundary instead of making the AI improvise it.

Copy this prompt into your AI

This prompt works best with an AI that can read and write a private folder and, with your permission, inspect the systems where your business information lives. If you are using a chat-only tool, it can still guide the process, but you will need to upload sources and save the files yourself.

You are my Business Context Architect. Help me build a private, maintained set of Markdown documents that future AI assistants can use to understand my business before they work.

We are not creating one giant company prompt, a marketing exercise, or a copy of every source. We are creating a routing and synthesis layer that tells an AI:

1. what is currently true;
2. which source owns each kind of truth;
3. how fresh and confirmed the information is;
4. which questions and decisions still belong to a human; and
5. which small set of files to load for a specific task.

CORE RULES

- Never invent a business fact, price, legal state, customer result, testimonial, biography, priority, deadline, product state, or public claim.
- Distinguish direct confirmation, verified source evidence, working inference, hypothesis, and open question.
- A plan is not built. Built is not deployed. Submitted is not approved. A local file is not public.
- Do not store passwords, API keys, tokens, authentication cookies, raw client transcripts, sensitive financial records, or unnecessary personal information in this folder.
- Use links and routing notes for private or live systems instead of copying their contents into general context.
- Preserve contradictions. Do not silently combine conflicting sources into one polished answer.
- Ask before accessing a new private system. Do not change an external system unless I explicitly authorize that change.
- Work in small batches. Show me material claims, conflicts, and open decisions before calling a document canonical.
- Prefer updating one existing owner document over creating a near-duplicate.

STATUS LABELS

- canonical: I have confirmed the document or its governing decisions.
- working-canonical: evidence-backed and safe as the current working position, but not fully reviewed by me.
- draft: incomplete, exploratory, or waiting on a material decision.
- tracker: a changing operational record that must be refreshed from its live source.
- reference: a pointer to another canonical resource.

FIRST SESSION

1. Ask me, one section at a time, about:
   - the business or businesses in scope;
   - the people responsible for major decisions;
   - brands, products, services, and customer groups;
   - the repeated tasks I want AI to help with;
   - the systems where strategy, projects, code, contracts, customers, content, billing, deployments, and credentials live;
   - privacy, client, legal, and publication boundaries; and
   - the files or systems you can currently access.

2. Do not ask me to narrate information you can verify in an approved source. First propose the sources you want to inspect and why. Wait for permission where access is not already available.

3. Create a source inventory with these fields:
   - source name and location;
   - kind of truth it owns;
   - owner;
   - freshness or review need;
   - access method;
   - sensitivity;
   - what it does not prove.

4. Propose a minimum useful folder structure based on my business. Start with:

   business-context/
   ├── AGENTS.md
   ├── README.md
   ├── BUILD-PLAN.md
   ├── core/business-overview.md
   ├── audience/customer-context.md
   ├── systems/source-of-truth-map.md
   ├── governance/source-register.md
   └── governance/changelog.md

   Add files only when they own a distinct decision surface that my repeated work needs. Explain why each added file deserves to exist.

5. Create the governance files first:
   - AGENTS.md with read order, task routing, authority order, freshness rules, editing rules, and safety boundaries;
   - README.md with the purpose, folder map, document lifecycle, and maintenance rhythm;
   - BUILD-PLAN.md with complete, drafted, not-started, and blocked states;
   - governance/source-register.md;
   - systems/source-of-truth-map.md; and
   - governance/changelog.md.

6. Before drafting business claims, show me:
   - the proposed authority order;
   - the source-of-truth map;
   - any conflicts already visible;
   - any sensitive material that should remain outside the folder; and
   - the first two to four related context documents you recommend building.

DOCUMENT CONTRACT

Every context document should include:

---
title: [Document title]
status: draft
owner: [Human owner]
last_reviewed: YYYY-MM-DD
review_cycle: [weekly, monthly, quarterly, or event-driven]
---

Then include:

- Purpose: the question this file answers and when an AI should load it.
- Confirmed: facts or decisions supported by the authority order.
- Working position: useful evidence-backed material that is not fully confirmed.
- Boundaries: what the file does not prove, authorize, or contain.
- Open questions: unresolved decisions, contradictions, or missing sources.
- Sources: source name, location, owner, and date checked.

Adapt the sections when the document needs a different shape, but preserve provenance, uncertainty, and boundaries.

ONGOING BUILD LOOP

For each small batch:

1. Re-read AGENTS.md, BUILD-PLAN.md, the source register, and the target files.
2. Identify and re-fetch the exact approved sources needed for the batch.
3. Compare current sources with existing Markdown.
4. Draft only evidence-backed content.
5. Put contradictions and missing decisions in Open questions.
6. Show me a review packet containing:
   - confirmed claims;
   - working inferences;
   - conflicts;
   - freshness-sensitive facts;
   - public claims; and
   - decisions you need from me.
7. After my review, update the document status, BUILD-PLAN.md, source register, and changelog.

TASK ROUTING

As the system grows, add a routing table to AGENTS.md. For each repeated task, name the smallest set of context files and live sources an AI should load. Examples include writing about the founder, creating marketing copy, reviewing an offer, working on an active build, checking a public claim, or choosing a tool.

MAINTENANCE

- Refresh current priorities and project state at least weekly or before consequential use.
- Verify pricing, product lifecycle, deployment, approval, billing, legal state, and public availability in the live owning system each time the answer matters.
- Review stable identity, brand, audience, and positioning monthly or after a material decision.
- Record meaningful changes in the changelog.
- If I repeatedly correct the same output, propose the smallest context update that would prevent the mistake.

Do not create files yet. Start by asking me the first small group of questions needed to define scope, repeated tasks, and source systems. Ask no more than five questions at a time.

A good first test

Do not judge the folder by how complete it looks. Give the AI a real task that used to require a long explanation.

Ask it to name the context files it loaded, the live sources it checked, the facts it treated as confirmed, and the decisions it left with you. Then inspect the result.

The test is not whether the AI sounds like it understands your business. The test is whether you can see why it made each important call, correct the source once, and make the next piece of work better without repeating yourself.

That is when context stops being another document and starts becoming part of how the business runs.