The gap between knowing you need AI Foundations and knowing what to actually put in them is where most founders stall.
The context pack gets started, runs out of steam in the voice guide section, and ends up as a half-finished document that helps marginally but does not produce the output quality leap it should.
This article closes that gap. Each document section below describes specifically what to write, why it matters, and what “complete” looks like; so the build produces AI Foundations that actually work.
This article is for founders who are building. If you are still deciding whether to build AI Foundations, the prior article in this series makes the case. If you have already decided and want the specific content guide, you are in the right place.
Document 1: The context pack
Section 1.1: Company description (250–400 words)
What to write: a factual, specific account of what the company does, who it serves, what it has built, and what it stands for. Written as the first five minutes of an excellent new hire orientation; not marketing copy, not an investor pitch.
The specificity test: after reading this section, can an AI accurately answer “what does this company do and who are its ideal clients?” with specific enough detail that the description would not apply to any other company in the category?
Common failure modes:
- Too general: “a consulting firm that helps companies grow”; applies to thousands of firms
- Too aspirational: “a pioneering force in AI strategy”; means nothing to an AI
- Missing the client descriptor: failing to name the specific revenue range, industry, or company type the firm works with
What the complete version contains:
- What the company does (the service or product, in plain, specific language)
- Who it serves (the specific buyer role, company size, industry, and situation)
- What the engagement produces (the specific outcomes clients achieve)
- What makes the company different (two to three specific, honest differentiators; not category-level claims)
- Brief proof: one or two specific results or client contexts that demonstrate the capability
Section 1.2: Client archetypes (100–150 words each; two to four archetypes)
What to write: a specific description of the two to four most common client types the company works with best; not market segments, but specific role-and-situation portraits.
The specificity test: can an AI reading this archetype write a proposal opening paragraph that would resonate specifically with this client type; not generically with “mid-market businesses”?
Common failure modes:
- Role only, no situation: “COO at a $20M company”; not enough; COOs vary enormously by situation
- Generic concerns: “wants to grow revenue”; every buyer wants this
- Missing the trigger: what specifically brought this person to the conversation right now?
What each complete archetype contains:
- Role, industry, company size range (specific)
- Current AI situation (where they are on the maturity curve; what they have tried that has not worked)
- The trigger that brought them to this conversation
- Their primary concern going into the first conversation
- How they communicate (direct vs. indirect, formal vs. casual, data-driven vs. intuitive)
- What a successful outcome looks like for them specifically
- One or two things they will say in a first conversation that signal good fit
Section 1.3: Competitive positioning (200–350 words)
What to write: how the company honestly describes its position relative to the alternatives its clients would consider.
The specificity test: can an AI write a proposal differentiation paragraph that makes an honest, specific case for why this company is the right choice; without using the generic claims that every competitor also makes?
Common failure modes:
- Using claims every competitor makes: “experienced team,” “client-focused,” “proven results”
- Avoiding the comparison: describing the company without acknowledging what the alternatives are
- Overclaiming: differentiators that are not true or not defensible
What the complete version contains:
- The alternatives the company is most commonly compared to (advisory-only firms, DIY AI tools, in-house hires, larger consulting firms)
- The one or two things the company does that these alternatives consistently fail to provide
- What the company explicitly does not do or claim
- The specific situation in which the company is the right choice
Document 2: The voice guide
Section 2.1: Tone description (100–150 words)
What to write: a description of the register the company uses; not abstract values (“professional,” “approachable”) but operational descriptions.
The specificity test: could a person who has never read any of the company’s communications use this description to produce something that sounds like the company?
What the complete version contains:
- The primary register (peer-to-peer, authoritative, collaborative, direct)
- How it varies by context (client emails vs. proposals vs. internal communications vs. LinkedIn)
- Two or three “sounds like us” descriptors that are specific; for example: “direct enough to give a clear recommendation rather than listing options, but never abrupt; we always acknowledge the difficulty before making the recommendation”
Section 2.2: Vocabulary guide
Format:
We use:
- [Word or phrase]: [why / context in which it is used]
(Aim for 10–20 items)
We avoid:
- [Word or phrase]: [why / what we use instead]
(Aim for 10–20 items)
Most valuable items in the “we avoid” list:
- Clichés the industry overuses (“transform,” “revolutionary,” “holistic”)
- Vague intensifiers (“very,” “really,” “quite”)
- Structural patterns the company consistently edits out (opening every email with a pleasantry, ending every section with “in conclusion”)
Section 2.3: Format standards by output type
What to write: for each of the four to six most common output types the company produces, the specific format standards that distinguish a good output from a mediocre one.
Format:
[OUTPUT TYPE — e.g., Client proposal]:
Opening: [what the opening should accomplish and how long it should be]
Structure: [the sections in order, with what each one contains]
Length: [word count range]
Closing: [how this output type ends — what the next step looks like]
What to avoid: [the most common format errors for this type]Output types to cover: client proposals, client email (standard), client email (sensitive or difficult), LinkedIn posts, internal documents, service descriptions.
Section 2.4: Examples (three to four outputs)
What to include: three to four existing outputs that represent the company’s voice at its best. A proposal introduction. A client update email. A LinkedIn post. Annotated with one or two sentences explaining what makes each one representative.
Why examples matter more than descriptions:
Abstract tone descriptions require interpretation. Concrete examples provide calibration. The AI that has read three annotated examples of the company’s voice produces more accurate outputs than one that has only read the description.
What not to include: outputs that are technically fine but not representative of the voice at its best. An average output as an example teaches the AI to produce average.
Document 3: Operating rules
What operating rules are
Operating rules are the documented decision logic for the scenarios the AI encounters most frequently; the judgment calls that recur often enough to document and that currently live in the founder’s head.
They are written as explicit “when X happens, we do Y” statements; not narrative explanations.
Why operating rules are the hardest document to build:
They require the founder to articulate decisions that are usually made intuitively.
“When a client asks for a discount, what do we do?” seems like a simple question until the founder realises they do different things depending on the client tier, the deal size, the relationship stage, and the specific circumstance.
Documenting the rule requires making the implicit logic explicit. That is the work.
Section 3.1: Commercial rules (eight to twelve rules)
What to write: the specific decision logic for pricing, discounts, payment terms, scope changes, and contract terms.
Rule format:
SCENARIO: Client requests a discount on a standard engagement
STANDARD POSITION: We do not discount standard engagements in the first conversation.
WHEN WE FLEX: For existing retainer clients requesting a new engagement, a 10% discount
is at the account lead's discretion.
ESCALATION THRESHOLD: Any discount above 15% requires founder approval.
WHAT WE SAY: "Our pricing reflects the engagement model — we'd rather adjust the scope
to fit the budget than discount the engagement and end up under-resourced."Rules to include in this section:
- Discount request response
- Payment terms standards and exceptions
- Scope change pricing and approval
- Retainer renewal pricing logic
- Early termination handling
- Referral and partnership arrangement standards
Section 3.2: Client communication rules (six to ten rules)
What to write: the specific standards for how the company communicates in different scenarios.
Rules to include:
- How project status is communicated (frequency, format, who sends it)
- How the company handles a client complaint or escalation (response time, tone, escalation path)
- How the company communicates bad news (deliverable delay, budget overrun, quality issue)
- How the company handles a client who is dissatisfied before a formal complaint
- What the company does when a project is going significantly better than expected
Section 3.3: Escalation and exception rules (four to eight rules)
What to write: the specific situations that require escalation to the founder or a senior team member.
Rules to include:
- What client situations require the founder’s direct involvement
- What commercial decisions require founder approval
- What communications require founder review before sending
- When to escalate a difficult client situation rather than continuing to manage it at the account level
Section 3.4: AI-specific rules (three to five rules)
What to write: the specific guidance for how the AI system should behave in edge cases.
Rules to include:
- What situations should never be drafted by AI without human-written content (termination of an engagement, response to a formal complaint, pricing proposal for a non-standard engagement above a specific value)
- What types of communications should always be reviewed by a senior team member before sending; regardless of AI quality
- What the AI should do when it does not have the information needed to produce a good output (flag; not guess)
Document 4: Workflow documentation
What a workflow document is
A workflow document is the complete specification for one AI-assisted recurring task; the instruction set that allows any team member (or an automation) to run the task at company quality.
The workflow document format:
WORKFLOW NAME: [Descriptive name that identifies the task and output]
PURPOSE: [One sentence — what this workflow produces and why it matters]
FREQUENCY: [How often this workflow is run — daily, weekly, per client interaction]
OWNER: [Which role runs this workflow]
INPUTS REQUIRED:
- [Input 1]: [Description of what is needed and where to get it]
- [Input 2]: [Description]
CONTEXT TO LOAD:
- [Which sections of the context pack are needed for this workflow]
- [Any workflow-specific context that supplements the standard context pack]
PROMPT STRUCTURE:
[The exact prompt text, with [PLACEHOLDERS] for variable inputs]
EXPECTED OUTPUT:
- Format: [the structure of the output — headers, sections, length]
- Length: [word count range]
- Tone: [any workflow-specific tone calibration beyond the standard voice guide]
QUALITY BAR:
An acceptable output: [specific description of what a good output looks like]
An output that should be re-run: [specific description of what signals rework is needed]
HUMAN CHECKPOINT:
Before use, this output is reviewed by: [specific role]
Review focus: [what the reviewer is checking — tone, facts, completeness, format]
KNOWN EDGE CASES:
- [Edge case 1]: [how to handle it]
- [Edge case 2]: [how to handle it]
LAST UPDATED: [date]
OWNER: [who maintains this document]The five workflows to document first
Build workflow documentation for the five highest-frequency, highest-value AI-assisted tasks first. For most $5M–$25M companies:
| Priority | Workflow | Roles it serves |
|---|---|---|
| 1 | Client proposal first draft | Account manager, sales |
| 2 | Client status update (weekly or per-milestone) | Project manager |
| 3 | Follow-up email after a sales or discovery call | Account manager, founder |
| 4 | Meeting summary and action item extraction | All roles |
| 5 | Weekly operational or pipeline summary | Ops manager, founder |
Once these five are documented and proven, the workflow library expands to cover finance, support, HR, and marketing functions.
The completeness test for workflow documentation
Give the workflow document to a team member who has not been involved in building it. Ask them to run the workflow on a real current task without any guidance beyond the document.
- If the output is acceptable without the builder’s involvement: the document is complete.
- If the team member has questions the document does not answer: those gaps must be filled before the workflow is deployed at scale.
The most commonly missed elements: and how to catch the gaps
Most commonly missed in the context pack:
- The specific revenue range of the ideal client (founders often write “mid-market” without specifying the number)
- The trigger that brings the ideal client to the conversation (what event or pressure precipitated their search)
- Specific outcomes produced for clients; not “improved efficiency” but “250% increase in leads” or “45% reduction in document retrieval time”
Most commonly missed in the voice guide:
- The vocabulary guide (most founders write the tone description and skip the word-level specificity)
- Format standards for difficult communications; the template for a client complaint response or a bad news email
- The “avoid these patterns” list; which is often more valuable than describing what to do
Most commonly missed in operating rules:
- The escalation thresholds (founders document standard positions but not the point at which the standard position gets overridden)
- AI-specific rules; when the AI should flag rather than generate
- What to say (the specific language); not just what to do (the decision)
Most commonly missed in workflow documentation:
- The quality bar section; what a good output looks like versus one that needs rework
- The edge cases; the inputs the workflow was not designed for and that should be handled differently
- The context to load; which specific sections of the context pack are relevant to this workflow (not “load the context pack”; but which parts and why)
Common questions on building AI foundations documents
”How often should each document be updated?”
| Document | Update trigger |
|---|---|
| Company identity | When services, positioning, or client base changes significantly |
| Client archetypes | When a new client type becomes common, or when an existing archetype description is no longer producing accurate outputs |
| Voice guide | Rarely; unless brand positioning changes substantially |
| Operating rules | When pricing, policy, or decision protocols change |
| Workflow documentation | When acceptance rate drops below 75%, or when the workflow prompt is improved based on usage data |
Formal quarterly review of the entire foundation set catches slow drift that event-triggered updates miss.
”Can I use AI to help write my context pack?”
Yes; with one important caveat. The AI is good at formatting, structuring, and expanding on content the founder has already expressed. It is not good at generating the strategic content itself.
The right workflow: the founder dictates or writes rough notes on each section; the AI structures and expands them; the founder reviews and edits for accuracy. The raw judgment must come from the human who holds it.
”Should the context pack be one document or multiple?”
For most $5M–$25M companies: one document, in sections. This makes it easier to load into a Claude Project as a single knowledge file and easier to maintain as a single source of truth.
Split into multiple documents when: the company has distinct product or service lines with sufficiently different audiences that loading the full document creates context noise.
”How detailed do the operating rules need to be?”
Detailed enough that the AI cannot get the answer wrong. A rule that says “we handle scope changes flexibly” is not a rule; it is an intention.
A rule that says: “Scope changes below $500: account lead discretion. Scope changes $500–$5,000: quote at standard rates, offer 10% discount for retainer clients. Scope changes above $5,000: escalate to the founder before quoting.” That is a rule the AI can apply.
”What if my company does not have clear client archetypes yet?”
Build the archetypes from the clients you have worked with best; not from an abstract ideal client profile.
The question to answer for each archetype: “Which of our past clients would we clone if we could?” Use those clients as the basis for the archetype description. Imperfect archetypes that reflect real clients are more useful than perfect archetypes that reflect nobody.
”Is there a template I can use to start?”
The document formats in each section above are the templates. Copy the structure, answer each field for the company, and the document is in the right format.
The hardest part is not the format; it is the content. The vocabulary guide requires examining habits of language. The operating rules require systematising intuitive judgment. The client archetypes require describing real people specifically. Those sections take time because the thinking is genuinely hard.
Want the foundations built completely: not approximately?
AI Foundations documents work when they are complete, specific, and current.
The gaps that most degrade them are not laziness.
They are the sections that are genuinely hard to write: the decision rules that require systematising intuitive judgment, the vocabulary guide that requires examining habits of language, the workflow quality bar that requires naming what “good enough” actually means.
The completeness tests in each section above give a specific check rather than a subjective estimate of readiness.
When each test passes, the foundations are working; and every AI output that follows reflects it.
Path one: start with Document 1, Section 1.1. Write the company description using the specificity test above. Load it into a Claude Project. Run the before/after test on one AI task. If the output is more specific, the context is working. If it is still generic, the description needs more specificity; go back and name the specific client type, the specific outcomes, and the specific differentiators.
Path two: bring in a partner. If you want all four documents built through a structured collaborative process; Phos AI Labs produces the initial drafts through structured interviews with the founder, then tests them against real work before handover. The fastest way to know if it is the right fit is a conversation. We have run 400+ AI engagements. Clients include Zapier, Coca-Cola, Medtronic, Dataiku, and American Express. Thirty minutes, no deck. Start here.