Day 13/15 — Headless 360 + Agentic AI Architecture

Three requests land on Arjun's desk in the same week. Sales wants Neha's assistant in Slack as well as in the browser. The service team wants an agent that works through Acme Global Tech's open cases, starting with "Sync errors after upgrade". And the CIO wants to know whether the new account-review app should be React running on Salesforce or a Next.js app the web team hosts outside it.

With Salesforce Headless 360 (now called AIforce), which opens the platform to agents through APIs and Model Context Protocol (MCP) tools, each request could be demoed in an afternoon. Each could also become a system nobody can debug, secure or pay for six months later. The difference is architecture: how many agents, which tools, which runtime, where the interface lives, and whose identity every call carries.

By the end of today you will be able to pick an agentic pattern for a Salesforce use case, place Agentforce, external agents and the beta Headless 360 MCP Server in it, choose between native React and an external Next.js app, and record the decision in an architecture decision record (ADR) for Acme.

On Day 12 we published Acme's business rules as custom MCP tools. Today we zoom out from one tool to the whole system. Headless 360 opens many doors into the platform; this is the day you decide which ones to open, and for whom.

Three agentic patterns

In this series an agent is a model that decides, in a loop, which tools to call on someone's behalf. I work with three patterns, and I adopt them in this order.

Single assistant

One model, one user, one conversation and a small, curated set of tools. Neha's meeting brief from Day 10 and the Day 15 capstone follow this pattern: Claude Sonnet 5.5 with sobject-all (write tools switched off, or off until she approves one) and the HeadlessAssistantTools custom server. Everything that happened is in one transcript, and every call runs with Neha's permissions. The limit is breadth. Salesforce's own guidance is that "Beyond a few dozen tools, an AI client struggles to select the right one for a given task", so a single assistant stays focused on one job.

Planner with tools

Some tasks have many steps across a large surface: "set up a new sales rep, assign the right permission sets, then create the named credential for the pricing service." A planner breaks the task down and calls tools in sequence, often discovering them as it goes. Two Salesforce servers already work this way. The beta Headless 360 MCP Server puts five tools in front of a library of operations, and the Data 360 MCP Server exposes Data 360's Connect API through three meta-tools, search, payload_examples and execute. You get reach without loading hundreds of tool definitions, at the price of longer loops, more calls per task and a larger blast radius per session.

Multi-agent handoffs

Here separate agents own separate domains, each with its own instructions, tools and owner, and a coordinator hands work to them. With MCP, a handoff can simply be a tool call. Salesforce's Summer '26 guide lists "Agentforce: Expose Agentforce agents ... as MCP tools" among custom tool types, with one condition: "Only agents created with the new Agent Script Builder are supported." Neha's assistant could hand "summarize the history of this case" to a service agent that the service team builds and maintains in Agentforce.

The strength is ownership: the service team changes its agent without touching the sales assistant. The costs are more hops to trace, duplicated context, and harder evaluation.

My rule of thumb: start with a single assistant. Move to a planner when one curated server can't hold the tools the job needs. Add agents only where a different team owns a domain and its rules. When you do hand off, pass record IDs rather than transcripts, and keep the approval step at the edge where the user is. Today every hop still runs as the signed-in user, because Salesforce's model has "no service accounts, no machine-to-machine flows, and no autonomous operation outside of user context."

Where Agentforce fits, and where external agents fit

Salesforce's launch article describes four layers and names Agentforce the "System of Agency". Headless 360 then opens the same platform to other agents: the Headless 360 MCP Server "enables agents running in Agentforce, Claude, ChatGPT, Cursor, and other AI platforms to dynamically discover, understand, and invoke Salesforce capabilities in real time." So the useful question isn't "Agentforce or Claude?" It is: where should this agent's loop run, and who owns it?

Three facts define the seams between the two worlds:

• Agentforce agents can be tools for external agents, through a custom hosted MCP server, if they were built with Agent Script Builder.
• The Einstein Trust Layer sits in specific paths. For prompt-template tools, "Salesforce executes the template server-side via the Generations API, applies the Einstein Trust Layer, and returns the result." For standard hosted tools, Salesforce documents something different: no Salesforce-side model, with processing that is "completely deterministic". Don't assume the Trust Layer covers a plain soqlQuery call from Claude; Salesforce documents it for prompt-template and agent tools.
• Agentforce can use external MCP servers too. At Dreamforce 2026 Salesforce announced MCP Risk Scores, which scan external servers "during Agentforce registration to uncover hidden threats ... such as prompt injections, tool poisoning, and rug pull attacks."

Slack is a third runtime: "Slackbot's MCP Client is now generally available", and it can connect to "all Salesforce MCP servers".

If the main need is…	Lean towards	Why
An agent inside Salesforce's own surfaces, built and governed by your admins	An Agentforce agent	Salesforce's "System of Agency"; Einstein Trust Layer policies apply to agent execution
Salesforce inside the tools people already use, such as Claude, ChatGPT or Cursor	An external agent through hosted MCP servers	Salesforce tests these clients, and every call runs as the user
Slack as the surface	Slackbot's MCP client	Generally available, and connects to Salesforce MCP servers
An external assistant that needs a domain another team owns	Both: the Agentforce agent as an MCP tool	Supported for agents built with Agent Script Builder
Full control of the interface, approvals and logs	Your own app on the Claude API	The capstone pattern, with Day 10's caveats

I don't rank these on security. The rule underneath is the same everywhere: "Every Salesforce Hosted MCP transaction runs as the authenticated user". What changes is who owns the loop, the prompt, the approval step and the logs.

The Headless 360 MCP Server (beta) at scale

The docs describe the idea in one sentence: "Instead of exposing thousands of features as individual tools, the server provides four tools backed by a continuously growing library of Salesforce operations." The org test found five. Connected from Claude Code on 2026-10-04, /mcp listed the four documented tools plus display_widget, with these annotations:

Tool	Annotation shown	What it does
discover	read-only	"finds the actions your agent can take": a "semantic search across a vector index of every API and skill we've generated"
describe	read-only	"returns the full specification for an action": APIs, parameters, dependencies and ordered steps
dispatch	destructive · open-world	"runs the chosen action", with GET, POST, PUT, DELETE or PATCH
dispatch_readonly	read-only · open-world	"runs read-only actions"; its method is restricted to GET
display_widget	none shown	Listed by the server; not covered here, and not called in the test

"Use them in this order for the best result." Discover takes a required query, an optional limit (1 to 50, default 10), a domain filter and a resultType of endpoint for single API operations or sor for multi-step Setup Operation Recipes. At launch the library held "roughly 100 skills" by the blog's count, and "dozens of operations, with most focused on Setup tasks for admins" by the docs', from creating and freezing users to defining platform events and named credentials. Archive Connect's 13 tools are also reached through this server, with their own limits, such as "Maximum 50 requests per hour per org" for unarchive. Two details prevent confusion: it isn't the Data 360 MCP Server ("The Data 360 server works only with Data 360 data"), and it needs API version 67.0 or later.

In practice, discover returned recipes with named steps rather than a flat list of operation ids. For permission sets, it returned a "PermSets" recipe with read steps such as list-permission-sets, get-permission-set-details and list-assignments, and write steps to create, edit, delete, assign and unassign. describe then returned a full specification for one step: GET /services/data/v67.0/tooling/query, operation id getServicesDataV670ToolingQuery (shared by about 25 recipes), a required q, and a QueryResult output. dispatch_readonly ran a SOQL query on PermissionSet and returned 95 permission sets. We never used the writing dispatch.

What this means for architecture:

1. It solves tool overload by moving the choice into search. The model sees five tools instead of hundreds, but what it runs depends on Discover's ranking. Log every describe and dispatch pair so you can see what was chosen.
2. It is an admin's server first. With mostly Setup operations, it belongs to Arjun's operations work, not to Neha's sales assistant.
3. Separate reads from writes. Use dispatch_readonly for jobs that only read. Salesforce advises: "configure your client to require your approval before it runs a tool that changes org configuration or alters or deletes data on your behalf". In your own app, the Claude API's MCP connector can switch dispatch off entirely.
4. Sandbox first. "As a best practice, make configuration changes in a sandbox or Developer org before you apply them in production."

