Context engineering for marketing and RevOps: the six files your agent needs

Last updated: 13 October 2026.

Ask two colleagues for “last month's conversion rate” and you may get two defensible numbers. One uses website sessions and form submissions. The other uses qualified opportunities and closed-won deals. An agent connected to both systems inherits the ambiguity.

The fix starts by writing down the decision that people were resolving informally. Better context makes the meaning available before the agent selects a query or proposes an action.

Context, prompts and the surrounding software

A prompt gives the current instruction: “review the September pipeline.” Context supplies the definitions, source data and prior decisions needed to do that work. The harness is the surrounding software that manages tools, permissions, execution, retries and saved state.

Anthropic describes context engineering as managing the information available during model inference, including instructions, tools, external data and conversation history. Its guidance emphasises relevance and maintaining useful context as work progresses. Anthropic's context engineering article.

For a marketing workflow, the distinction is practical:

• The prompt asks for an audience recommendation.
• The context defines eligibility, exclusions and the intended offer.
• The software prevents an unapproved audience from being sent to a campaign.

Writing “never send without approval” is useful guidance. Enforcing approval in the execution path is a separate implementation task.

If your team is building this across several tools, Martechdevs' custom agent work connects the business definitions to the tools and controls that apply them.

Use a small index and six focused files

The following structure is an original working template for a fictional B2B SaaS team. Adapt the content and filenames to your environment; no platform automatically loads these files merely because they exist.

context/
  README.md
  metrics.md
  data-dictionary.md
  naming-rules.md
  customer-fit.md
  playbooks.md
  brand-and-claims.md

The index should tell the agent what each file governs, when to read it and who owns it. Keep stable operating rules there. Retrieve detailed definitions when the task requires them.

For example, a UTM review needs naming rules and the campaign brief. It usually does not need the full renewal playbook or every support transcript.

Open full diagram

This structure makes maintenance possible. When a lifecycle definition changes, there is one known place to update it and a known set of tests to rerun.

File 1: metrics.md

The metric file should resolve the questions hidden inside a familiar label: population, event, period, exclusions and aggregation.

An example:

## Qualified trial rate
Owner: Growth operations
Effective from: 2026-10-01

Numerator: Trial accounts that meet the approved qualification rule
within 14 complete days of trial creation.
Denominator: Eligible trial accounts created during the cohort period.
Grain: Account, counted once.
Exclude: Internal, test and duplicate accounts.
Unknown qualification state: Include in denominator; report separately.
Source: marketing_reporting.trial_qualification_cohorts
Observation rule: Exclude cohorts without a complete 14-day window.

The most valuable line may be the treatment of unknowns. If an agent drops unknown records, the reported rate can improve simply because missing data increased.

Add related terms that must remain distinct. An activated account, a qualified trial and a paying customer may overlap, but they are not interchangeable populations.

Include one small worked example with the expected answer. If 100 eligible trials contain 25 qualified, 60 unqualified and 15 unknown, this definition produces a 25% rate and a separately reported 15% unknown share. That example becomes a reusable acceptance test.

Keep the actual implementation connected to the definition. If the SQL and prose disagree, identify which owner resolves the conflict before the metric is used in a decision.

File 2: data-dictionary.md

The data dictionary explains where evidence comes from and how records relate. A list of column names is insufficient.

## Account identity
Business key: account_id
Billing mapping: account_id -> billing_customer_id
CRM mapping: account_id -> crm_company_id
Expected relationship: one current CRM company per account

## Subscription state
Authoritative source: billing subscription events
Reporting model: customer_reporting.subscription_daily
Grain: one account per reporting date
Freshness expectation: complete through the previous UTC day
Known limitation: CRM lifecycle stage can lag billing status

Document timezones and timestamps separately. created_at, qualified_at, closed_at and synced_at answer different questions. If the agent chooses a valid but inappropriate date field, the query can run successfully and still produce a misleading report.

Also record join hazards. For example, one account may have several contacts and several subscriptions. Joining all three raw tables can multiply rows. The dictionary should identify the approved model or aggregation that avoids that multiplication.

Keep personal data out of a general context file when a description is sufficient. The agent usually needs to know how identity works before it needs to inspect an actual customer record.

The warehouse design guide explains how to turn these relationships into models that support repeatable analysis.

File 3: naming-rules.md

Naming rules turn campaign metadata into something the team can analyse consistently.

## Paid campaign URL rules
utm_source: approved platform identifier
utm_medium: paid_social or cpc, according to channel policy
utm_campaign: stable campaign identifier from the campaign register
utm_content: creative identifier
Case: lowercase
Spaces: prohibited
Personal data: prohibited in URL parameters

Validation output: original URL, proposed URL, reason for each change
Unrecognised value: flag for review; do not invent a new convention

The final line prevents the agent from “cleaning up” a value by creating a new category nobody else uses.

Keep a distinction between identifiers and display labels. A campaign's marketing name can change while its analytical identifier stays stable. That stability makes longitudinal reporting much easier.

For a migration, maintain an explicit mapping between old and new values. Retrofitting names in a spreadsheet does not automatically rewrite historical analytics data or every destination URL already in circulation.

The UTM naming guide provides a fuller campaign-level convention and QA process.

File 4: customer-fit.md

A useful ideal customer profile contains evidence and exclusions. “Growing SaaS companies” gives an agent too much room to guess.

## Fit for the implementation offer
Positive evidence:
- Uses the supported CRM and has a named operations owner.
- Has a specific cross-system reporting or lifecycle problem.
- Can provide access to the required systems during implementation.

