Inside AI Crew's Field Service Agent: One AI per End Customer

Summary: Industrial chemical distributors face a structural bandwidth wall: one distributor representative typically supports 20 to 40 active end customers, while end customers expect quote, technical data sheet (TDS), and order-status responses within minutes rather than next business day. Lubinpla AI Crew now ships a Field Service Agent feature that gives every end customer their own dedicated AI counterpart inside the distributor's workspace, so the end customer can ask quote, TDS, and order-status questions directly and receive responses grounded in documents the distributor has shared with that customer specifically. The article describes what the Field Service Agent does, how its document architecture separates shared, customer-specific, and internal folders, how the external-visibility toggle on every document and folder controls reach, and why the containment promise (one competing customer cannot see another customer's data) is structural rather than policy-based. It also walks through the end-customer onboarding flow (invite link to live AI in three steps) and the operational impact for the distributor's internal team (less repetitive inbound lookup, more capacity for live sales work). For information-security context the article cites ISO/IEC 27017:2015 for cloud-tenant segregation, ISO/IEC 27018:2025 for personally identifiable information (PII) handling in public clouds, GDPR Articles 5 and 25 for purpose limitation and data protection by design, and NIST SP 800-53 Revision 5 access control families for the access-enforcement language used. The article does not include performance or accuracy figures: where benchmarks are needed they are drawn from published industry distribution and customer-service surveys, not from Lubinpla product telemetry.

Table of Contents

I. One Distributor Rep, 30 End Customers, The Bandwidth Wall

II. What End Customers Can Now Do: Direct Quotes, TDS, Order Status Inquiry

III. Document Architecture: Shared, Customer-Specific, and Internal Folder Boundaries

IV. The External-Visibility Toggle: Decide Once, Apply Forever

V. The Containment Promise: Why Competing Customers Cannot See Each Other's Data

VI. End Customer Onboarding: Invite Link to Live AI in Three Steps

VII. Distributor Internal Impact: Less Repetitive Lookup, More Real Sales

VIII. Key Takeaway

IX. References

I. One Distributor Rep, 30 End Customers, The Bandwidth Wall

Industrial chemical distribution runs on a one-rep-to-many-customers staffing pattern that has not changed since the catalog era, yet end-customer response expectations have collapsed from next business day to inside the hour. Reps absorb the gap by doing the same lookups repeatedly: last quoted price, latest TDS revision, current order status. The Field Service Agent is the response to that specific bandwidth wall.

Lubinpla is an industrial chemical artificial intelligence agent company that provides AI Shooting (per-case industrial chemistry analysis) and AI Crew (an AI agent subscription for technical sales, customer support, and operations workflows). AI Crew has been used to date inside the distributor's own staff workspace. The Field Service Agent extends AI Crew so that the distributor's end customers also get a counterpart agent of their own, without the distributor having to staff a second-tier support desk.

Why the math forces a structural change

Sales representatives spend approximately 30 percent of their time on revenue-generating activity and roughly 70 percent on administrative and internal tasks, with administrative work consuming about 41 percent of a representative's day (Everstage, 2026). When one distributor representative carries 20 to 40 active end customers, the repetitive inbound load (quote refresh, TDS revision check, order status) is what fills that 70 percent. Reducing the repetitive load is the only way to recover selling capacity without adding headcount.

End-customer expectations have moved in the opposite direction. Approximately 61 percent of business-to-business (B2B) buyers prefer a rep-free buying experience for routine interactions, and 100 percent of B2B buyers want to self-serve at least part of the buying journey (Gartner, 2025). A distributor that forces every routine inquiry through a human representative is now actively friction-creating for two thirds of its own customer base.

Why a shared chatbot is the wrong answer

The obvious response, a single shared portal chatbot trained on the distributor's full document library, breaks on the first multi-customer interaction. End Customer A and End Customer B may both buy from the same distributor but compete with each other, or hold confidential terms that the other should never see. A chatbot that can answer "what is my last quoted price" must also be unable to answer that question for someone else's account, and that unable must be enforced at the data layer, not at the prompt layer. The Field Service Agent is built around that constraint.