Here is point 3 as a request fragment, aimed at a sandbox as point 4 advises. The configs entry disables one tool by name; the names match what Claude Code showed in the org test. A denylist still lets through any tool added later, such as display_widget. For a read-only job, the stricter form is "default_config": { "enabled": false } with only discover, describe and dispatch_readonly enabled in configs, which is how the Day 15 capstone fails closed.

{
  "mcp_servers": [
    {
      "type": "url",
      "name": "salesforce-headless-360",
      "url": "https://api.salesforce.com/platform/mcp/v1/sandbox/platform/headless-360",
      "authorization_token": "<USER_ACCESS_TOKEN>"
    }
  ],
  "tools": [
    {
      "type": "mcp_toolset",
      "mcp_server_name": "salesforce-headless-360",
      "configs": { "dispatch": { "enabled": false } }
    }
  ]
}

The guardrails don't change with the beta: "If you can't do it in Salesforce, your agent can't do it through the MCP server. The audit trail attributes actions to you." Salesforce collects feedback in the mcp-hosted repository.

Two ways to ship UI: native React or an external Next.js app

Agents need interfaces, and Headless 360 gives you two serious options for a React developer.

Salesforce Multi-Framework is, in Salesforce's words, "a framework-agnostic runtime on the Agentforce 360 Platform that lets developers build native Salesforce apps using React and other frontend frameworks — with authentication, security, and governance built in." It launched in beta in April 2026 and has been "generally available" since August 19, 2026; at Dreamforce, Salesforce added Angular and made micro-frontends generally available, so React and Angular components can embed in Lightning, Experience Cloud and the mobile apps. Apps "retrieve and mutate records with GraphQL, invoke Apex methods, and use UI APIs", and the data SDK's createDataSDK() "handles authentication automatically so no token management is required in the application code". The CLI from the launch blog scaffolds one:

sf plugins install @salesforce/plugin-ui-bundle-dev
sf template generate project --name my-react-project
cd my-react-project
sf template generate ui-bundle -n myreactapp -d "./force-app/main/default/uiBundles" -t reactbasic

An external Next.js app, like the capstone, is an API client. Salesforce's REST docs say such an application "must be authorized as a safe visitor", using "an external client app or a connected app and an OAuth 2.0 authorization flow"; this series always uses an External Client App. You own sign-in, token storage, hosting and the backend that talks to Claude.

	Native React (Multi-Framework)	External Next.js app
Where it runs	On the platform, opened from the App Launcher	Your own hosting
Sign-in	Handled by the SDK; no token code	OAuth through an External Client App; tokens kept server-side
Data access	GraphQL, Apex, UI API	REST, GraphQL, UI API, or hosted MCP tools through a model
Security you add	Little beyond good Apex	Sessions, CSRF protection, secret storage, token refresh
Tooling	Salesforce CLI template with Vite, Vitest, shadcn/ui and Tailwind	Your stack
Choose it when	Users live in Salesforce and you want the React ecosystem	The app serves other surfaces, joins other systems, or runs an LLM backend

Salesforce's own advice: "Choose React when you need to share components across Salesforce and non-Salesforce surfaces, or use the broader React ecosystem. Choose LWC when you want declarative data access with @wire and Lightning Data Service, the base component library, and the drag-and-drop Lightning App Builder." Multi-Framework "doesn't replace LWC; it runs alongside it."

There is a third option when the interface is the agent conversation itself. The Headless Experience Layer, generally available since Dreamforce, "separates what an agent does from how it appears", rendering natively in Slack, mobile, ChatGPT, Claude, Gemini, Teams "or any client that supports MCP apps".

For Acme the answer is "both". The account-review app for reps who already work in Lightning is a Multi-Framework React app. Neha's AI assistant, with its own approval flow and a Claude backend, stays an external Next.js app.

