Investor brief · Agentforce intake

Patient intake on Salesforce Agentforce + Service Cloud

Pause-Health.ai's patient intake is built to run on Agentforce Service Agent inside Salesforce — the substrate that most US health systems and payers already operate. The public prototype defaults to a scripted Pause-branded fallback; the live Agentforce agent activates when the four NEXT_PUBLIC_AGENTFORCE_* env vars are set in Vercel. See the environment table below for what each deployment actually serves.

Why Agentforce

Four reasons the front door is Salesforce

Pills: Shipped wired in the prototype today · Designed design decision, activates with the first design partner.

Designed

Where our customers already live

Salesforce Health Cloud is deployed across a large share 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. Pause is pre-design-partner, so this is the GTM thesis, not a customer deployment in production yet.

Shipped

GA today, on Enhanced Chat v2

Salesforce Embedded Messaging for Web (inline mode) is general-availability and is the substrate prospective design partners already license. We use the documented Embedded Service Deployment snippet — same pattern Salesforce ships in their public dev guide. Wired in the prototype: components/agentforce-embed.tsx mounts it when the four env vars are present.

Designed

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. The dev-org agent (Pause_Health_Intake_Agent) has the topic skeleton; production-grade action wiring lands with the first design partner.

Designed

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. Inherited posture only counts once we deploy into a customer org; today we run against a Trailhead Playground for development.

Where the live agent is wired

What each deployment actually serves

The live Agentforce Service Agent path is activated by four NEXT_PUBLIC_AGENTFORCE_* env vars (ORG_ID, DEPLOYMENT_NAME, SITE_URL, SCRT2_URL). When all four are present, /demo/intake mounts the real Salesforce Embedded Messaging for Web bootstrap and runs the Pause_Health_Intake_Agent in our dev org. When any one is missing, the page falls back to a Pause-branded scripted intake (components/agentforce-fallback.tsx) so the experience renders end-to-end without credentials.

Environment	AGENTFORCE env vars	Active intake path
Local dev (founder's machine)	Set in `frontend/.env.local`	LIVE Agentforce Service Agent (real Salesforce dev org)
Vercel preview / production (`pause-health.ai`)	Deliberately unset	Pause-branded scripted fallback (shape-identical to live path)
Investor demo session	Temporarily set in Vercel, then unset after	LIVE for the duration of the demo

Why the public site is fallback-by-default: the connected dev org is a Trailhead Playground (not production-grade), and routing public intake traffic at it would (a) exhaust its API limits, (b) create unbounded demo conversation records, and (c) tie investor demo quality to whoever last did a write against the agent. The scripted fallback is clinically realistic and conveys the same experience without any of those risks. The first paying customer brings their own Salesforce org and their own env vars (Path: the six-step setup checklist below).

Touch the architecture

Three live surfaces you can hit right now

Even when the live agent is gated off, the surrounding Pause architecture is fully wired in the prototype and inspectable in one click.

Open the prototype intake →Care Router A2A descriptor →Sample prechat context →

Prototype vs production

What changes when the env vars are set

The surrounding layout, the structured-record handoff scaffolding, and the clinical triage rules are identical across both modes — only the chat surface and the data destination differ.

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

The six steps to a live customer deployment

Planned The entire checklist runs end-to-end with the first design partner.

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

What we are deliberately not doing

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

Why this front-door choice compounds with the rest of the stack

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 choicesThe stack we are building toward: Salesforce on the front, FHIR R5 + JupyterHealth on the back, DBDP for wearable feature engineering, our menopause model in the middle. Each piece is the best-in-class open substrate for its role — see technology choices for the layer-by-layer status pills.

Read deeper

Where Agentforce sits in the bigger picture

Headless 360 — where Agentforce fitsToday · partialAgentforce embedded chat is one of three patterns in Salesforce's Headless 360 architecture (TDX 2026). The audit page maps every Pause surface — REST + MCP + A2A — onto the patterns, with honest pills on every row.
Data 360 groundingWired in prototypeEvery intake is resolved to a unified Data 360 patient id and enriched with longitudinal context before the Care Router decides. The Phase 1 LIVE grounding path is wired in the prototype against a real Health Cloud org.
Multi-agent control planeToday · partialIn a customer deployment, the Agentforce intake hands off over Google A2A to the Anthropic Care Router; the whole multi-agent flow is governed and traced by the Agent Fabric. Today the fabric runs as an in-memory trace plane in the prototype (see /demo/agent-fabric).
JupyterHealth integrationDesignedWhere the Agentforce intake hands its structured record back to the FHIR R5 substrate. Today the integration is design-doc + reference flow; first end-to-end ingest lands with the first design partner.
MuleSoft integrationDesignedHow the intake's consent decisions and structured record will propagate into JupyterHealth, the DBDP feature pipeline, and downstream systems via the customer's Anypoint platform. Today: mocked Experience APIs at /api/mulesoft/*.
MCP serverWired in prototypeProvider lookup is already live: on the trailsignup org the Pause_Health_Intake_Agent has a "Find a Provider" subagent that calls findMenopauseProviders as a native Agentforce action via an External Service + Named Credential over /api/mulesoft/providers (verified GROUNDED in Preview — routes, calls with zip/menopause=true/limit=3, returns real NPPES-derived MSCP clinicians). The MCP server is the future consolidation, now wired both ways: stdio (npx @pause-health/mcp; private:true today, npm-published in Phase 1) for Claude Desktop / Cursor, AND Streamable HTTP at https://pause-health.ai/api/mcp for Agentforce 3.0 Registry intake (Setup → Agentforce Registry → New MCP server → paste the URL → allowlist the four tools → land in the Asset Library → attach to a Topic in Builder).
Technology choicesFull stack rationale, including why Salesforce is the right front door — each layer status-pilled and cross-linked to the architecture brief that owns it.
Try the prototypeSee the scripted intake (and, where configured, the live agent) end-to-end. Public deployments default to the scripted fallback by design — see the environment table above.
Salesforce: Inline Mode in Enhanced Chat v2The Salesforce dev guide we follow for the embedded mount.