Figure 1. Distributor Inbound Load Distribution (illustrative)

Inquiry type	Approximate share of inbound	Resolution path before Field Service Agent	Resolution path after
Order status lookup	High	Rep checks ERP, replies by email	End customer's AI counterpart pulls from shared order-status folder
TDS / SDS revision request	High	Rep finds latest revision, attaches file	End customer's AI counterpart returns latest revision linked to that customer
Standard product quote refresh	Medium	Rep checks last-quoted price, replies	End customer's AI counterpart drafts a quote using that customer's pricing folder
Custom formulation question	Low	Rep escalates to product manager	Routed to distributor staff (no change)
Complaint or claim	Low	Rep escalates to QA / leadership	Routed to distributor staff (no change)

The high-frequency, low-judgement inquiries are exactly what an AI counterpart with the right document scope can resolve; the high-judgement inquiries still route to humans by design. Lubinpla does not publish per-customer telemetry.

II. What End Customers Can Now Do: Direct Quotes, TDS, Order Status Inquiry

The Field Service Agent gives each end customer a chat-style AI counterpart inside a workspace the distributor controls. The counterpart answers quote refresh, technical data sheet (TDS) requests, safety data sheet (SDS) requests, and order-status inquiries using only documents the distributor has explicitly made visible to that customer. There is no public web chatbot and no broadcast bot; each counterpart is bound to exactly one end customer.

Why these three job functions and not others

Quote refresh, technical document delivery, and order status are the three highest-volume, lowest-judgement requests in distribution inbound, and the source of truth for each is a structured artifact the distributor already maintains (price-list line, versioned datasheet, order-tracking record). The agent locates and presents existing artifacts; it does not generate prices or specifications. Custom formulation, claim handling, contract negotiation, and pricing exceptions route to distributor staff because their source of truth is a human conversation, not a static artifact.

How a request flows end to end

When an end customer types "do you have the current TDS for product X", the agent receives the message, scopes the search to that customer's permitted document set (shared library plus that customer's own folder, with the distributor's internal folder excluded), retrieves the latest version of the TDS file, and returns it with the version date and a link. If the latest TDS is not yet visible to that customer (for example, a new revision is still under distributor review), the agent returns the previously published revision and notes that a newer revision is pending. The agent does not synthesize content that is not in the source documents.

What the agent will not do

The agent will not negotiate price, commit delivery dates, or state legal liability, warranty terms, or compliance commitments on behalf of the distributor. These boundaries are encoded in the agent's instruction layer and reinforced by the Critic evaluation step that every external-facing draft passes through before reaching the end customer.

III. Document Architecture: Shared, Customer-Specific, and Internal Folder Boundaries

The Field Service Agent's containment rests on a three-tier document architecture: Shared, Customer-Specific, and Internal. The tier is a property of the folder, not of the user, which is what keeps the architecture stable as customers and reps come and go.

Shared library

The Shared library holds documents that every authorized end customer of the distributor may access: published TDS files, published SDS files, generic technical bulletins, distributor catalog pages, and similar non-confidential material. The distributor publishes once into the Shared library, and every end customer's counterpart agent reads from it. Versioning matters here: when a revision lands, every counterpart sees the same new revision at the same time, which removes the "the rep gave me an older version last month" support load.

Customer-Specific folders

Every end customer in the distributor's workspace has a dedicated folder. Inside it live that customer's own pricing line, that customer's negotiated terms, that customer's order history, that customer's compliance documents (for example, that customer's site SDS confirmations), and any one-off communication artifacts the distributor wants the agent to use for that customer only. The folder is named for the customer and is the only folder of its kind that this customer's counterpart agent reads. No other end customer's counterpart agent can read this folder.

Internal-only folders