Hands-on: an architecture decision record for Acme Global Tech

An ADR is a short document that records one decision: the context, the options, the choice and its consequences. Its value is the list of reasons you can re-check when a fact changes, and in this space facts change monthly. Keep ADRs in the repository next to the code, for example in docs/adr/.

Here is the template I use:

# ADR-<NNN>: <the decision, in one line>

- Status: Proposed | Accepted | Superseded by ADR-<NNN>
- Date: <YYYY-MM-DD>
- Deciders: <names and roles>
- Review by: <date, or the event that should trigger a review>

## Context
<The problem, the users and the constraints. Link test results.>

## Decision drivers
- <security, time to value, cost, skills, GA or beta status>

## Options considered
| Option | For | Against | Status (GA or beta) |
| --- | --- | --- | --- |

## Decision
<The chosen option and exactly what it covers.>

## Consequences
- Good: <…>
- Bad: <…>
- Follow-ups: <…>

## Security and data
<Who the agent runs as, which servers and tools, where tokens live, what is logged.>

## Open questions and review triggers
- <question> (owner, due date)

And here it is filled in for Acme.

ADR-004: How Neha's sales assistant reaches Salesforce

Status: Proposed. Date: 2026-09-30. Deciders: Arjun (Salesforce admin), the sales operations lead and the security architect. Review by: after the pilot test in a Developer Edition org, and again when agent registration ships.

Context. Account executives want an assistant that prepares account reviews and creates follow-up tasks. Answers must use Acme's health rule (Day 12's getAccountHealth), every write needs the user's explicit approval, and security requires per-user permissions, tokens kept server-side and a log of every tool call.

Decision drivers. Runs as the signed-in user. Approval enforced outside the prompt. Generally available components wherever possible. One place to log. A pilot within weeks.

Option	For	Against	Status
A. Claude custom connector to the hosted servers	No code; each rep connects their own account	Approval experience and logs belong to the client, not to Acme	Hosted servers GA
B. An Agentforce agent in Lightning	Native surface; Trust Layer on agent execution	A new build stack for this team, for a pilot	Not evaluated in this series
C. External Next.js app with the Claude API MCP connector (the capstone)	Approval enforced per request by tool configuration; own tool-call log; tokens server-side	Token sent to Anthropic; connector in beta; Acme runs the app	Servers GA, connector beta
D. The Headless 360 MCP Server as the only server	One connection, broad reach	Beta; mostly Setup operations	Beta

Decision. Option C. Servers: sobject-all with its write tools disabled until approval, plus HeadlessAssistantTools. Model: Claude Sonnet 5.5 (claude-sonnet-5-5). Identity: the Headless Assistant Local External Client App, admin-approved users only, gated by the Headless_Assistant_User permission set. The Headless 360 MCP Server stays out of the sales path; Arjun may use it from Claude Code in a sandbox, with approval required for dispatch.

Consequences. Good: one approval path, one log, business rules in tested Apex. Bad: each request carries the user's short-lived access token to Anthropic's API, and Anthropic's docs mark the MCP connector "not-eligible" for Zero Data Retention; Acme hosts and patches a web app. Follow-ups: the Day 14 runbook and API usage monitoring.

Security and data. Every call runs as the rep, so sharing and field-level security apply. Tokens live in an encrypted, httpOnly cookie and are refreshed after 15 minutes. Logs record tool names and IDs, never record data.

Open questions and review triggers.

• Does the Claude API connector work end to end with the hosted servers? No document confirms the pairing, but Arjun's Developer Edition test on 2026-10-04 did: it called sobject-all and the custom server with the user's token, with no resource indicator. Re-test before production, since the connector is beta.
• Does one access token work for both servers? Yes, in the same test.
• Agent registration, which Salesforce is "Targeting November", would give agents their own identity. It is announced, not shipped, and subject to change: revisit the identity section when it ships.
• Headless Platform Interaction billing, part of the same November plan: the multipliers are "TBA" and pricing is subject to change; revisit before rollout beyond the pilot.

