Without a source of context about the business they support, agents produce generic work and drift as the business changes.
The solution is a GTM wiki: a folder of markdown files. It grounds every chat and agent in the same context.
An org-wide skill tells agents and chats how to read the wiki. A maintainer agent keeps it current.
Code you can clone: gtm-agent-wiki
What is a context system for marketing agents
A context system for marketing agents is one maintained source of truth about your business: the company, the products, the ICP, the pipeline, the live campaigns. Every chat and agent reads what they need from it before they do work.
Marketing teams are usually provided with access to an agent harness (like Claude). They can fire prompts and build agents. But they are not provided with a way to equip their chats and agents with context about the company they are doing marketing for.
For an agent that can’t be steered, this means it doesn’t work. Its performance will degrade if the context is hard-coded and doesn’t update over time.
A marketing context system is what makes agents produce outputs you can actually use.
A deployed context system is a folder of markdown files. I call it a GTM wiki.
Start with an indexed master file
All agents should be uniformly grounded in the same core context about the business they are supporting.
Agents supporting different channels or business units are going to require specific context about that area to be successful.
But having all your chats and agents read all the context you can provide will bloat their context windows and hurt performance.
The simple solution is one canonical 'index' file. I use AGENTS.md.
It does not hold the knowledge. It contains:
- A short summary of the company.
- A list of the files in the wiki and what each is for.
- A read order for common jobs.
The knowledge lives in the files the index points at. Start with business-core.md, icp-personas.md, voice.md, metrics.md, and competitors.md. Add more when a motion needs it.
KPI definitions belong in metrics.md. Agents that report numbers get those definitions wrong without it. I wrote about that kind of structured context in How to measure what AI actually says about your company.
The wiki exists as a folder of markdown. It works as a git repo or an Obsidian vault. Notion can render it. The object is the files. The host is whatever makes the most sense for your company.
Roll out an org-wide skill
A skill file tells chat sessions and agents to read the index first, then the other files they need.
If agents work in the wiki folder, they load AGENTS.md. Chat agents use the skill. API-built agents get the same contract as a system prompt.
An important step is getting the context system into the chat sessions individual team members use.
I usually make sure the organization I'm supporting has skill sharing on in their enterprise Claude and / or Codex accounts and then have team members install shared skills I publish. That way the whole org is using the same context, and I can make changes afterward if needed.
Keep context up to date with a dedicated agent
Partnerships, events, sales pipeline updates, and site traffic trends all become stale fast.
This is where I end up investing most of my time when building this system with clients.
For agents, stale context can result in poor or incorrect outputs. I have an agent for a client that analyzes weekly site traffic trends and produces an insights report. The agent has context about the team's weekly events and partner announcements. That context drastically improves its performance.
One process edits the canonical files: a maintainer agent.
It pulls from the sources you named. Internal docs, dashboards, the web. GTM agents append new facts and questions to an intake file, and the maintainer agent resolves conflicts and merges them into the context system.
I usually run the maintainer agent as a scheduled cron job. Claude Code Routine, Cursor Automation, etc.
How to start
Don't start with a blank-page interview. Build from evidence you already have. Ask people only what the sources cannot answer.
Then:
- Decide where the markdown folder will live, and what the agents can already read.
- Decide which GTM motions need context now. Those files get built first.
- Name the sources the maintainer will pull, and how often.
If you want the format, clone gtm-agent-wiki and paste the build prompt in the README.