Internal folders hold the distributor's own working material: cost prices, margin notes, supplier sources, internal training documents, reseller agreements, competitive intelligence, and personnel records. No end-customer counterpart agent reads from the Internal folder under any condition. Internal-only material is the default for new documents until the distributor explicitly promotes a document to Shared or files it under a specific Customer folder.

Figure 2. Document-Access Matrix (folder tier x persona x visibility)

Folder tier	Distributor staff (internal)	End Customer A counterpart	End Customer B counterpart	External-visibility toggle default
Internal	Read and write	Cannot read	Cannot read	OFF (locked)
Shared library	Read and write	Read	Read	ON
End Customer A folder	Read and write	Read	Cannot read	ON for A only
End Customer B folder	Read and write	Cannot read	Read	ON for B only

The combination of tier and toggle is what makes a given document reachable by a given counterpart agent. There is no fifth path: a document not in one of these tiers does not exist from the agent's perspective.

Why this is operationally stable

The architecture maps to how distributor staff already think about documents: "published datasheet" (Shared), "Acme's pricing letter" (Customer-Specific), "our cost sheet" (Internal). The Field Service Agent inherits that mental model rather than imposing a new one. The worst-case misfile (an Internal document dropped into Shared) is a single file move to repair, and the access audit captures it.

IV. The External-Visibility Toggle: Decide Once, Apply Forever

Every folder and document carries a single external-visibility toggle. ON makes the document reachable by counterpart agents whose scope includes that folder; OFF restricts it to distributor staff. The toggle is set once at the folder level and inherited by every artifact placed inside, so the operator does not re-decide per document.

Default-off, opt-in disclosure

New folders default to OFF (Internal-only). This is the deliberate inverse of the typical shared-drive pattern, in which everything is accessible until someone explicitly locks it down. Default-off matches the data-protection-by-design principle of GDPR Article 25, which requires that by default only personal data necessary for the specified purpose is processed (European Parliament, 2016). The same logic applies to commercial data: the default for any new artifact is internal, and disclosure to an end customer is the deliberate act, not the omission.

Inheritance and override

A document inside a folder inherits the folder's toggle. The operator may override a single document upward (more restrictive) but not downward (more permissive). In practice this means an Internal folder can contain an individually-Shared document (for example, a published bulletin filed inside the strategy folder for convenience), but a Shared folder cannot silently contain an Internal document. The override direction is intentional: the architecture refuses to let a more-permissive child override a more-restrictive parent, which is the failure mode that produces accidental leakage.

Audit trail

Every toggle change writes an entry to the access log: who changed the toggle, on which folder or document, at what time, in what direction. The log is read-only to operators and is the artifact a compliance auditor would inspect to verify that disclosure decisions are deliberate and traceable. This satisfies the audit and accountability expectations in NIST SP 800-53 Revision 5 access control family controls AC-2 (account management), AC-3 (access enforcement), and AC-5 (separation of duties), which together govern who may grant access, who enforces it, and who reviews the enforcement (NIST, 2020).

Figure 3. Containment Decision Flowchart (data class to routing to access toggle)

Step	Question	Answer = Yes	Answer = No
1	Is the artifact a published, non-confidential document (catalog page, generic TDS / SDS)?	File in Shared library, toggle ON	Go to step 2
2	Does the artifact belong to one specific end customer (their pricing, their order, their site-specific SDS)?	File in that customer's folder, toggle ON for that customer	Go to step 3
3	Does the artifact contain distributor internal data (cost, margin, supplier, personnel)?	File in Internal folder, toggle OFF and locked	Go to step 4
4	Is the classification still unclear?	Hold in Internal folder pending operator review	Do not promote to Shared until step 1, 2, or 3 resolves

The dominant operational risk is hurried misclassification when the operator faces a new artifact and is unsure. Step 4 makes the safe default explicit: when in doubt, stay Internal.

V. The Containment Promise: Why Competing Customers Cannot See Each Other's Data

The containment promise is that no end customer's counterpart can read another end customer's folder under any prompt at any time. This is enforced at the retrieval layer — scope is built from the customer identity at session start — not at the prompt layer, which is what distinguishes structural containment from policy containment.