Several facts in this record could change within months. That is exactly why it is written down.

What can go wrong

Symptom	Cause	Fix
Nobody can explain which agent did what	Multi-agent from day one	Start with a single assistant; add agents only at ownership boundaries
A sales workflow breaks after a quiet change	A beta server in a user-facing path	Keep the Headless 360 MCP Server in sandbox admin work, with approvals
The model keeps choosing the wrong tool	Dozens of loosely described tools on one connection	Curate custom servers, or use discovery tools for large surfaces
Security assumes "the Trust Layer covers it"	Salesforce documents the Trust Layer for prompt-template and Agentforce agent tools, not for standard tools	Put approvals, logging and data rules in your client
Users juggle logins and tabs	Native React built for outside users, or an external app for users who live in Lightning	Choose the UI option by where users already sign in
A redesign after November	The design assumes every agent acts only as the user	Record the assumption in the ADR with a review trigger

Open access, not open bypass

Salesforce's governance guidance puts the principle in four words: "open access, not open bypass." It lists what that means in practice: "Limit the scope of external tools", "Grant only necessary user or integration permissions", "Restrict exposure to sensitive data" and "Require human approval for high-impact actions". Every pattern today inherits those rules. More agents never mean more permissions; they mean more places where the same permissions must hold.

Today's checklist

• I can name the three agentic patterns and when to move from one to the next.
• I know where Agentforce agents, external agents and Slackbot fit, and that an Agentforce agent can be an MCP tool.
• I can explain the five tools of the Headless 360 MCP Server and why it is beta and admin-focused.
• I know when to disable dispatch and use dispatch_readonly.
• I can choose between Multi-Framework React and an external Next.js app for a given user group.
• I have an ADR for my own assistant, with review triggers.

Frequently asked questions

Should I build a Salesforce agent with Agentforce or with Claude?

It depends on where the agent's loop should run and who owns it. Agentforce suits agents inside Salesforce's surfaces; external agents such as Claude suit people who already work there. You can combine them by exposing an Agentforce agent as an MCP tool.

Is the Headless 360 MCP Server ready for production?

It is a Beta Service, in open beta since July 2026, under Salesforce's Beta Services Terms. Salesforce recommends making configuration changes in a sandbox or Developer org first and requiring approval for tools that change data or configuration.

Can an external agent call an Agentforce agent?

Yes. A custom hosted MCP server can expose an Agentforce agent as a tool, if the agent was created with the new Agent Script Builder. The Einstein Trust Layer applies to that agent's execution.

Is Salesforce Multi-Framework generally available?

Yes. Salesforce announced general availability on August 19, 2026, and at Dreamforce added Angular support and made micro-frontends generally available.

Does a multi-agent design give each agent its own identity?

Not today. Hosted MCP calls run as the signed-in user, with no service accounts. Salesforce has announced agent registration, targeting November, which would give each registered agent its own identity. Treat it as announced, not shipped, and subject to change.

What's next

An ADR says what you will build. Day 14 is about running it: who approves new tools and servers, how changes move from sandbox to production, what Salesforce logs and what your app must log, how to classify and retry errors, and what the announced November changes to identity and billing mean for your plan. We finish with a typed error-handling module and a runbook for Acme.

Sources

Verified against the sources below on September 30, 2026. Salesforce ships Headless 360 changes often: check the linked docs if a screen looks different.

1. Headless 360 MCP Server (Beta) — Salesforce Hosted MCP Servers guide
2. Announcing the Headless 360 MCP Server Beta
3. Salesforce Turns Enterprise Applications into Enterprise Capabilities — August 19, 2026: availability of the Headless 360 MCP Server, Multi-framework and Slackbot MCP Client
4. Build with React, Run on Salesforce: Introducing Salesforce Multi-Framework
5. Agentforce (agents and prompt templates as MCP tools)
6. What Salesforce Headless 360 Means For Developers
7. The Top 5 Dreamforce Announcements for IT
8. Slackbot MCP Client