Exclusions:
- Requests only a purchased contact list.
- Has no owner for the resulting workflow.
- Requires a capability outside the current service scope.

Unknown evidence: label unknown and state what would resolve it.
Company size alone: insufficient to classify as qualified.

These example criteria are illustrative. Use the actual buying conditions and delivery constraints of your business.

For research workflows, require a source and observation date. A company's old job advertisement may suggest it once used a tool, but it does not establish that the tool is still installed.

Separate fit from intent. An account can match your service well without showing any current need to buy. That distinction changes the appropriate next step and prevents manufactured urgency in outreach.

File 5: playbooks.md

A playbook should identify the trigger, evidence, decision and permitted next step.

## Trial activation review
Trigger: eligible account reaches day 7 without the activation event.
Check: event ingestion freshness, current paid status, open support issue.
If data is stale: stop and report the freshness problem.
If already paid: exclude from trial outreach.
If support issue is open: route the recommendation to its owner.
Otherwise: prepare the approved assistance message for review.
Output: account ID, evidence, recommended next action and reason.
Execution: sending requires the configured campaign approval process.

This is more useful than a long list of generic customer-success advice because it tells the agent what to do with conflicting evidence.

Define completion too. “Reviewed account” could mean the agent retrieved data, wrote a recommendation or actually updated a task. Use a precise status so a later run does not mistake a proposal for a completed action.

For retryable operations, give the implementation an idempotency rule or a way to check whether the action already happened. Repeating a recommendation is inconvenient; sending the same message three times damages the customer experience.

File 6: brand-and-claims.md

Tone is easier to preserve through specific editorial decisions than a list of adjectives.

## Writing principles
Lead with the useful answer.
Use concrete examples and explain the mechanism.
Remove sentences that add no evidence, instruction or necessary context.
Use direct language without exaggerated promises.

## Claims
Use only approved product capabilities and current offer terms.
Label modelled examples as examples.
Do not imply a customer result without an approved source.
When evidence is missing, qualify the claim or remove it.

## Examples
Keep three approved samples with notes on their openings,
sentence progression, level of detail and calls to action.

Add examples of weak and improved sentences using your own material. Explain the improvement: perhaps the revised line replaces a vague benefit with a specific operational result.

For instance, “improve reporting efficiency” says little. “Give the revenue meeting one agreed pipeline figure, with the source query attached” tells the reader what changes and how it can be checked.

Keep factual approval separate from voice approval. A sentence can sound exactly like the founder and still make an unsupported claim.

Give every context item an owner and an expiry condition

Use a compact header for each maintained document:

owner: revenue-operations
version: 1.2
effective_from: 2026-10-01
review_by: 2026-11-01
applies_to: trial-activation-review
status: approved

The dates are examples. Choose review frequency according to how quickly the content changes.

Also define precedence. Signed customer terms may govern a specific account; an approved internal policy governs the general process; an old sales note is supporting evidence. The agent should not decide authority purely from whichever document was retrieved most recently.

Remove superseded context from the active retrieval path while retaining an archive where needed. Leaving two conflicting “current” definitions available creates a problem that more detailed prompting may never fix reliably.

Connect context to tools without flooding the conversation

Give the agent a small index, descriptive tool names and a clear path to the relevant evidence. Anthropic's tool-design guidance stresses clear tool contracts and evaluation against realistic tasks. Writing effective tools.

For example, get_trial_activation_summary can return the approved metric, cohort window, freshness and count of unknown records. That is easier to use consistently than a generic tool returning every property on every account.

When using Claude Code, its project-memory documentation explains how instructions such as CLAUDE.md enter the working context. Link or import the relevant maintained material according to the client's supported mechanism, then verify that the agent actually read it. Claude Code memory.

Skills offer another packaging option for repeatable procedures and supporting files. The Agent Skills specification defines a SKILL.md-based structure. A skill can tell the agent when to read a playbook; it does not grant access to the data or enforce a security boundary. Agent Skills specification.

The marketing skills guide shows how to package these instructions around useful tasks.

Worked example: why the renewal list was wrong

Imagine a fictional agent asked to identify customers at risk before renewal. It sees a CRM field called last_active_date and flags 40 accounts.

The data dictionary reveals that the field records the last CRM interaction, not product usage. The agent has answered a different question: which customers have had little recorded sales contact?

After the context is corrected, the workflow uses a product-adoption model, contract renewal date and unresolved implementation milestones. It identifies 14 accounts for review, with five additional accounts marked unknown because recent usage data is missing.

Those figures are illustrative. The improvement is the decision process: the agent uses the intended evidence and preserves uncertainty.

Add the original failure to the acceptance set. Ask the same renewal question with misleading field names present and check that the agent still selects the approved model. Otherwise the next schema addition can recreate the problem.

Test context changes like changes to a business process

Create a small set of realistic questions with expected behaviour. Include an ambiguous metric, stale data, an excluded account and a request that exceeds the permitted action.

Evaluate four things:

1. Did the agent retrieve the right definition?
2. Did it select the appropriate source and population?
3. Did it preserve unknowns and conflicting evidence?
4. Did it stop at the intended action boundary?

For longer tasks, preserve completed work and unresolved decisions in a structured progress record. Anthropic's work on long-running harnesses discusses the need to maintain useful state across sessions. Long-running agent harnesses.

A marketing version can record the campaigns already reviewed, the files changed, the evidence still missing and the approvals still pending. That prevents the next session from repeating work or treating an unfinished review as complete.

At Martechdevs, we build the data access, definitions and working instructions behind repeatable AI workflows. Start with the free martech AI audit, or explore an AI assistant built around your approved workflows.