What policy containment looks like and why it fails

Policy containment is the pattern in which one model has access to all customers' data and is told, in its system prompt, to only talk about the requesting customer's data. It fails on unanticipated phrasings, long conversations that drift the model from its instruction, or prompt-injection buried in user-supplied content. Shared-model, prompt-only isolation is the cheapest pattern and the most fragile (WorkOS, 2025; AWS, 2024).

What structural containment looks like

Structural containment treats each customer's data scope as a separate retrieval context bound to the authenticated end-customer identity at session start. The retrieval layer accepts only documents in (a) the Shared library and (b) that customer's own folder. Other customers' folders and Internal documents are not "denied"; they are simply not addressable. The agent cannot return what the retrieval layer does not surface.

This pattern is consistent with ISO/IEC 27017:2015 control CLD.9.5.1, which calls for segregation of customer data in virtual computing environments shared by multiple tenants (International Organization for Standardization, 2015), with the cloud-specific PII guidance in ISO/IEC 27018:2025 (International Organization for Standardization, 2025), and with the access-enforcement language in NIST SP 800-53 Revision 5 AC-3 and AC-4 (NIST, 2020).

Why this matters for competing customers

Distributors regularly serve customers that compete in the same downstream market. Customer A's quoted price, lead time, and term sheet are a specific competitive asset; a single line of A's pricing surfaced to B's counterpart through a clever prompt is both a lost commercial position and a possible breach of a confidentiality clause. Structural containment removes that class of failure from the agent's reach.

Figure 4. Policy Containment vs Structural Containment

Dimension	Policy containment (shared model, instructed)	Structural containment (per-customer scoped retrieval)
Where the boundary lives	In the system prompt	In the retrieval layer, bound to authenticated identity
Vulnerability to prompt drift	High	None (drift cannot widen retrieval scope)
Vulnerability to prompt injection	High	None on retrieval; standard injection defenses still apply to output
Audit complexity	Hard (must review every conversation)	Lower (review folder toggles and identity binding once)
Failure mode	Silent cross-customer leak	None at retrieval; output-side review catches the rest
Alignment to ISO/IEC 27017 CLD.9.5.1	Partial	Full
Alignment to NIST SP 800-53 AC-3 / AC-4	Partial	Full

The two patterns look identical on a normal day and differ catastrophically on the failure-mode day, which is the only day that matters.

VI. End Customer Onboarding: Invite Link to Live AI in Three Steps

The distributor onboards an end customer to their Field Service Agent counterpart in three steps that the end customer experiences as a single short flow. The distributor generates an invite, the end customer follows the link and verifies, and the counterpart agent is live in the end customer's workspace with that customer's scoped document set already in place. No software installation, no separate account creation outside the invite link, and no manual scope configuration.

Step 1: Distributor generates the invite

The distributor operator opens the end customer's record in the AI Crew workspace and issues a one-time invite link. The link encodes the customer identity, so the workspace does not need to ask the end customer to "find their account". When the link is generated, the end customer's folder is created (if it does not already exist) and the customer's pricing line and order history are filed into it. The distributor confirms the external-visibility toggle is ON for that customer's folder and OFF for everything else, per the document-access matrix in Section III.

Step 2: End customer follows the link and verifies identity

The end customer follows the invite link, confirms their email and organization, and lands in a workspace already labeled with their organization's name and the distributor's brand. The verification step uses standard email-based identity verification, consistent with the identification and authentication controls in NIST SP 800-53 Revision 5 IA-2 (identification and authentication for organizational users) and IA-4 (identifier management) (NIST, 2020). The end customer does not configure scope; scope is set by the distributor's existing folder structure.

Step 3: Counterpart agent is live

The end customer asks the first question. The agent retrieves from the Shared library plus that customer's own folder, returns the answer with the source document linked, and the session continues. The first session usually consumes one to two minutes of end-customer time. Subsequent sessions reuse the same workspace; no re-invitation is required unless the distributor revokes access. The distributor can revoke access at any time by toggling the customer's folder visibility OFF, which the agent enforces on the next session start.

