Investor brief · Agentforce intake

Patient intake on Salesforce Agentforce + Service Cloud

Pause-Health.ai's patient intake runs on Agentforce Service Agent inside Salesforce — the substrate that most US health systems and payers already operate. The public prototype shows the experience; provider deployments are the real thing.

Why Agentforce

Where our customers already live

Salesforce Health Cloud is deployed across the majority of US health systems and large payers. Building Pause intake on Agentforce means our intake artifacts land where the rest of the patient record already lives — no new console, no new identity, no new audit trail to defend.

GA today, on Enhanced Chat v2

Salesforce Embedded Messaging for Web (inline mode) is general-availability and is the surface most of our pilot customers already license. We use the documented Embedded Service Deployment snippet — same pattern Salesforce ships in their public dev guide.

Topics + Actions instead of prompt soup

Agentforce Service Agent organizes intake as topics (e.g. Symptom Capture, Red-Flag Screening, Consent) with structured actions. Each action writes typed fields to the FHIR record. This is what makes our intake auditable in a way a raw LLM chat is not.

Compliance posture inherited

HIPAA-eligible Salesforce orgs come with audit logging, field-level encryption, region-pinned data residency, and SAML SSO. We inherit those controls instead of re-implementing them.

Prototype vs production

The public prototype at /demo/intake renders a Pause-branded scripted intake by default. The same page automatically upgrades to a live Agentforce Service Agent once the four deployment env vars are set. The surrounding layout, the structured-record handoff, and the clinical triage rules are identical across both modes.

Aspect	Public prototype	Provider deployment
Public prototype experience	Pause-branded scripted intake (a local TypeScript state machine).	Real Agentforce Service Agent backed by Service Cloud topics + actions.
Data destination	Component state only. No PHI captured.	FHIR R5 Observations + Salesforce Health Cloud Person Account, both in the customer-controlled tenant.
Conversational logic	Hand-written script (lib/intake-script).	Agentforce topics + actions, with deterministic guardrails for red flags and consent.
Identity + audit	None — anonymous browser session.	SSO-backed patient session; full Salesforce audit trail.
Switch trigger	Default when NEXT_PUBLIC_AGENTFORCE_* env vars are unset.	All four NEXT_PUBLIC_AGENTFORCE_* env vars (orgId, deploymentName, siteUrl, scrt2Url) set in Vercel.

Setup checklist (provider deployment)

1. Provision the Salesforce org

Service Cloud edition that includes Messaging for In-App and Web. Confirm with the Salesforce account team that Agentforce Service Agent is licensed.

2. Build the Agentforce Service Agent

Create the agent in Salesforce Setup. Define topics for Symptom Capture, Cycle Status, Red-Flag Screening, Consent. Wire actions that write structured fields to a custom Pause object (or Person Account).

3. Create the Embedded Service Deployment

Setup → Embedded Service Deployments → New. Channel: Messaging for Web. Bind to the agent from step 2. Save and click Code Snippet.

4. Capture the four config values

From the Code Snippet panel, copy: Org ID (first init arg), Deployment API Name (second), Site URL (third), scrt2URL (in the options object).

5. Set Vercel env vars

Set NEXT_PUBLIC_AGENTFORCE_ORG_ID, _DEPLOYMENT_NAME, _SITE_URL, _SCRT2_URL on the Pause Vercel project. Redeploy. The prototype intake page now renders the live agent automatically.

6. Validate the round trip

Run a test intake. Confirm the structured record appears in Salesforce. Confirm consent + red-flag actions fire correctly. Wire the FHIR write-back to JupyterHealth Exchange via our existing pause_ingest worker.

Guardrails

Public values onlyAll four env vars are public deployment metadata. They ship in the Salesforce-provided snippet by design and do not grant API access. We do not store any Connected App secrets, refresh tokens, or Frontdoor URLs in the frontend.
No PHI in the public prototypeThe fallback intake runs entirely in browser memory and is reset on page reload. It exists to convey the experience, not to capture real patient data.
Salesforce trademarks used only descriptivelyThe investor narrative references Agentforce and Service Cloud by name because that is the technical substrate. We do not use the Salesforce logo, the Astro mascot, or any Salesforce visual marks in patient-facing surfaces unless and until a co-marketing agreement is in place.
Provider org isolationEach provider customer points the env vars at their own Salesforce org. Pause does not centralize patient conversations through a Pause-owned org.

Strategic fit

Procurement velocity"Runs on your existing Salesforce" is the fastest possible answer to a security review. We are adding capability to a substrate the customer already trusts, not introducing a new vendor for the data plane.
Operational alignmentSalesforce is where the customer's care coordinators already work. Routing exceptions and follow-up tasks flow through queues those teams already manage.
Compounds with our other choicesSalesforce on the front, FHIR + JupyterHealth on the back, DBDP for wearables, our menopause model in the middle. Every piece is the best-in-class open substrate for its role.

Read deeper

JupyterHealth integrationWhere the Agentforce intake hands its structured record back to the FHIR substrate.
MuleSoft integrationHow the intake's consent decisions and structured record propagate into JupyterHealth, the DBDP feature pipeline, and any downstream systems via the customer's Anypoint platform.
MCP serverIn production, the Agentforce Service Agent consumes the Pause MCP server to call get_patient_timeline, get_patient_intake, and find_menopause_providers as native tools.
Multi-agent control planeThe Agentforce intake hands off over Google A2A to the Anthropic Care Router; the whole multi-agent flow is governed and traced by the MuleSoft Agent Fabric.
Data 360 groundingEvery intake is resolved to a unified Data 360 patient id and enriched with longitudinal context before the Care Router decides.
Technology choicesFull stack rationale, including why Salesforce is the right front door.
Try the prototypeSee the scripted intake (and, where configured, the live agent) end-to-end.
Salesforce: Inline Mode in Enhanced Chat v2The Salesforce dev guide we follow for the embedded mount.