B2B and B2C in the same stack: when to separate agents and connections

In 60 seconds: Separate B2B and B2C when their sources of truth, permissions, channels, or human owners differ. Two CRMs can provide a useful starting boundary, but only if the agent uses separate credentials, connectors, and indexes. If both sides converge in a shared back office, publish a view or API for each audience: the B2C agent should never receive B2B table names, fields, or results. The prompt can guide behavior; the barrier belongs in the data and tool layer. One agent may be enough when policies are compatible and every request receives a bounded toolset based on the user’s identity. Before production, test instruction injection, cross-audience searches, logs, permissions, and human handoffs.

A company may sell complex contracts to businesses while also serving direct consumer purchases. The B2B CRM holds accounts, opportunities, negotiated terms, and sales owners. The B2C environment handles orders, campaigns, support, and contact preferences. Both eventually consult inventory, billing, or product data in the same back office.

The problem begins when one agent configuration can reach both sides. A legitimate support question could pull in a commercial note that does not belong to that consumer. A retrieved document could contain a malicious instruction intended to change the agent’s behavior. A long conversation history could carry context from one audience into the next session.

OWASP lists prompt injection and sensitive information disclosure among the risks for applications built with language models. The impact depends on the data and actions available to the application. Keep data and tools the audience does not need out of reach, even when the prompt already tells the agent whom it serves.

Separation starts at five boundaries

Our guide to one generalist or several specialized agents compares context, cost, latency, and maintenance by function. The boundary here is different. Two agents may perform the same task, such as finding a product or preparing a reply, and still need separation because they serve populations with different data and policies.

Boundary	Design question	Signal to separate
Audience	Who is making the request, and what relationship do they have with the company?	A consumer should not appear in B2B account searches, or vice versa
Permissions	Which records, fields, and actions does this identity need?	One audience needs terms, notes, or write access that the other must not receive
Source of record	Which system decides the state of the customer, order, or opportunity?	B2B and B2C use different CRMs, schemas, or resolution rules
Channel	Where does the interaction enter and leave?	Each channel has its own templates, consent, hours, or owners
Human ownership	Who reviews an exception, and who may approve an action?	Different teams are accountable for errors, escalations, or commitments

Not all five boundaries have to differ. If only the response tone changes, an audience-specific template may be enough. If permissions or the source of record changes, the separation should exist outside the prompt.

Two CRMs help, but they do not guarantee isolation

Existing silos are a useful starting point. A sales CRM and a consumer CRM already have different data models, owners, and change cycles. They can become natural boundaries through:

• one service identity per CRM instead of a shared account with global access
• one connector and allowlist of operations per audience
• separate search indexes with independent ingestion and deletion processes
• logs that show which identity queried which source for a given request
• review queues routed to the team that owns the process

The isolation disappears when both connectors use the same administrative credential, when every document lands in one index without enforceable filters, or when the agent can query an intermediate database containing both populations. It also disappears when someone pastes B2B data into a B2C conversation. A technical boundary cannot correct an incompatible operating practice.

The NIST definition of least privilege restricts each user or process to the resources and authorizations needed for its task. In this design, the B2C agent should operate as an actual B2C identity. A label in its instructions does not replace that identity.

One connector per audience creates an enforceable policy

A connector does not have to mean two products or two full deployments. It can be the same integration platform with two independent configurations. Each configuration should define:

• its credential and authorized audience
• the available read and write operations
• the fields that may enter and leave
• mandatory filters that the model cannot remove
• volume and time limits
• an owner, alerts, and a revocation procedure

Tools should express business intent. find_b2c_order can accept an order identifier and the consumer’s verified identity. find_b2b_opportunity can require an account and sales owner. A generic tool such as query_database(sql) asks the model to resolve authorization and database access at the same time, exposing a much larger surface.

The application must check permissions on every call. The model may choose the wrong tool or receive content designed to persuade it to do so. OWASP notes that RAG and model fine-tuning do not fully mitigate prompt injection. Connector credentials, allowlists, and validations still apply when the model’s instructions change.

How to share the back office without sharing its schema

