The Agentforce architecture Salesforce said couldn't be built.

The Business Problem

The client operates in a B2B2C support model. Customers don't contact the manufacturer directly. A product fails, the customer contacts the retailer, the retailer emails the manufacturer's support team with receipts, photos, and warranty details.

Before Cloudsheer, the workflow was entirely manual. Roughly twelve thousand inbound emails per month, all manually triaged. Every case required manual data entry. Warranty validation depended on human lookup. Customers waited around fourteen hours for a first response. Average handling effort before a case even existed was eight minutes per email. Warranty validation took six minutes of manual lookup on top of that.

The support team faced two completely different interaction patterns on the same channel:

• Vendors sent structured submissions like receipts, invoices, customer details, and photos. That work needed structured extraction.
• End customers sent incomplete conversations with missing order numbers, missing product details, and partial warranty data. That work needed conversational slot-filling.

One monolithic agent couldn't do both well. A specialized pair of agents coordinated by a dispatcher could. That dispatcher architecture is exactly what Salesforce said couldn't be built reliably.

What Salesforce Said

When the client first scoped this build with Salesforce Support and Solution Engineering, the response was direct. The architecture wasn't supported. It wasn't recommended. It shouldn't be attempted on Agentforce.

The objections were structural. Salesforce believed these patterns would fail:

• A coordinated three-agent topology with programmatic dispatch between agents.
• A custom Foundation Layer using direct ConnectApi.EinsteinLlm execution outside standard declarative Agentforce patterns.
• Grounding an LLM against an unstructured Excel ContentDocument for live warranty validation.
• Operator-controlled "Trap Doors" that let humans bypass AI execution on demand.
• Stable recovery from nested call chains: Dispatcher to Apex to Specialist back to Dispatcher.

The client brought the problem to Cloudsheer. We built every piece Salesforce said couldn't be built natively, on-platform, while keeping the Einstein Trust Layer fully intact. And we shipped it in eleven weeks.

Architecture

We designed the platform as four cooperating layers. Each layer represented a piece of the "not possible" answer.

1. Multi-Agent Routing. Dispatcher routing to a B2B Specialist or B2C Specialist.
2. Apex Invocables. ThreadAnalyzerAction and ParsePromptResponse.
3. Apex Core. IntentDetectionService, CaseDataExtractionService, EmailCommunicationService, CustomerRecordService, and PromptService.
4. Foundation Layer. ConnectApiWrapper executing live against ConnectApi.EinsteinLlm.

The Foundation Layer

This was the layer Salesforce Solution Engineers were most skeptical about. Instead of relying only on declarative Prompt Templates, we built a dedicated Foundation Layer that directly communicates with the Einstein LLM.

• ConnectApiWrapper owns all live LLM execution. It is a centralized, fully audited execution path.
• PromptService standardizes payload structure and ensures consistency across every AI interaction.

Every request flows through this layer: intent classification, summarization, warranty validation, and email drafting. In production, mean LLM latency runs under 1.4 seconds. Fast enough that customer interactions feel instant.

The Three Agents

The Dispatcher is the entry point for every interaction. It handles conversation routing, escalation orchestration, vendor and customer classification, and safety validation before delegation. A custom metadata-driven lookup identifies vendors, customers, and registered domains. More than one hundred vendor domains are now classified with 100% deterministic accuracy. No model guessing required.

The B2B Specialist is purpose-built for structured ingestion. It handles:

• Case operations scoped to vendor portfolios.
• OCR and LLM receipt extraction.
• Attachment parsing.
• Predictable JSON normalization.

Vendor receipt processing runs end-to-end in under four seconds.

The B2C Specialist is purpose-built for conversational support and slot-filling. Its capabilities include:

• Warranty validation.
• Product Q&A.
• Manual retrieval.
• Case history retrieval.

Seventy-eight percent of customer interactions now resolve in a single contact without human involvement.

Grounding Against an Excel Document

The client's warranty master existed entirely inside an Excel file. Not a custom object. Not a database table. An Excel document.

We intentionally avoided forcing unnecessary migration work onto the business. Instead, the system loads the ContentDocument directly and grounds the LLM against it in real time. The AI returns a deterministic result of either covered or expired. Manual lookup used to take six minutes per case. Autonomous validation now runs in three seconds with a 99.4% match rate against the source-of-truth catalog.

Salesforce said this couldn't be grounded reliably against free-form Excel data. In production, it works at scale.

The Apex Core

A major part of the engagement involved decomposing monolithic Apex into focused services. Each service does one job, uses one prompt, and follows one execution path:

• IntentDetectionService, backed by Intent_Classifier.
• CaseDataExtractionService, backed by Generate_Case_Summary.
• EmailCommunicationService, backed by Draft_Email_to_customer.
• CustomerRecordService, for customer matching and record creation.
• PromptService, for centralized prompt execution.

The result was roughly 1,800 lines of brittle Apex retired.

The Trap Door Pattern

Most AI guardrails rely entirely on automated fallbacks. We added something different: manual operator kill switches. Two critical invocables, ThreadAnalyzerAction and ParsePromptResponse, include admin-controlled Trap Doors.

If automation becomes unsafe:

• The AI step is bypassed.
• The case routes directly to a human.
• Routing completes in under five seconds.

This wasn't exception handling. It was intentional operator control by design.

Guardrails

Salesforce specifically flagged the nested orchestration chain as unstable. We hardened the system across four layers:

• Pre-delegation safety validation on every agent handoff.
• UUID crash protection inside ApexAgentUtils.cls.
• Einstein Trust Layer enforcement on all grounding and policy checks.
• Operator Trap Doors on every critical invocable.

Since launch, the system has logged zero user-facing errors.

Testing

Production-grade agent systems require real testing infrastructure. Most Agentforce implementations skip this entirely. We shipped:

• IntentWrapperMock.
• Reusable mock frameworks.
• Universal Apex harness coverage.
• Regression coverage across every named agent path.

The result was 94% Apex test coverage at deployment.

The Impact

The Takeaway

Salesforce Support told the client this architecture wasn't possible on Agentforce. Cloudsheer built it anyway. The platform now handles twelve thousand cases per month, resolves 92% autonomously, operates with operator-grade controls, and runs fully inside Salesforce. All delivered in eleven weeks.

If your Agentforce roadmap is stuck behind a "not possible" answer, that's usually where Cloudsheer starts.Cloudsheer Consulting

Want a build like this? Book a 30-minute architecture call.

Read more stories from the team.