Layers per client and context documents
Resolve the client, route and apply precedence
Answer with the client's rules and tables
AI agent, reports and client service
What it solves
- The agent never mixes one client's data or rules with another's.
- Each client is measured by the definition agreed with the agency.
- When data is missing, the agent says so instead of estimating.
Business questions it answers
Ask your agent these questions once the case is live.
What you need
- Each client's sources connected and organized by layer
- Each client's definitions: lead, sale, main event, taxes and scope
What you get
- A routing document per client and platform
- A global contract with rule precedence
- An agent that answers by each client's rules
- The list of what still needs validating with each client
Where to activate
The account manager asks about a client and gets the answer by that client's rules.
Report templates in the context, filled only with queried data and with questions when something is missing.
Data sliced by client for an agent that sees only its own dataset.
Little transformation and a lot of writing. The work is surveying and validating each client's rules; the model repeats for every new client. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
Each agency client has its own funnel, conversion event, taxes, CRM and vocabulary. Without separate context, the AI agent uses another client's table because the name looks similar, applies the global rule on top of an agreed exception, or estimates a number that does not exist. The answer looks right and reaches the client wrong.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
The order is: 1) client named in the current request; 2) conversation context, only when there is exactly one active client and no ambiguity; 3) otherwise, the client stays unresolved and the agent asks. A question covers one client only. Queries that combine clients only when explicitly requested.
Each client has a routing document per platform that states its source, layer and physical tables. That document only resolves where the data lives: it does not redefine KPI, result, grain or deduplication. The global documents say how to interpret the data and hold no client physical names.
When two rules conflict, this order applies: 1) explicit user request; 2) validated client rule; 3) global agency rule; 4) generic platform interpretation. A global rule never silently overrides a validated client exception.
Another client's table is not proof, even with the same name, structure, metrics and connector, or when its document shows up by similarity. Do not reuse a validated join, observed grain or available history from another client.
A lead can be a digital deal created in the CRM, a contact with a valid conversion in marketing automation, or a conversion reported by the platform when there is no CRM. The same word (lead, MQL, sale) changes from client to client. Use the vocabulary of the report the client already receives and write the definition in their document.
Fixed header: STATUS (validated, partially validated, surveyed in the data and not validated), scope, owner and date of last review. When answering with an unvalidated rule, the agent warns that the rule is the agency's and is pending validation with the client.
Declare what is not part of the analysis: a reactivation funnel built from imports, revenue from the old customer base when the agency only handles the new slice, the client's own campaigns in the shared account. Never divide the client's total revenue by the agency's budget.
A client with no CRM connected has no sales, MQLs or close rate in the data: the right move is to say so, not to approximate. No number is estimated, rounded for convenience or inferred. If a report is missing information, the agent asks before filling it in.
Rules are stable; counts (active clients, layers, connectors) are a snapshot of a date and go stale within days. If a number in the document diverges from the query, the query is the truth. Before flagging a divergence, check the date of the source's last run.
The agent may retrieve only an excerpt. Each block must stand on its own: a descriptive title with the client's name, one concept per block, terms defined before they are used, and explicit references to table and field.
Who wins when two rules conflict
From strongest to weakest. With no resolved client, none apply.
Definitions
Pitfalls that already happened
Clients with tables sharing the same connector prefix and similar names led the agent to answer with another client's data.
Routing per client and a written ban on using another client's resources.
A client that agreed on a custom event as the result got a CPL calculated from the global rule's standard lead.
Precedence in the global document and the exception marked as validated.
Almost all of the client's revenue was repeat purchases from the existing base; dividing it by the media budget produced an absurd return. Revenue coming from marketing was a tiny fraction.
Written scope: only revenue from people who were marketing leads counts.
For a media-only client, the agent approximated sales from platform conversions.
An overview document stating that the question has no answer in the data.
Documents written by an agent showed up duplicated, with test probes and a "generic market overview" in the middle of the client's context; the generic benchmark became the answer.
Automation only updates marked blocks; generic content stays out of the client document.
Layers and connectors changed within a few days and the warehouse copy of the portfolio lagged by up to 24 hours; the document and the query diverged.
A date on every count and the query as the truth.
Acceptance test
The case is done when every item passes.
- Asking for the same metric for two clients with similarly named tables, each answer uses only that client's own source and layer.
- A question with no client, in a conversation without a single client, gets a question back and no number.
- For a client with a validated result exception, the agent's cost per result matches the client's official report (difference below 1%).
- For a client with no CRM, "how many sales did we have this month" is answered as nonexistent data, with no estimate.
- Every client document has STATUS, owner and review date in the header.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
Per-client context contract - Every question covers exactly one client. Resolve in this order: client named in the request; conversation context only if there is a single active client; otherwise, ask which client it is. - Never pick a client by similar name, same platform or similar tables. - The physical location (source, layer, tables) comes from the "<client> Routing" document for each platform. The global documents say how to interpret, not where the data is. - Another client's resource is not evidence, even with the same table, metric and connector. - Precedence: 1) explicit user request; 2) validated client rule; 3) global agency rule; 4) generic platform interpretation. A global rule never overrides a validated exception. - Lead, MQL, SQL and sale are defined in each client's document. Use that client's definition. - If the rule used has status "not validated", say the rule is the agency's and is pending with the client. - With no connected data (e.g. a client with no CRM), say the question has no answer in the data. Never estimate. - Counts written in the documents are a snapshot of a date; if they diverge from the query, the query wins. - Combine clients in one answer only when the user explicitly asks. Per-client exceptions: - <client>: lead = <definition>; status: <validated | not validated> on <date>. - <client>: out of scope: <funnel, revenue or campaigns that are excluded>. - <client>: no CRM connected; sales and MQL questions have no answer in the data.
Build the "Per-client context for the AI agent" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/agencias/contexto-por-cliente-ia.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.
Variations
One table or layer per client for agents exposed to the end client; in the notebook, literal table names per client.
Multi-client sources (Google Business Profile, Business Manager) filtered by the client identifier declared in the document.
The agency itself, analyzed as a client, sits in a scope separate from the global rules it maintains.