Why three steps and not five

The flow was collapsed to three steps because 80 to 95 percent of B2B ecommerce projects underperform and roughly 65 percent of B2B platforms under-deliver after launch (Ringly, 2026), with extra onboarding steps the most common cited cause in distribution.

VII. Distributor Internal Impact: Less Repetitive Lookup, More Real Sales

The Field Service Agent's internal impact on the distributor's own team is that repetitive inbound lookup compresses, and the recovered hours route to live commercial work that an AI counterpart cannot do. The point of the feature is not "reduce headcount"; the point is "let the existing headcount do the work the headcount is for". Quote refresh and TDS lookup do not require a senior representative; closing a custom formulation discussion does.

What the distributor team stops doing

The distributor representative stops being the relay layer for routine inbound. They stop opening the order-status screen ten times a day. They stop attaching the same datasheet to fifteen different emails. They stop refreshing the same standard quote line for repeat orders. These tasks did not disappear from the world; they migrated to the end customer's counterpart agent, which has the documents it needs to answer them directly.

What the distributor team starts doing more

The representative starts doing the work that is genuinely commercial: introducing a new product line to a strategic account, walking a customer's QA team through a formulation change, negotiating a multi-quarter framework agreement, recovering a stalled customer, and prospecting into a new account. These are the activities where high-performing representatives spend 20 to 25 percent more time with customers than their peers (Everstage, 2026), and where the bandwidth recovered from repetitive lookup translates directly into closed business.

Why the distributor's internal documents are safer, not less safe

The documents an end-customer counterpart can read are exactly those the distributor already shares with that customer through email and manual delivery; the agent surfaces existing-permission documents on demand rather than exposing new ones. The previously-protected Internal documents (cost, margin, supplier, personnel) remain unreachable to every counterpart by structural containment, in line with ISO/IEC 27017:2015 CLD.9.5.1 (International Organization for Standardization, 2015) and NIST SP 800-53 Revision 5 AC-3 (NIST, 2020).

A note on purpose limitation

GDPR Article 5(1)(b) requires that personal data be collected for specified, explicit, and legitimate purposes and not further processed in a way incompatible with those purposes (European Parliament, 2016). The Field Service Agent's scope-by-identity design enforces this principle at the retrieval layer: documents in Customer A's folder are processed for Customer A's session, not for Customer B's session. Purpose limitation in the GDPR sense is a policy obligation in most systems; in the Field Service Agent it is also a retrieval invariant.

Figure 5. What Shifts in the Distributor Representative's Day

Activity	Before Field Service Agent	After Field Service Agent
Standard quote refresh	Rep prepares and sends	End customer counterpart drafts; rep reviews exception cases only
TDS / SDS delivery	Rep finds and attaches	End customer counterpart returns from Shared library
Order status inquiry	Rep checks ERP, replies	End customer counterpart returns from order-status entry
Custom formulation discussion	Rep handles	Rep handles (no change)
Strategic account development	Rep handles when time allows	Rep handles with recovered bandwidth

The shift is qualitative, not quantitative. Lubinpla does not publish a productivity uplift figure because the gain depends on the distributor's inbound mix and migration pace. The structural claim: the representative's day reallocates from relay work to commercial work in proportion to how much inbound sits in the first three rows.

VIII. Key Takeaway

• Every end customer of the distributor gets a dedicated AI counterpart inside the distributor's workspace, scoped to that customer's identity at the retrieval layer, not at the prompt layer. The scope is built into the data, not into the instruction.

• Documents live in one of three tiers: Shared library (every authorized end customer reads), Customer-Specific folder (only that customer reads), Internal folder (no end customer reads). The tier is a property of the folder, set by the distributor operator, and inherited by everything inside.

• The external-visibility toggle defaults OFF for new folders. Disclosure is the deliberate act. This is aligned to the data-protection-by-design principle in GDPR Article 25 and to the segregation control in ISO/IEC 27017:2015 CLD.9.5.1.