Inventory, products, or billing often live in a common system. Duplicating that system for each audience can create inconsistencies and more maintenance. A better option is to publish separate access contracts over the same back office.

Consider these two views:

B2B surface	B2C surface
Availability by warehouse and promised date	Public or direct-to-consumer availability
Authorized price list and terms for the account	Current consumer price and channel promotion
Order status linked to an account	Order status linked to the verified consumer identity
Reference to the responsible account executive	Reference to the support or self-service path

The service layer applies row and column filters, validates identity, and returns a minimal result. The B2C agent receives no access to the table catalog, B2B schema, or an exploration tool. It does not need to “know not to” query a B2B table because that table is absent from its tool vocabulary.

Some data can remain shared, such as a public product sheet. In that case, keep one approved source for both audiences and separate only the restricted attributes. Our guide to building a technical assistant without exposing sensitive data covers document classification, filtered retrieval, and source provenance.

Logs need boundaries too. A debug record that copies full prompts, complete results, and access tokens can recreate the mixture the architecture was meant to prevent. Record identifiers, policy version, tool, operational outcome, and access decision. Retain content only when necessary, with defined permissions and retention.

When one agent remains reasonable

Separation increases the number of identities, configurations, evaluations, and escalation paths. Two agents may share infrastructure, model provider, deployment, and observability, but someone must maintain their contracts and check for unintended divergence.

One agent can work when:

• the person’s identity is verified before context is assembled
• the application decides which toolset to provide for each request
• both audiences share policies and a source of truth for that specific task
• memory is limited to the authorized conversation or account
• tests cover audience changes, ambiguous data, and out-of-scope tool calls

For example, a read-only agent may answer from a public catalog and retrieve an order status through a tool that verifies identity. It does not need two personalities if it never receives B2B data and the application does not expose B2B tools in that session.

Separation becomes more valuable when one execution would otherwise need simultaneous access to both domains, when one audience has write access and the other does not, or when teams must approve and evaluate changes independently. The cost includes development, secret management, monitoring, and support. The risk of one stack includes the reach of a credential, the amount of accessible data, and the number of cases an error can affect before detection.

Assign a control level to every action

Audience separation does not decide how much autonomy an agent receives. A B2B agent might read opportunities, propose follow-up, or send a message. These actions have different consequences. The same is true of returns, address changes, or cancellations in B2C.

The five control levels help assign read, recommend, draft, approved execution, or bounded autonomy to each operation. Correct data separation does not make an irreversible action safe. Audience limits and execution limits should be designed separately and tested together.

The CRM should retain commercial state, ownership, and the next step. The channel carries the conversation. Our article on the CRM as the source of record describes this division and prevents a messaging history from becoming a second, ungoverned database.

Pre-production checklist

Identity and permissions

• Each audience uses its own service identity and credentials.
• Tools expose only the required operations and fields.
• The API or data layer applies filters instead of relying on the prompt.
• A tested procedure can revoke one side without stopping the other flow.

Context, knowledge, and memory

• Indexes and ingestion processes preserve audience classification.
• Memory is scoped by user, account, audience, and authorized duration.
• Documents and messages are treated as untrusted content.
• A missing source produces a bounded answer or handoff, not a wider search.

Leakage tests

• Cases request names, records, and terms from the other audience.
• Tests include malicious instructions in messages and retrieved documents.
• Identity changes during a conversation verify that context is rebuilt.
• An evaluation fails if the response reveals data, confirms its existence, or calls an out-of-scope tool.

Logs and operations

• Every call records identity, policy, connector, result, and correlation without copying secrets.
• Alerts detect repeated denials, unusual queries, and volume spikes.
• The team can trace a response to its sources and configuration version.
• Log and conversation retention has an owner and review date.

Human handoff

• Every exception has a queue, owning team, and SLA.
• The handoff shares the minimum necessary context and preserves the original audience.
• A person can correct the record in the source of truth.
• The incident procedure can pause one connector without blocking the other.

Kiia can map sources, identities, connectors, and owners before deciding how many agents to deploy. Our systems integration approach starts with an access matrix and real exception cases. That map shows where infrastructure can remain shared and where to place a boundary that the model cannot expand.