Building the foundation layer for marketing AI
How I turned scattered prompting and disconnected source material into a shared context system that marketing workflows could build from.
├─ brand-voice.md
├─ company-product.md
├─ content-requirements.md
├─ positioning.md
├─ messaging-matrix.md
└─ workflow-connections/
├─ skill-blog-draft.md
├─ skill-email-review.md
└─ skill-landing-page.md
As AI use expanded, the missing piece was shared context.
Claude Enterprise gave us access to a powerful model, but the company, product, audience, and brand context surrounding the work still had to be reconstructed across projects and workflows.
AI tasks could start from blank chats or different source material, which meant output quality and consistency depended heavily on what context happened to be supplied.
Claude was capable. We just weren't giving every workflow the same reliable starting point.
From starting over to starting from shared context
A reusable source of truth for marketing AI
I first began organizing this foundation in OpenWebUI for an AI-related launch. As our tooling evolved, I migrated and expanded the system in Claude.
The goal was not to create one enormous instruction document. It was to separate durable organizational knowledge from workflow-specific instructions, then make that knowledge reusable across projects, Skills, and recurring marketing work.
Brand voice
Tone, language patterns, audience expectations, approved examples, and the things our writing should avoid.
Company and product
Core company information, product terminology, positioning, differentiators, and the context a model cannot safely guess.
Content requirements
Channel-specific constraints, formatting expectations, quality standards, and examples of acceptable output.
Workflow connections
The reusable Skills and workflows that inherit this foundation instead of recreating it every time.
├─ brand-voice.md
├─ company-overview.md
├─ product-positioning.md
├─ messaging-matrix.md
└─ content-requirements.md
// audience context
├─ audiences/
├─ security-leaders.md
└─ technical-evaluators.md
// workflow connections
├─ workflows/
├─ skill-blog-draft.md
├─ skill-email-review.md
└─ skill-landing-page.md
The modular file structure keeps foundational context separate from individual workflows, so knowledge can be updated and reused without rewriting everything.
The context sits upstream of the workflow
This is the part of AI implementation that is easy to miss. The model only sees what the system gives it. Better outputs begin before the prompt, with clearer source material, stronger examples, and explicit decisions about what the model should and should not do.
The setup matters as much as the output
company-product.md
positioning.md
messaging.md
content-reqs.md
technical-eval.md
channel-partners.md
skill-email.md
skill-landing-page.md
The context layer separates durable company knowledge from workflow-specific instructions.
## Tone
- Confident, not aggressive
- Technical accuracy over jargon
- Direct and clear
## Audience expectations
- Security leaders: business impact
- Technical evaluators: specifics
## Avoid
✗ FUD, buzzwords, unsubstantiated claims
✗ "Revolutionary next-gen AI-powered"
✓ "Continuous monitoring across your environment"
How approved marketing knowledge is translated into model-readable context.
The same task produces different output when the model begins with stronger context.
Visuals, examples, and file names are generalized to protect current-employer work; the structure reflects the actual system.
Organizing the files was not the hardest part
The important decisions were not technical.
I had to determine which information belonged in the shared foundation and which instructions should stay specific to an individual workflow. I had to reconcile contradictions between approved documents and live Skills, decide which examples actually represented good output, and identify where the model needed constraints instead of more information.
The system also had to be understandable by someone other than me. If a workflow only works when its creator is standing nearby explaining it, it is not a reusable system yet.
Shared or workflow-specific?
What should every workflow know, and what only belongs in one use case?
More context or better constraints?
Would additional information help, or did the model need a clearer boundary?
Automated or reviewed?
Which steps could be generated safely, and where did marketing judgment need to remain explicit?
A foundation that can grow with the work
The result is a reusable context foundation that can support new marketing workflows without rebuilding the company's knowledge every time.
It also created a more visible place to catch gaps, outdated guidance, and contradictions. As new workflows are built and tested, the foundation continues to improve.
It's still evolving. Every new workflow exposes another gap, outdated instruction, or contradiction to clean up.
A consistent starting point
Workflows can begin with the same foundational context instead of relying on individual memory.
Reusable infrastructure
New Skills and recurring workflows can build on the existing source layer.
An evolving system
Real work reveals gaps, conflicting guidance, and opportunities to improve the foundation.
Better AI output starts with better source material
I started this work thinking mostly about prompts and workflows. I came away convinced that the quality of the foundation matters more.
A model cannot compensate for unclear positioning, contradictory guidance, undocumented judgment, or a process the team itself has not defined. AI makes those problems more visible. It does not solve them automatically.
The most useful AI systems I have built begin with the same question: What does this workflow need to know before it can do useful work?
From Figma to HubSpot with Claude
How design direction, brand context, platform access, and human review helped turn a basic HubSpot starting point into custom landing-page components.
View case study: From Figma to HubSpot with Claude →