# Compound Context for AI Marketing Workflows: Encode Once, Reuse Safely

- Source: https://simeoncreatives.com/blog/compound-context-for-ai-marketing-workflows
- Hub: AI & Business Automation
- Author: Simeon Matheka, Founder & Creative Director
- Published: 2026-10-01
- Updated: 2026-10-01
- Reading time: 14 min

Every new prompt that starts with “you are a marketing expert” re-invents your positioning and forgets your limits. Write one context pack, version it, and let every workflow read the same approved facts.

You built a workflow that drafts social posts. Then another that writes first-reply emails. Then one that summarizes a competitor page. Each prompt describes the company in slightly different words, and two of them quietly promise a turnaround time you stopped offering in spring. Nobody did anything wrong. The context just lives in five places, and every copy drifts.

The fix is not a smarter model. It is one reviewed document that every workflow reads. If you have not picked which jobs deserve automation yet, start with [which business processes to automate with AI](https://simeoncreatives.com/blog/which-business-processes-to-automate-with-ai). Come back here once you have a job that will run more than once.

## What “compound” means here

Compound context is a simple idea. You encode a fact once, in one place, and every workflow that needs it inherits it. When the fact changes, you edit one file and every job gets the update on its next run. A new workflow starts with your positioning already loaded instead of a blank prompt.

The compounding goes both ways. A wrong claim in the pack is also copied everywhere. That is why the pack is small, owned by one person, and edited through review. Reuse without review is how a typo becomes a policy.

```mermaid
flowchart TD
    A["Context pack v3"] --> B["Social draft job"]
    A --> C["Email reply job"]
    A --> D["Competitor summary job"]
    B --> E{"Claims check"}
    C --> E
    D --> E
    E -->|Pass| F["Human review queue"]
    E -->|Fail| G["Rejected, logged"]
    H["Owner edits pack"] --> A
```

> Framework: the pack is read-only to every workflow. Only a named owner edits it, and every edit gets a version number and a date.

## The six sections of a marketing context pack

Keep each section short and checkable. A model can follow a clear rule. It cannot follow a mood.

| Section | What goes in it | What goes wrong without it |
| --- | --- | --- |
| Positioning | One sentence: who you serve, what you do, why you over the alternative. Plus the three things you are not. | Drafts drift into generic “full-service” language and promise work you do not sell. |
| Voice | Five rules with a good and bad example each. Banned words. Sentence length range. | Every channel sounds like a different company, or like every other company. |
| Ideal customer profile (ICP) | Industry, size, trigger event, who signs. Plus who you decline. | Outreach and replies chase leads you cannot serve. |
| Claims allowed | Statements you can defend today, each with a proof source and a review date. | Old claims survive after the work or the offer changed. |
| Claims forbidden | Prices, guarantees, rankings, client names, results, and comparisons you will not make in generated copy. | The model fills a gap with a confident invention. |
| Proof sources | Where the evidence lives: URL, document, owner. No pasted screenshots in the pack itself. | Nobody can check a claim, so reviewers either guess or approve blind. |

## Write the claims lists first

Teams start with voice because it is fun. Start with claims. A voice mistake is awkward. A claim mistake is a complaint, a refund, or a regulator’s email.

- **Allowed claims: **Write each as a full sentence with a proof pointer and a “verified on” date. Example format: “We build static marketing sites on Cloudflare. Proof: /work. Verified 2026-10-01.” If you cannot point at proof, it goes in the forbidden list until you can.
- **Forbidden claims: **Be blunt. No invented prices. No “guaranteed” anything. No named clients unless the contract allows it. No “best,” “leading,” or ranked comparisons. No result numbers that are not on a page you control.
- **Gray claims: **Anything that needs a person to decide in context, such as a comparison with a named competitor. These do not belong to the model. They route to a human with the draft attached.

The claims check in the diagram does not have to be clever. A deterministic step can scan a draft for forbidden terms, dollar signs, and percent signs, and reject on a hit. Cheap rules catch the loud failures. Humans catch the subtle ones.

## Store it so a workflow can read it

The format matters less than three properties: it is versioned, it is readable by a person, and a workflow can fetch the current version by a stable name. A file in a git repository, a Notion page exported on a schedule, or a single sheet tab all work. What fails is “the doc in someone’s Drive that we copy-paste on Mondays.”

#### Pack header

```yaml
# marketing-context-pack
pack_version: 3
owner: "Simeon"          # one named person
reviewed_on: "2026-10-01"
next_review: "2026-12-01"

positioning: "We design and build brand and web for small B2B firms."
not_for: ["enterprise procurement", "logo-only jobs"]

claims_allowed:
  - text: "We build static sites hosted on Cloudflare."
    proof: "/work"
    verified: "2026-10-01"

claims_forbidden:
  - "any price or discount"
  - "guaranteed rankings or leads"
  - "client names not listed on /work"
```

#### Prompt wrapper

```text
System:
You draft marketing copy. You do not publish.
Use ONLY the context pack below. If a needed fact is missing,
output NEEDS_FACT and name the missing field. Never invent one.

Context pack (version {{pack_version}}):
{{pack_text}}

Task:
{{task}}
```

*Hypothetical pack header. Workflows log pack_version with every run so you can tell which rules produced which draft.*

Notice the NEEDS_FACT escape hatch. A model asked to always produce copy will invent the missing fact. Give it a legal way to say “I do not know,” and make that output a normal result your workflow handles.

## Reuse safely: the loading rules

Shared context is power, so it needs limits. These rules keep one bad edit from spreading quietly.

1. **Read-only for workflows: **No job writes back to the pack. A model that can edit its own rules will eventually edit them.
2. **Pin the version per run: **Log the pack version with every output. When a draft goes wrong, you can see which rules were live.
3. **Scope by job: **The email job does not need the competitor notes. Pass only the sections the job uses. Less context means fewer places for a stray instruction to hide.
4. **Treat retrieved text as untrusted: **If a workflow pulls a web page or a customer email into the same prompt, that text can carry instructions. The Open Worldwide Application Security Project (OWASP) lists this as prompt injection, where inputs alter model behavior even when a human cannot see them. Keep pack text and fetched text in clearly separated sections, and do not let fetched text change the pack.
5. **Review edits like code: **A pack change goes through the same approval as a prompt change. See change control for prompts and workflows.

Sourced: [OWASP LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) (checked 1 October 2026). The process side is in [prompt and workflow change control](https://simeoncreatives.com/blog/prompt-and-workflow-change-control).

## Which jobs should read the pack, and which should not

| Job | Reads the pack? | Why |
| --- | --- | --- |
| Draft a social post from a blog URL | Yes, positioning + voice + claims | Needs tone and limits. A person still approves. |
| Draft a first reply to a form lead | Yes, plus ICP and offer lines | Must not invent an offer. See the human-in-the-loop (HITL) guide for the queue. |
| Summarize a competitor’s pricing page | Only forbidden claims and ICP | The job reports what the page says. It does not need your voice. |
| Route a lead by country or budget band | No. Use a rule. | A closed table does not need a model. See the deterministic guide. |
| Send the monthly invoice reminder | No. Use a template. | Money copy should not vary by run. |

If a job is a lookup, keep it out of the model entirely. [Deterministic workflows vs LLM agents](https://simeoncreatives.com/blog/deterministic-workflows-vs-llm-agents) draws that line, and the human-approval pattern for the rest is [human-in-the-loop review for n8n and LLM jobs](https://simeoncreatives.com/blog/human-in-the-loop-n8n-llm-jobs).

## Filled hypothetical: a four-person studio

Hypothetical, not a client. A studio runs three drafting jobs: weekly social posts, first-reply emails, and a monthly newsletter intro. Each has its own prompt. An audit finds two different “typical timeline” sentences, one that says “two weeks” and one that says “four to six weeks,” and neither matches the current offer page.

The fix takes an afternoon. The owner writes a one-page pack. “Timelines” moves to the forbidden list, because the honest answer depends on scope. Each job swaps its private description for the pack and adds NEEDS_FACT handling. The next draft that mentions a timeline now comes back as NEEDS_FACT, and a person fills the gap from the real quote. That is a better outcome than a fluent wrong number. It is also slower on that one sentence, and that is the trade.

## Failure modes to plan for

- **Pack bloat: **Everyone adds a rule after an incident and none get removed. Set a review date and delete anything nobody can justify.
- **Stale proof: **A claim outlives the evidence. Every allowed claim carries a verified date. Past the next review, it drops to gray until someone rechecks.
- **Voice flattening: **Strict rules can make every draft sound the same. Keep the voice section to a few rules with real examples, and let a human edit the final line.
- **False safety: **A good pack reduces bad drafts. It does not remove the need for review on anything that reaches a customer. A fluent draft is not permission to send.

## What this does not prove

A shared pack makes your outputs more consistent. It does not make them accurate on its own, and it does not show that AI marketing drafts perform better than your current copy. Test the drafts against a golden set before you connect any send. The method for that is in the evaluation guide.

Download the blank [marketing context pack template](https://simeoncreatives.com/resources/marketing-context-pack) and fill one page. Then pressure-test it with [evaluate an AI workflow before production](https://simeoncreatives.com/blog/evaluate-ai-workflow-before-production). If you want a second reader on the claims list before it goes live, [send it over](https://simeoncreatives.com/contact).

## FAQs

### What is a context pack?

A short, versioned document that holds the facts every marketing workflow is allowed to use: positioning, voice rules, ideal customer profile (ICP), claims you may make, claims you may not make, and where proof lives. It is the single source your large language model (LLM) prompts read from, instead of each prompt carrying its own half-remembered copy.

### Is this the same as fine-tuning a model?

No. Fine-tuning changes model weights. A context pack is plain text you pass in with each call. You can edit it in five minutes, diff it, and roll it back. For a small team, that control matters more than squeezing out a few points of style match.

### How long should the pack be?

Short enough that a person reads it before approving a change. One to two pages is a good ceiling. If it grows past that, split it into a core pack and a per-campaign addendum, and keep the core stable.

### Do I need retrieval-augmented generation (RAG) for this?

Not at first. Retrieval-augmented generation (RAG) means the system searches your documents and feeds passages to the model. A two-page pack fits in the prompt directly. Reach for retrieval only when the proof library is too big to paste, and then follow the access rules in the rules, retrieval, or agent guide.

### Who owns the pack?

One named person. Not “marketing.” That person approves edits, dates them, and decides what counts as proof. Everyone else proposes changes through the same review you use for prompts.

### What about a standard operating procedure (SOP)?

A standard operating procedure (SOP) says how a job is done. The context pack says what the job is allowed to say. You need both. Write the SOP first if the job is still unclear, then write the pack.