• Structural containment, not policy containment, is what makes the system safe to put in front of competing customers. The retrieval layer cannot return documents that are not in the customer's scope, regardless of how a prompt is phrased.

• End-customer onboarding is three steps: distributor generates invite, end customer follows link and verifies, counterpart agent is live with scoped document set. The flow was collapsed because B2B portal abandonment data identifies extra onboarding steps as the dominant adoption-failure mode (Ringly, 2026).

• The internal impact on the distributor's team is bandwidth reallocation from repetitive lookup to commercial work, where high-performing representatives already spend 20 to 25 percent more customer-facing time than their peers (Everstage, 2026).

See how AI Crew handles this workflow in your environment: https://www.lubinpla.com/ai-crew

IX. References

[1] Amazon Web Services. (2024). *Tenant isolation - SaaS Architecture Fundamentals*. AWS Whitepaper. https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html

[2] European Data Protection Board. (2019). *Guidelines 4/2019 on Article 25 Data Protection by Design and by Default* (Version 2.0). https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_en.pdf

[3] European Parliament and Council of the European Union. (2016). *Regulation (EU) 2016/679 - General Data Protection Regulation, Articles 5 and 25*. https://gdpr-text.com/read/article-5/

[4] Everstage. (2026). *Sales Productivity Statistics: Trends and Data for 2026*. https://www.everstage.com/sales-productivity/sales-productivity-statistics

[5] Gartner. (2025, June 25). *Gartner Sales Survey Finds 61 Percent of B2B Buyers Prefer a Rep-Free Buying Experience* [Press release]. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-sales-survey-finds-61-percent-of-b2b-buyers-prefer-a-rep-free-buying-experience

[6] Gartner. (2025, August 25). *Gartner Says By 2030 that 75 Percent of B2B Buyers Will Prefer Sales Experiences that Prioritize Human Interaction Over AI* [Press release]. https://www.gartner.com/en/newsroom/press-releases/2025-08-25-gartner-says-by-2030-that-75-percent-of-b2b-buyers-will-prefer-sales-experiences-that-prioritize-human-interaction-over-ai

[7] International Organization for Standardization. (2015). *ISO/IEC 27017:2015 - Information technology - Security techniques - Code of practice for information security controls based on ISO/IEC 27002 for cloud services*. https://www.iso.org/standard/43757.html

[8] International Organization for Standardization. (2025). *ISO/IEC 27018:2025 - Information security, cybersecurity and privacy protection - Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors*. https://www.iso.org/standard/27018

[9] McKinsey & Company. (n.d.). *Winning B2B customers in technology and telecommunications*. https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/winning-b2b-customers-in-technology-and-telecommunications

[10] National Institute of Standards and Technology. (2020). *NIST Special Publication 800-53 Revision 5 - Security and Privacy Controls for Information Systems and Organizations, Access Control (AC) family*. https://csrc.nist.gov/CSRC/media/Projects/risk-management/800-53%20Downloads/800-53r5/SP_800-53_v5_1-derived-OSCAL.pdf

[11] National Institute of Standards and Technology. (2020). *AC-5: Separation of Duties - NIST SP 800-53 Rev. 5*. CSF Tools. https://csf.tools/reference/nist-sp-800-53/r5/ac/ac-5/

[12] Redis. (2024). *Data Isolation in Multi-Tenant Software as a Service (SaaS)*. https://redis.io/blog/data-isolation-multi-tenant-saas/

[13] Ringly. (2026). *55 B2B ecommerce statistics you need to know in 2026*. https://www.ringly.io/blog/b2b-ecommerce-statistics-2026

[14] Sprinto. (2024). *ISO 27017 Explained: Cloud Security Controls, Scope and Certification Guide*. https://sprinto.com/blog/iso-27017/

[15] WorkOS. (2025). *The developer's guide to SaaS multi-tenant architecture*. https://workos.com/blog/developers-guide-saas-multi-tenant-architecture