Author
Luana Pereira
Date
October 8, 2026
Category
Governance
An agency runs AI agents across many clients by giving each client an isolated data layer with permissions scoped per client, so one client's data never touches another's, and by turning each learned pattern into a written rule it can reuse across clients without moving anyone's data. Isolation has to be a control at the data layer, not a sentence in a prompt, and the agency's real advantage, the pattern it learns on one account, stops living in an employee's head and becomes a versioned asset. This guide covers the isolation unit, how to set up multi-tenancy, and where the agents run per client.
By giving each client an isolated data layer, scoping permissions per client, and having the agents operate one client at a time, so client A's data never reaches an agent working on client B. The agency does not build one omniscient agent that knows fourteen APIs across every account; it builds agents that read a single governed layer and act in the source tools, with access that is granted, not assumed. Two things make this work and neither is a prompt instruction: isolation enforced at the data layer, and the pattern an agency learns on one client written down as a rule it can reuse on others without moving anyone's data.
In the catalog, a layer is the top-level storage and permission boundary. An agent's access token reads the layers it is granted and cannot touch a layer it is not. Isolation becomes a control, not a sentence in a prompt.
The usual agency setup has data living in a dozen places: one ad account here, a CRM there, press monitoring somewhere else, and anyone who wants to cross two of them opens four tabs and a spreadsheet. A spreadsheet does not isolate anything, does not run overnight, and nobody consults another client's spreadsheet to find a pattern. Running agents on top of that safely is exactly what a per-client data layer plus per-client permissions solves.
Because isolation is what the client is actually paying for, and a leak between clients is not a bug, it is a breach of contract. The privacy of a client's data is the product. So the rule that client A's data never touches client B cannot depend on an agent behaving well; it has to be enforced where the agent cannot override it.
This is the difference between a boundary and a request. If the only thing stopping an agent from reading another client's data is a line in its prompt telling it not to, that is a polite request, and a model under pressure will eventually cross it, confidently. A permission set at the data layer is a boundary: the agent's token simply does not return another client's rows, no matter what the prompt says. The failure mode of relying on the prompt, where an agent mixes two clients and states the blended number as fact, is the same class of problem as why AI agents give different answers on the same data.
There are two documented patterns, and they trade maintenance for strength. Both start from the same non-negotiable: the client is a first-class dimension, present from the Raw layer through to the Service layer, never something you deduce afterward from a campaign name.
Around either pattern, three things are configured per client. Sources are connected per client, and a setup link can invite the client to fill in their own source credentials, so the agency never handles them. Permissions are assigned with roles and groups, at the level of layer, folder, table and volume, so access is data-level rather than honor-system. And the agent reaches the data over the MCP server with an access token whose scope is exactly the platform permissions it was granted, which is what makes one client's agent physically unable to read another's.
| What | Per client, isolated | Shared across clients |
|---|---|---|
| Data and tables | Each client's data, filtered by client or in its own layer | Nothing |
| Sources and permissions | Connectors and access scoped to that client | Nothing |
| Agent access token | Reads only the granted layers | Nothing |
| Learned rules | Applied to each client's own data | The pattern, as a written rule, not the data |
By writing the pattern down as a rule instead of leaving it in someone's head. An agency's real advantage was never the labor; it is breadth, having seen what works across many accounts a single in-house team never touches. The problem is that this breadth usually lives in the memory of analysts, gets re-discovered every time a new account runs the same test, and walks out the door when a person leaves. The agency keeps the logo and the contract and loses the expertise, which was never written anywhere.
A written rule changes that. When an agent learns something on one account, the pattern becomes a context document in the semantic layer: plain-language business rules, annotated to the concrete tables and columns they refer to, stored and versioned, read by the agent before it acts. A definition like what counts as an active customer, or the observation that one angle outperforms another for a type of account, persists because schemas change but definitions do not. The important part for an agency is that the rule is portable while the data is not: the same written pattern can inform the agent working on another client, applied to that client's own isolated layer, without a single row crossing between accounts. What used to depend on an analyst remembering to tell the team becomes an asset the agency owns. Attaching that meaning to the data itself is context engineering for AI agents, and the governed definitions it produces are a semantic layer for AI agents.
Each agent queries one client's layer and acts in that client's tools. The split is the same one that lets a small team run many agents without chaos: reading happens in one place, the governed layer, and doing happens in the source tool, which stays the source of truth for what it owns. The CRM remains the source of truth for the lead, the ad platform for the campaign; the agent calls that tool's API directly when it is time to execute, and queries the layer when it needs to know something.
For an agency this keeps each agent simple and safe. An agent knows one read source, its client's layer, and a few execution tools, rather than becoming an omniscient system that must understand every API across every account. Token cost stays down, because a deterministic query against the layer is far cheaper than paging a tool's API repeatedly, and scope stays tight, because the agent's access token is bound to one client. It is the same architecture as an AI-native GTM stack, now drawn per tenant, and running a paid-media agent this way, querying performance in the layer and acting in the ad platforms, is covered in how to run paid ads with an AI agent.
Nekt is a data platform that gives AI agents governed context, and multi-tenancy is a direct example of the three parts it covers, applied per client.
The result is that the agency's breadth stops being fragile. It learns from many clients at once, keeps each one's data isolated by a real control, and holds the learning as a written asset instead of in the memory of whoever might leave. See how Nekt works, or create a free account and connect your first source.
Yes. Either keep one model with the client as a first-class column and filter every query by client, or give each client its own layer, which is the top-level permission boundary. In both cases the agent's access is scoped so it reads one client at a time, and the semantic layer states the rule that every query is per client, so the model does not blend accounts.
With a permission at the data layer, not a line in the prompt. Access control is set per layer, folder, table and volume, and the agent reaches the data over an MCP server with a token scoped to exactly those permissions. An agent granted one client's layer cannot return another client's rows, regardless of what it is asked, because the boundary is enforced below the model.
Yes, because what you reuse is the rule, not the data. A pattern learned on one account is written as a context document in the semantic layer, versioned and annotated to the data it describes. That rule can inform the agent working on another client, applied to that client's own isolated layer, without any row crossing between accounts. The learning is shared; the data stays separate.
