AI costs in marketing: Context costs more than licenses and tokens. How to get started

When I look at our projects from the past months, one constant stands out. Whether we build an agent team for a client or an AI operating system. Whether it’s AI in marketing or optimization in sales. By far the most time and energy go into Context Engineering.

It’s the same in our internal processes. Of all the disciplines we work with, Context Engineering is the one that ultimately determines the outcome. In six of eleven client cases, a curated knowledge base is the backbone the agents run on.

What does AI really cost in the enterprise?

This balance is now backed by data. On September 14, Bitkom published a new AI study surveying 603 companies. They asked where the major AI costs occur. Infrastructure was cited by 51 percent. Preparing internal data, 50 percent. Integration with existing systems, 41 percent. Licenses and subscriptions? Only 21 percent. Token consumption, the topic of many debates, is a major cost for just 8 percent.

• 51 % – Infrastructure as a major cost
• 50 % – Preparing internal data
• 41 % – Integration into existing systems
• 21 % – Licenses and subscriptions

Bitkom President Ralf Wintergerst summed it up: "Anyone who only buys a license has purchased AI, but changed nothing." He gets more specific for agents. An agent that acts on its own needs "reliable data, connected systems, and rules for what it may and may not do."

What is Context Engineering?

Context Engineering is the work of giving an AI the right knowledge, rules, and relationships for a specific task. A model knows nothing about your company. It doesn’t know your brand, your target groups, your approval workflows, or the campaign that failed last spring.

In most organizations this knowledge is scattered: in PDFs, old presentations, email threads — and mostly in people’s heads. A person knows which document is outdated. An agent does not. Preparing, organizing, and maintaining that knowledge is rarely budgeted when the AI plan is made. That’s exactly where the AI costs in the Bitkom study come from.

This work can be done in stages. The most expensive mistake is the reverse: buy a platform first, then decide what goes into it. That’s a shelf for a library that doesn’t exist yet.

Step 1: Start with a task and a scope

Context Engineering starts with the question: which task should an agent take on? The more specific, the better. In marketing this might be: create campaign briefings for a product line. Or: prepare proposals for a defined service package.

The task determines what knowledge is required. Everything else stays out for now. That turns an open-ended data project into a bounded one. That’s how we work in large client organizations too: start from concrete use cases and derive the structure backwards. The framework follows.

A useful test: Can you describe in two sentences what the task will deliver and who will approve it? If not, the task is still too big.

Step 2: Derive a Knowledge Graph for that domain

Before migrating anything, map the items involved in the task and how they relate. This is a Knowledge Graph in its simplest form: nodes and relationships.

For a campaign briefing the nodes might be brand, product, persona, pain point, message, channel, approval process, and past campaigns with their results. Relationships turn that into knowledge: the persona has a pain point. the product addresses it. the message targets the persona. the channel reaches them.

This sketch fits on a whiteboard and takes half a day. It immediately shows what information exists and what’s missing. Often you’ll find twenty pages of brand guidelines but no agreed description of the personas. Then the data project becomes a clarification project. An agent needs a single, clear answer where humans have been diplomatically inconsistent.

Step 3: Migrate the context piece by piece

Now turn the sketch into a repository. This is the part that surprises many: you don’t need complex infrastructure at the start. Shared folders and Markdown files are enough.

The mapping is direct. Each node type becomes a folder: Personas, Products, Messages, Campaigns. Each node becomes a file. Relationships become links between files. People can read and edit Markdown. Models ingest it without detours. And you’re not locked into any product.

Three rules we follow:

• A fact lives in exactly one place. The persona description exists once; other files link to it.
• Each file has an owner and a date. Otherwise no one will know in six months if the content is still valid.
• Sources get distilled. A 40‑page PDF is reduced to what the task actually needs.

Our own Company Brain started exactly this way: folders on a shared drive, Markdown files, one file per topic. It still runs on that foundation.

Our Company Brain: Start with folders and Markdown

Our own Company Brain started exactly this way: folders on a shared drive, Markdown files, one file per topic.

The mapping is direct: each node type becomes a folder. Each node becomes a file. Relationships are links between files.

People can read and edit Markdown. Models understand it without detours. We’re not tied to a vendor. It still runs on this basis today.

Step 4: Agents and processes that grow the Company Brain

Once the context for the first task exists, you assign the agent its mission. It reads the files it needs and produces the briefing. That’s the visible part. The more important part is what happens next.

We learned this the hard way. Earlier, manually maintained brand folders atrophied because they lacked feedback loops and rituals, even though the tech worked. That’s why processes belong from day one. New insights from meetings land in an intake folder and get regularly incorporated. If a person corrects an agent output, the correction is written back into the source file. And a recurring weekly meeting has one job: find contradictions and decide which information holds.

Agentic workflows can handle a large share of this maintenance. Humans remain responsible for relevance decisions. The rules for that live in written AI governance where any agent can read them.

Then you add the second task. It reuses some of the same nodes. Personas are already there, so is the brand. You add only what’s new. With each task, the Brain grows and each subsequent task becomes cheaper.

1. Step 1: Task and scope
   Context Engineering starts by defining the task an agent should do. The more specific, the better: for example campaign briefs for a product line or proposals for a service package. The task determines the knowledge needed; everything else stays out for now.
2. Step 2: Knowledge Graph
   Before migrating data, map the nodes and relationships for the task. For a campaign brief, nodes include brand, product, persona, pain point, message, channel, approval process, and past campaigns. The sketch exposes missing information and reveals contradictions.
3. Step 3: Migrate context
   Turn the sketch into a repository with folders and Markdown files. A fact lives in one place, each file has an owner and date, and sources are distilled. Relationships are links between files.
4. Step 4: Agents and processes
   The agent reads the needed files and creates the briefing. Feedback loops and rituals ensure new insights are incorporated and contradictions resolved. With each task the Brain grows and each next task costs less.

When the infrastructure must scale

Folders and Markdown have limits. When many agents access content concurrently. When permissions need to be finer than “this folder, that team.” When data must come live from other systems — that’s when true AI integration begins. Or when a definitive Company Brain must carry more weight than personal notes so contradictions don’t fall on the agent.

That’s the moment to add search indexes, databases, and APIs. We evaluated off‑the‑shelf knowledge tools. Technically they can do a lot. What they lack are governance, ownership, and a higher-level context — exactly what you build in the first three steps. The graph stays the same. Only the underlying storage becomes more powerful.

Infrastructure should match functional scope. If you spend the 51 percent from the Bitkom study at the start, you’re paying for capacity that no task yet needs.

Frequently asked questions about Context Engineering

What’s the difference between Prompt Engineering and Context Engineering?

A prompt describes a single request. Context Engineering ensures every request is grounded in the same verified knowledge. Prompts get shorter and results become more stable.

Do I need a graph database for a Knowledge Graph?

At the start, folders as node types, Markdown files as nodes, and links as relationships are sufficient. Move to a database when volume, access patterns, or live data require it.

Who in the organization is responsible for Context Engineering?

Assign a named owner per knowledge area, supported by IT. Context Engineering is a leadership responsibility because context arises in decisions and accountabilities. It’s a core part of AI enablement.

What you can do this week

Bitkom finds that 59 percent of AI users say they aren’t using AI’s potential at all. In the projects we see, that almost always comes down to context the model never received.

The first step costs nothing but time: pick a task. Map the nodes and relationships it needs. Create a file for each node.

Which task in your team would benefit first, and who on your team decides today which knowledge counts?