How many rules should a context layer start with?

Fewer than ten. Seed the ones you already know without research: fiscal calendar, currency handling, universal reporting exclusions, attribution, your deprecation convention, the allowed object and field list, and the anti-patterns you've already been bitten by. Everything after that should come from a wrong answer you logged and traced. A library that starts large was written by guessing.

Which rules must load on every question?

Exclusions, anti-patterns, temporal rules, currency rules, and the allowlist. They share one property: the agent cannot detect that they're missing. A skipped interpretation rule produces a hedge; a skipped exclusion produces a confident wrong number that includes every test record in your org.

Do these seven rules work for HubSpot as well as Salesforce?

The failure modes are identical; the object names and the syntax of the filter fragments differ. Fiscal calendars, mixed currencies, junk records polluting counts, split attribution, dead fields, and ungroupable calculated properties all show up in both. Swap the API names for yours.

What comes after the first seven?

Whatever your logs tell you. Run the agent, keep the guidance version and rule IDs with each answer, and when someone reports a bad one, find the assumption it made and write the rule that prevents it. Each new rule should get a golden question that fails without it, so the fix stays fixed.

The minimum viable CRM context layer

The reason most people never build a context layer is that it looks like a documentation project with no finish line. Define every field, explain every object, and start when exactly?

It isn't that, and the finish line for version one is about seven rules.

Here's the whole starting library as a copyable file: minimum-viable-context-layer.yaml. It validates against the canonical entry schema, and every rule in it is one you can write today without research, because you already know the answer.

The seven

#	Rule	Category	Always loads
R-001	Use the fiscal calendar for every quarter, year, and comparison	`temporal`	yes
R-002	Never sum amounts across currencies without converting first	`currency`	yes
R-003	Exclude system-generated, test, and internal records from reporting	`exclusion`	yes
R-004	Credit the AE and the development rep from their separate fields	`attribution`	no
R-005	Treat any `DNU_`-prefixed field as dead	`authority`	yes
R-006	Query only allowed objects and fields; refuse rather than substitute	`security`	yes
R-007	Never group or filter on a multi-select or formula field	`anti_pattern`	yes

Six of the seven always load. That ratio isn't an accident. These are the rules an agent cannot detect are missing. It has no gap to notice, so it answers confidently from a number that includes every test opportunity in the org.

Why these seven

Each one maps to a failure that shows up in every CRM I've worked in, and each produces a wrong answer that looks completely fine.

Fiscal calendar. If your year doesn't start in January, every quarter-over-quarter comparison an agent makes is silently shifted by a month or two. Nothing errors. The trend line is just wrong. This is the single most common source of confidently incorrect CRM AI output.

Currency. Mixed-currency amount fields sum without complaint. The total is meaningless and looks exactly like a real number, which is the whole problem.

Reporting exclusions. Every org accumulates records that aren't real: CPQ artifacts, test accounts someone made in 2023, internal provisioning opportunities. They inflate every count. Nobody remembers they exist until a number looks too good.

Attribution. Two roles usually get credit for a deal, and they live on different fields. Collapse them onto one owner field and you credit the wrong person consistently, which people notice at exactly the wrong moment.

Deprecation convention. You can't write a rule per dead field, and there are always more than you think. A naming convention plus one global rule covers the entire long tail with a single line of guidance. That's the highest coverage-per-word rule you will ever write.

The allowlist. Without one, an agent that can't find what it wants goes looking for an object with a promising name and answers from that instead. The rule is the semantic half; the same list has to be enforced in code at the tool boundary, because guidance text is not authorization.

Anti-patterns. Grouping by a multi-select returns a distribution over stored combinations, so Cloud;Security becomes its own bucket. Formula and calculated fields don't behave like stored values in aggregates. Both operations succeed and return something plausible and wrong. The expensive failures are the ones that return a result.

What one looks like

minimum-viable-context-layer.yaml (excerpt)

- id: R-003
  kind: rule
  title: >
    Exclude system-generated, test, and internal opportunities from all pipeline,
    win-rate, and forecast reporting
  category: exclusion
  appliesTo: [Opportunity]
  alwaysLoad: true
  status: active
  version: 1
  ruleText: >
    Before running any query on Opportunity, add the exclusion filters below
    unless the user has explicitly asked for operational testing records. These
    records are created by quoting and provisioning automation and are not real
    pipeline. Say which exclusions were applied before giving a total.
  filterFragment: "Type != 'Internal Test' AND IsSystemGenerated__c = false"
  owner: revops
  evidence: CPQ creates one artifact opportunity per quote revision
  testIds: [GQ-07]
  updated: "2026-08-20"

Three details in there do most of the work.

The title states a condition, not a category. In a phased retrieval design the agent decides whether to fetch the body from the title alone, so Opportunity exclusions would get skipped and the rule would never apply.

The rule text is an instruction to perform, not a description of a policy. "Test records are excluded from reporting" gets read and ignored. "Before running any query on Opportunity, add these filters" gets applied. Same information, different verb mood, materially different compliance.

The filter fragment ships the predicate. A prose definition gets re-derived on every run and mis-derived on some of them.

Adapting it

Swap the object and field names for yours. Then:

Fix the fiscal calendar in R-001 to your actual boundaries, including how the year is named. Getting this subtly wrong is worse than not having the rule.
Delete R-002 if you're single-currency. Say so explicitly in R-001 instead, so the agent knows rather than assumes.
Fill R-003 with your real junk. Look at what a pipeline report excludes today and copy those filters. Somebody already solved this in a report definition.
Set your deprecation prefix in R-005. DNU_, ZZ_, OLD_, whatever you already use. If you don't have one, adopt one now and rename as you go.
Cut R-006 down to what you actually need. Start narrow. An agent that can reach four objects and answer well beats one that can reach forty and guess.

Then stop. Resist the urge to document the rest of the org.

Growing it

Everything after these seven should come from a wrong answer you logged and traced. An agent counts test records as pipeline, you find the assumption it made, you write the rule. That rule stays forever, and it encodes something nobody knew was load-bearing until it broke.

Two habits make that loop work:

Log the guidance version and rule IDs with every answer. You cannot write a corrective rule for a failure you can't reconstruct, and "the agent said something weird on Tuesday" is not a reconstruction.

Give every new rule a golden question that fails without it and passes with it. That's what makes the fix stay fixed when the library is forty rules deep and someone changes retrieval logic.

The complete list could not have been written up front by anyone, in any org. A mature rule library is scar tissue from specific mistakes, and that's exactly what makes it valuable.

How to build an AI context layer for your CRM — the full concept and build
The rule schema — every field, the thirteen categories, and how to validate
Salesforce implementation — the same rules as an admin-maintained custom object
HubSpot implementation — as files or an Enterprise custom object