System Prompts: Claude's Briefing Before the Meeting
A system prompt is a set of instructions you send to Claude through the API before the user's message. It's the first thing Claude reads in any conversation, it shapes how Claude behaves for the entire session, and the user never sees it. When you make an API call, there's a dedicated system field where this content lives — completely separate from the messages your users send.
To understand the weight of this instruction, consider the Sorting Hat analogy. Before a student ever sits on the stool, the Hat has a permanent set of instructions woven into its fabric. That's the system prompt — it defines the "Who" and the "How." In the Wizarding World, it's the spell that says: "You are a judge. Look for bravery, loyalty, or ambition. Be witty, speak in rhyme, and don't take any nonsense." In your marketing tool, it's the instruction that says: "You are a senior SQL architect. Use dbt best practices, prioritize staging models over raw data, and always format spend as USD." The system prompt is the logic engine. It doesn't change from student to student — it's the consistent "brain" that processes everything it hears.
Think of it as the briefing you give Claude before it walks into a meeting. Without that briefing, Claude is a capable generalist — smart and helpful, but working with no specific knowledge about your business, your data, or your expectations. With a strong system prompt, Claude becomes something much more useful: a specialist who already knows your client's fiscal year conventions, your column naming quirks, and which tables you trust.
For a marketing analytics tool, your system prompt might say something like:
"You are a marketing analytics assistant. You have access to a BigQuery dataset with the following tables and columns. When users ask about campaign performance, write SQL to query the data and return a clear summary. Spend should always be pulled from staging models, not raw sources. Impressions in the DV360 table use the column nameimpwhile Google Ads usesimpressions."
That last detail — the platform-specific column mapping — is exactly the kind of domain knowledge that turns Claude from a generic SQL writer into something a marketing team actually trusts. Without it, Claude might write technically valid SQL that queries the wrong column. The query runs, the number looks plausible, and nobody catches the error until something downstream breaks.
Good system prompts don't just tell Claude what to do. They tell Claude where the tricky edges are, how to handle ambiguity, and what the stakes are if it gets something wrong. That's what separates reliable AI tooling from unreliable AI tooling.
What Belongs in a Marketing System Prompt
The content varies by task, but a few categories almost always earn their place.
Business context — who is this client, what are their primary KPIs, what does their media mix look like? Claude doesn't need an essay, but a paragraph of grounding prevents a lot of misinterpretation.
Data structure — table names, column names, what each metric means and how it's calculated, and critically, any inconsistencies across platforms. Marketing data is notoriously inconsistent. If your DV360 data and Google Ads data use different column names for the same concept, the system prompt is where that gets reconciled.
Rules and constraints — which models or tables are trusted sources? Which are raw data that should never be queried directly? Are there default date ranges or spend thresholds that should apply unless a user explicitly overrides them?
Format expectations — should Claude return a narrative summary, a SQL block, or a table? Being explicit about output format prevents a lot of unnecessary back-and-forth.
The system prompt is where institutional knowledge gets encoded — the stuff that would otherwise live in one person's head and disappear when they leave. Done well, it's the difference between a tool that requires expert supervision and one a junior analyst can use confidently.
Context Files: How to Keep Your System Prompt Manageable
As your tool grows, your system prompt grows with it. Add a new advertising platform and you need its column mapping. Onboard a new client and you need their schema. Build a new feature and you need a whole set of conventions and guidelines.
If you're managing all of that as a single hardcoded string somewhere in your application code, you're going to have a bad time. It becomes impossible to review, easy to break, and painful to update.
The better approach is to break your system prompt content into separate context files — usually Markdown files — and have your application read and assemble them at runtime. Each file covers one focused area: a base context file with general rules and conventions that apply everywhere, a client-specific schema file with that client's table structure and metric definitions, and a task-specific file for each distinct use case.
Your application reads the relevant files and combines them into a system prompt before making the API call. Claude never sees the files themselves — it just sees the assembled text that your app builds from them. From Claude's perspective, it's all one system prompt.
The practical benefits compound over time. When a client's schema changes, you update one clean, readable file instead of hunting through application code. When you add a new advertising platform, you add its column mapping to the schema file and the tool picks it up automatically. These files live in version control, they're reviewable by people who don't write code, and they stay organized as your tool grows.
This also sets you up for a meaningful cost optimization. The portions of your system prompt that never change between requests — base context, stable schema files — are perfect candidates for Anthropic's prompt caching feature. You pay full price once, then roughly 90% less on every subsequent request that reuses those cached tokens. Breaking your system prompt into stable and dynamic layers makes caching straightforward to implement.
How They Fit Together
Once you see the relationship, the confusion mostly goes away. System prompts are the mechanism — the field in every API call where Claude gets its instructions and context. Context files are how you organize and maintain the content that goes into those system prompts.
For a marketing team building a data tool on Claude's API, the practical takeaway is straightforward: invest in your system prompt content, and break it into focused context files that are easy to maintain. Get those pieces right and you have a foundation that's accurate today and easy to keep accurate as things change.