# Customer Context Layer: Making Golden Context Useful for a Small SaaS

Canonical URL: https://www.martechdevs.com/blog/martech-context-work

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder, martechdevs

Published: 2026-01-02

Last updated: 2026-10-13

A customer can look ready for an upgrade in your product data and be waiting for an apology in your support system. If your AI sees only usage, it can write a persuasive expansion email at exactly the wrong moment. A useful customer context layer makes the missing facts available before the decision.

For a ten-person SaaS company, this does not have to begin with a new platform. It begins with one decision, the evidence required to make it, and someone responsible for keeping that evidence usable.

The hard part is rarely finding a place to store another document. It is deciding which source wins, how old a fact can be, what the agent may infer and who can authorise a change to the rules.

## What Golden Context means in practical terms

In his [9 October 2026 essay on context work](https://newsletter.chiefmartec.com/p/context-is-a-hot-word-in-martech-but-the-work-required-is-underestimated), Scott Brinker revisits the Golden Context framework developed with Frans Riemersma. It connects customer circumstances, company priorities and the portion of both that systems can use. He also stresses that maintaining alignment requires organisational work, not just software.

Here is an original small-company application of that idea:

- Customer context: a workspace is growing, its administrator wants easier collaboration, and an unresolved incident is blocking a key workflow.
- Company context: the team wants expansion revenue, but its approved playbook puts incident resolution before promotional outreach.
- Systems context: the product events, current support status, workspace identity and approved playbook are available to the workflow making the recommendation.

If the incident exists only in the founder's memory, it cannot reliably influence the automated decision. If it is stored in a support ticket but joined to the wrong workspace, the result is still wrong. If the agent can read it but nobody defines what should happen, the decision remains ambiguous.

Golden Context is a useful aim. It is not a certificate that the business has complete customer understanding.

## Define the layer by the decision it supports

For this guide, a customer context layer means the maintained data, definitions and retrieval paths needed to understand a customer in a particular workflow. It connects facts to their meaning, source, freshness and permitted use.

Start with a decision that is specific enough to test: “Should we recommend an expansion conversation for this workspace today?”

That is more useful than “give the agent all our customer context.” The narrower decision tells you which information matters:

1. The workspace and the people associated with it.
2. Its current plan and relevant product usage.
3. The observed need an expansion conversation might solve.
4. Support or account conditions that should pause outreach.
5. The approved offer and the person responsible for the relationship.
6. Current contact eligibility and previous outreach.
7. The evidence the reviewer should see before deciding.

Some of these are facts, some are interpretations and some are policies. Keep them distinguishable. “Five active members” is a measurement under a definition. “The team is ready to upgrade” is an inference. “Pause promotional outreach during a severe incident” is a business rule.

An agent should not turn an inference into a fact merely because it generated the sentence confidently.

## Map the existing stack before buying anything

Imagine a fictional SaaS using HubSpot for relationship records, Segment for product-event delivery, a warehouse for account models and a support tool for tickets. This is an architecture example, not a claim that those products automatically share every field or permission.

Keep a stable internal workspace ID. Maintain explicit mappings to the relevant CRM company and support organisation. A person's email can change, and one person can belong to multiple workspaces. The context lookup must identify the workspace for this decision, not merge every activity under that person's address.

Use the warehouse for reconciled usage and account facts. Use the support system's current state when an old support snapshot could change the action. Keep the approved expansion rules in a versioned document or configuration owned by the business.

An API or MCP tool can expose the required information to an agent. The connection is a delivery mechanism. It does not decide which account mapping is correct, whether the support data is stale or whether an email should be sent.

![Product events and CRM identity combine with current support state and approved rules. Complete, current, permitted context supports a reviewed expansion recommendation and a final action check.](https://www.martechdevs.com/assets/blog/martech-context-work.svg)

The [support customer context guide](https://www.martechdevs.com/blog/support-customer-context) covers the identity and support data in more detail. Here, the extra work is turning that information into a maintained decision process.

## Write a small context contract

A context contract says what a workflow needs, where it comes from and how to behave when it is missing. It can begin as a reviewed document. Implement the important rules in the actual workflow as you move beyond manual review.

For the expansion example, define account usage over a named window and require that the source is complete through a known timestamp. Define what counts as a blocking support issue. Define the current plan using the billing or entitlement source your team has chosen, rather than whichever CRM field happens to be convenient.

Then specify conflict behaviour. If billing says the workspace has upgraded but the CRM still says Starter, hold the recommendation and reconcile the records. Do not ask the model to vote between them.

This fictional YAML is a planning record, not a vendor configuration or an Agents Schema import:

```yaml
decision_id: expansion-review-042
workspace_id: ws_042
assessed_at: "2026-10-13T09:00:00Z"
policy:
  id: expansion-review
  version: 3
  owner_role: growth_lead
usage:
  active_members_7d: 5
  source: warehouse.workspace_usage
  complete_through: "2026-10-13T08:45:00Z"
  max_age_minutes: 60
support:
  blocking_issue: true
  source_record: support:ticket_731
  checked_at: "2026-10-13T08:58:00Z"
  max_age_minutes: 5
relationship:
  owner_role: founder
  contact_eligibility: not_checked
recommendation:
  action: hold
  reason: unresolved_blocking_issue
  next_owner_role: support_lead
```

At the assessment time, the usage completeness timestamp is 15 minutes old and the support check is two minutes old. Both meet these illustrative freshness limits. The recommendation is still to hold because the blocking issue is present.

Contact eligibility remains unchecked. Resolving the incident would therefore not automatically make the account ready for outreach. The remaining prerequisites must still be evaluated.

The one-hour and five-minute limits are example operating choices. Set yours according to the cost of acting on stale information and the freshness your systems can actually deliver. A nightly source cannot honestly satisfy a five-minute requirement.

## Separate information that changes at different speeds

Do not refresh everything on the same schedule.

Brand position and the approved expansion playbook may change infrequently. Keep an owner, an effective version and a review trigger. A pricing change or product launch should trigger review immediately, even if the routine review date is weeks away.

Workspace usage may update in batches. Record the period it covers and the latest complete data boundary. “Refreshed at 09:00” is not enough if the refresh only loaded events through yesterday.

Support status, recipient preferences and previous sends can change between recommendation and execution. Recheck the conditions that can invalidate the action at the point of action. An approved recommendation from yesterday should not bypass a new suppression or an incident opened this morning.

Caching can be useful, but the cache needs an expiry rule and a response when refresh fails. For this expansion workflow, a failed support lookup should produce “support status unavailable,” with the recommendation held. It should not produce “no open issues.”

This is also why one large context file is a poor home for changing account facts. The [context engineering guide](https://www.martechdevs.com/blog/context-engineering-marketing) provides a starting structure for durable business definitions. Live state needs a maintained retrieval path beside those documents.

## Give each kind of context an owner

In a ten-person company, one person may hold several roles. The responsibility still needs to be explicit.

The growth lead owns the expansion decision, its success measure and the approved offer. The product lead owns the interpretation of usage and activation. The engineer responsible for data owns identity mapping, freshness signals and failed retrievals. The support lead owns the definition and resolution of blocking account issues. The founder resolves conflicts between revenue pressure and customer commitments.

Avoid assigning “all context” to the engineer. Engineers can encode a rule. They cannot reliably invent the company's promises or decide when a commercial exception is justified.

Also avoid making the founder approve every harmless wording change. Define which changes alter the decision policy. Changing an example sentence is different from allowing outreach to accounts with unresolved incidents.

Keep a short change record: what changed, why, who approved it, when it becomes effective and which workflows depend on it. If an exception applies to one account, give it a scope and an expiry. Do not silently turn it into the default rule for everyone.

## What the vendors mean by a context layer

The phrase now covers several products and architectural positions. These are their documented approaches, not evidence that they offer identical capabilities or that a purchase removes the work above.

[HubSpot describes its context layer](https://www.hubspot.com/company-news/introducing-the-agentic-customer-platform) around Smart CRM, customer records and interactions, business knowledge and team context. Its platform framing connects that context to applications, agents and coordination. That is relevant when relationship work already lives in HubSpot; check the exact feature and subscription required for your workflow.

[Hightouch argues for composable context](https://hightouch.com/blog/composable-context): connecting to warehouses and existing knowledge systems, while writing marketing learnings back into the customer's stack. For a buyer, the useful question is what can actually be retrieved, exported and reused outside the vendor's interface.

[Snowplow's documentation](https://docs.snowplow.io/docs/get-started/) centres on behavioural data, validation, enrichment and real-time context through its data infrastructure and Signals. That addresses a different gap from documenting why the founder approved an unusual customer promise.

[RudderStack's distributed-metadata argument](https://www.rudderstack.com/blog/one-context-layer-or-many-metadata-architecture-agentic-era/) emphasises context at its source, including event provenance and transformations. It also acknowledges reconciliation, governance and availability as reasons central coordination still matters. Treat this as an architectural position to evaluate, not proof that every agent will reconcile distributed sources correctly.

[Fivetran Context Layer](https://fivetran.com/docs/context-layer) is documented as Public Preview. It combines documentation, operational and analytical sources, with access through Agent Context MCP or the warehouse. Current prerequisites include supported paid plans and North American destinations on Snowflake, BigQuery or Databricks. Check eligibility before planning a rollout around it.

Ask each supplier to demonstrate your failure case. What happens when two systems disagree about the plan? Can the workflow distinguish stale from absent data? Where is the approved rule stored? Can an ordinary user retrieve something they should not see? A demonstration using your question is more useful than a shared product label.

## Where Agents Schema fits

[Agents Schema](https://github.com/dbt-labs/agents_schema) publishes metadata into an `AGENTS` schema in the warehouse. It gives agents a discoverable place to find context about the data they query, including source models and definitions. It does not replace every source-native API or development tool.

The [current specification](https://github.com/dbt-labs/agents_schema/blob/main/SPEC.md) uses `AGENTS.ROOT` as a provider registry, with `provider`, `key` and `content` fields. Providers can describe their contributed tables and publish agent-readable guidance. The content can be loosely structured; this is not a rigid business-object model that every source must share.

For our example, it could help an analyst discover the approved workspace-usage model and its documentation. It would not, by itself, make a stale support extract current or enforce a sending rule.

Start with the maintained source definition, then decide how to publish it for discovery. Copying a wrong definition into an open schema makes it easier to find, not more accurate. Access controls, publishing ownership and checks that the agent actually used the relevant context remain implementation work.

## Budget for maintenance, not only the first draft

Here is an original planning estimate for one expansion workflow. It is not a benchmark or a report of client results.

Allow two hours to agree the decision and policy, three hours to map the required fields and sources, three hours to build reference cases, and two hours to document ownership and change triggers. That is ten hours of definition and review work. Connector development, identity repair and production implementation are additional.

Reserve 30 minutes a week to review failed or disputed recommendations and one hour a month to check definitions and dependencies. In a four-week planning month, that is three hours. Changes to pricing, instrumentation or customer promises create extra work outside that allowance.

The estimate is useful because it exposes the tradeoff. If the team cannot give one workflow three maintenance hours a month, promising a company-wide autonomous context layer is premature. Narrow the workflow until ownership is credible.

## Measure whether the context changes decisions

Count preventable mistakes and review effort before celebrating the number of connected sources.

In a fictional audit of 40 expansion candidates, suppose 30 have complete required context, six lack a reliable support state and four have unresolved workspace mappings. Decision coverage is 30 divided by 40, or 75%. The ten incomplete cases should remain visible as unresolved work.

Suppose reviewers accept 24 of the 30 supported recommendations. That is 80% acceptance among covered cases and 60% accepted recommendations across all candidates. Neither number proves the recommendations increased revenue. They describe workflow readiness and reviewer agreement.

Track why the other six were rejected. Missing context requires better retrieval. A wrong usage definition requires a model correction. A poor commercial rule requires a business decision. Combining all three under “the AI was wrong” prevents useful repair.

Measure commercial impact separately, with an appropriate comparison and customer-experience checks. An upgrade following outreach does not establish that the outreach caused it.

## A practical first-release checklist

- [ ] One customer decision has a named owner and an explicit expected benefit.
- [ ] Person, workspace and company identities are distinguishable.
- [ ] Required facts have sources, definitions and freshness limits.
- [ ] Conflicting, unavailable and expired evidence have defined outcomes.
- [ ] Business rules have versions, owners and effective dates.
- [ ] Action conditions are rechecked when the action occurs.
- [ ] Restricted information stays restricted in the actual retrieval path.
- [ ] Reviewers can see why a recommendation was made and correct the right source.
- [ ] Missing coverage and ongoing maintenance are included in the success measure.

A [composable CDP](https://www.martechdevs.com/blog/composable-cdp) may provide identity, modelling or activation capabilities within this design. A context layer also needs the company rules and decision evidence that make those capabilities useful. The two ideas overlap; neither label guarantees the other is complete.

If your team has the data but keeps rebuilding the same explanations for every AI tool, our [context engineering work](https://www.martechdevs.com/custom-martech-ai-agent#context-engineering) can turn one useful workflow into maintained definitions, retrieval paths and reviewable decisions. Start with the customer moment that deserves better judgment.

## Frequently asked questions

### What is a customer context layer?

It is the maintained information and retrieval structure a workflow needs to understand a customer in context. Useful implementations include identity, relevant facts, definitions, sources, freshness and permitted use. Its scope should follow the decision it supports.

### Is Golden Context a specific software product?

In the Brinker and Riemersma framework, it is an aspiration to align customer circumstances, company priorities and what systems can act on. Different products can support parts of that work. Buying one does not establish complete understanding or operational alignment.

### Is a context layer the same as a CDP?

There is overlap in customer data, identity and activation. The context required for a decision can also include company policies, promises, current operational constraints and source provenance. Evaluate those capabilities directly rather than assuming either category covers everything.

### Do we need Agents Schema to start?

No. A reviewed definition, a reliable account model and a bounded retrieval path can support the first workflow. Agents Schema becomes useful when warehouse-connected agents need a shared way to discover published metadata. It is one delivery approach, not the prerequisite for knowing your own rules.

### Who should own context in a small company?

Assign a business owner to the decision and source owners to the facts it uses. Engineering owns reliable delivery and controls; product, growth, support and leadership own the meanings and policies within their remit. One person can cover multiple roles, but each responsibility should be named.

## Sources

1. [Scott Brinker on the work behind marketing context](https://newsletter.chiefmartec.com/p/context-is-a-hot-word-in-martech-but-the-work-required-is-underestimated)

2. [HubSpot's agentic customer platform](https://www.hubspot.com/company-news/introducing-the-agentic-customer-platform)

3. [Hightouch on composable context](https://hightouch.com/blog/composable-context)

4. [Snowplow introduction and architecture](https://docs.snowplow.io/docs/get-started/)

5. [RudderStack on distributed context](https://www.rudderstack.com/blog/one-context-layer-or-many-metadata-architecture-agentic-era/)

6. [Fivetran Context Layer overview and prerequisites](https://fivetran.com/docs/context-layer)

7. [Agents Schema repository and scope](https://github.com/dbt-labs/agents_schema)

8. [Agents Schema specification](https://github.com/dbt-labs/agents_schema/blob/main/SPEC.md)