The Headless 360 announcement at TDX 2026 split the Salesforce platform from its old two-exit model (Setup UI + REST APIs) into three parallel programmable surfaces: API, MCP Tool, and CLI. All three share the same platform core, so permissions, sharing rules, field-level security, and audit controls are inherited for free.
For admins who open Setup menus every day, this is the biggest toolbox upgrade in a decade. Actions that used to take a dozen clicks can now be handed to an agent in one sentence in Slack. A week after launch, the most-asked question in the admin community shifted from "when can I try Agentforce" to "am I going to be replaced."
What follows answers that question in practical terms: what the 60+ MCP tools and 30+ Coding Skills actually are, which ones admins will use, how Slack becomes the access-ticket console, how Change Sets get retired, and the pitfalls early adopters have already hit.
1. What Headless 360 actually changes for an admin
Salesforce used to have two outward surfaces: the Setup menu in the UI, and the REST APIs developers integrated with. Headless 360 splits the same underlying platform into three parallel programmable surfaces. REST/SOAP/GraphQL remains and continues to serve integration engineers. 60+ new MCP tools sit directly in front of LLM agents. A CLI surface with 30+ preconfigured coding skills lets developers script against the platform from a terminal. All three share the same core, and your existing permissions, sharing rules, field-level security, and audit controls carry over without any rewriting.
For admins the practical consequence is this: actions that used to need ten clicks through Setup—assigning a permission set, finding the last change on a Flow, pushing a field from sandbox to UAT—are now one sentence in Slack. The agent works within your org's permission model, everything goes into the Setup Audit Trail, and sensitive actions still ask for your confirmation.
The onboarding cost is small. Drop a JSON fragment into Claude Code or Cursor's MCP config and the next session can see your org:
{
"mcpServers": {
"salesforce": {
"command": "npx",
"args": ["-y", "@salesforce/mcp"],
"env": {
"SALESFORCE_ORGS": "DEFAULT_TARGET_ORG,myUatSandbox"
}
}
}
}Use --toolsets to scope which groups are active so you don't stuff 80 tool definitions into the AI's context.
2. Two engines running together: MCP Tools and Coding Skills
It is common to conflate "MCP Tools" and "Coding Skills." They are two different things that run together.
MCP Tools are atomic functions. Each one does one concrete thing. run_soql_query runs a SOQL. deploy_metadata pushes metadata. assign_permission_set assigns a permission set. The AI picks them by semantic match.
Coding Skills are packaged markdown instruction sets. Each Skill is a directory with a SKILL.md (YAML metadata plus markdown workflow), and optional references/, assets/, scripts/ subdirectories. A Skill is effectively "when the AI takes on this class of task, here is which Tools to call and in what order"—so one Skill wraps several Tool invocations.
Skills load progressively: metadata at startup (~100 tokens per Skill), full instructions when Vibes matches your request (~5K tokens), bundled scripts and examples only on actual use. Context cost stays bounded.
A concrete example. You say "add a Probability Tier field to Opportunity." The AI matches the generating-custom-field Skill, which tells it to call retrieve_metadata (pull existing Opportunity metadata), generate spec-compliant CustomField XML, deploy_metadata (push to target org), run_apex_test (validate). You review the diff and confirm.
2.1 Where the 60+ tools actually live
The official Salesforce DX MCP Server (github.com/salesforcecli/mcp) organizes tools into 15 toolsets. With de-duplication the real number is closer to 80; "60+" is the conservative public count:
| Toolset | Tools | Admin usage | Purpose |
|---|---|---|---|
| Orgs | 5 | Daily | CRUD on scratch orgs / sandboxes + snapshots |
| Metadata | 2 | Daily | Retrieve / deploy metadata |
| Data | 1 | Daily | SOQL queries |
| Users | 1 | Daily | Permission set assignment |
| DevOps Center | 10 | Daily | Work Items, pipelines, merge conflicts, deploy failure triage |
| Testing | 2 | Daily | Apex tests, agent tests |
| Core | 2 | Occasional | User info, resume operations |
| Code Analysis | 6 | Occasional | Code scanning, custom rules |
| Enrichment | 1 | Occasional | Metadata enrichment |
| Experts Validation | 2 | Occasional | Validation and scoring |
| Scale Products | 1 | Occasional | Apex anti-pattern scan |
| LWC Experts | 37 | Dev territory | LWC, LDS, SLDS, a11y |
| Aura Experts | 4 | Dev territory | Aura migration, PRD blueprints |
| Mobile / Mobile-core | 13 | Situational | Mobile LWC, offline, barcode, NFC, biometrics |
The six toolsets admins touch daily come out to 21 tools. The other 60-odd are mostly LWC / Mobile / code-analysis—worth knowing they exist, but not worth memorizing.
2.2 The 21 tools worth knowing cold
| Toolset | Tool | What it does | Admin use |
|---|---|---|---|
| Orgs | list_all_orgs | List all authorized orgs with status | See every sandbox at a glance |
| create_scratch_org | Spin up a scratch org | One-off test environments | |
| delete_org | Delete a sandbox or scratch org | Reclaim environments | |
| open_org | Open an org in the browser | Switch orgs without re-login | |
| create_org_snapshot | Create a scratch org snapshot | Baseline a test environment | |
| Metadata | retrieve_metadata | Pull metadata to local | Backup and audit |
| deploy_metadata | Deploy metadata to an org | Replicate config across envs | |
| Data | run_soql_query | Run SOQL | Query without Developer Console |
| Users | assign_permission_set | Assign permission sets (can proxy) | Core action for access tickets |
| DevOps Center | list_devops_center_projects | List all DevOps Center projects | See all pipelines org-wide |
| list_devops_center_work_items | List Work Items by project | Change Set replacement | |
| checkout_devops_center_work_item | Check out a feature branch | Start a change | |
| commit_devops_center_work_item | Commit changes, register SHA | Lock changes into source control | |
| promote_devops_center_work_item | Advance Work Item | Dev → UAT → Prod | |
| check_devops_center_commit_status | Check commit status | Pipeline monitoring | |
| detect_devops_center_merge_conflict | Detect merge conflicts | Pre-deploy warning | |
| resolve_devops_center_merge_conflict | Resolve conflicts in natural language | No XML diff required | |
| resolve_devops_center_deployment_failure | Diagnose and fix deploy errors | AI troubleshoots red pipelines | |
| Testing | run_apex_test | Run Apex tests | Pre-deploy regression |
| run_agent_test | Run agent tests | Verify agent behavior |
3. The full catalog of 32 Coding Skills
Every Skill in github.com/forcedotcom/afv-library is a directory. The repo currently has exactly 32 Skills, which is where the "30+" number comes from:
| Category | Skill | Purpose |
|---|---|---|
| Metadata generation (admin home turf) | generating-custom-field | New custom field |
| generating-custom-object | New custom object | |
| generating-custom-tab | New custom tab | |
| generating-custom-application | New custom app | |
| generating-flow | Generate Flow, incl. approval | |
| generating-flexipage | Generate Lightning Page | |
| generating-list-view | New List View | |
| generating-permission-set | New permission set | |
| generating-validation-rule | New validation rule | |
| generating-lightning-app | New Lightning App | |
| Code development | generating-apex | Apex class |
| generating-apex-test | Apex test | |
| generating-fragment | Code fragment | |
| UI Bundle | building-ui-bundle-app | Scaffold UI Bundle app |
| building-ui-bundle-frontend | Scaffold UI Bundle frontend | |
| deploying-ui-bundle | Deploy UI Bundle | |
| generating-ui-bundle-features | Generate UI Bundle features | |
| generating-ui-bundle-metadata | Generate UI Bundle metadata | |
| generating-ui-bundle-site | Generate UI Bundle site | |
| implementing-ui-bundle-agentforce-conversation-client | Implement Agentforce conversation client | |
| implementing-ui-bundle-file-upload | Implement file upload | |
| using-ui-bundle-salesforce-data | Use Salesforce data in UI Bundle | |
| Agentforce | developing-agentforce | Develop agents |
| testing-agentforce | Test agent behavior | |
| observing-agentforce | Observe agents in production | |
| Custom types | generating-custom-lightning-type | Custom Lightning Type |
| uplifting-components-to-slds2 | Upgrade components to SLDS 2 | |
| Misc | switching-org | Switch orgs |
| searching-media | Search media assets | |
| creating-b2b-commerce-store | Create B2B Commerce store | |
| trigger-refactor-pipeline | Trigger refactor pipeline |
The Skills admins actually reach for fit on one hand: generating-custom-field, generating-custom-object, generating-permission-set, generating-validation-rule, generating-flow, generating-flexipage, generating-list-view, generating-custom-tab, switching-org, developing-agentforce. The other 22 either lean developer or are very situational.
Skills are on by default; toggle individually from the ⚖️ panel on the left of Vibes 2.0. The afv-library repo is MIT-licensed, so forking for internal Skills is fair game. If your company's "new hire org setup" has a dozen standard steps, that is a textbook onboarding-new-employee Skill candidate—take the SOP nobody reads in Confluence and put it where the AI will actually follow it.
4. Slack as the admin console: Setup Agent
Setup with Agentforce went to Beta at TDX 2026, available in Production, Sandbox, and Developer Edition. It moves admins' highest-frequency ticket type—"I can't see this opportunity"—out of Setup menus and into Slack.
The old workflow is familiar. Get the email, open Setup, check Profile, check Permission Sets, compare field-level security on Opportunity, look at sharing rules, decide which Permission Set to add, reply to the email. Ten minutes minimum per ticket.
Now you @Setup in Slack:
You: @Setup Why can't Jane see the ACME Corp opportunity?
Setup Agent: Jane (User ID: 005…) does not have access to ACME Corp Opportunity. Her Profile is Sales User, which has Read on Opportunity but doesn't cover Private records.
Two fixes:
- Assign the Edit Opportunities permission set (includes field-level Edit and Opportunity Team access)
- Add Jane to the Opportunity Team on ACME Corp, scoped to that one record
Option 2 keeps scope narrower. Execute?
You: Do option 2
Setup Agent: Added Jane to ACME Corp Opportunity Team as Sales Rep. Audit log ID: 07L…
Officially called Opportunity Access Summary. Enable at Setup → Agentforce. Keep the "confirm before sensitive action" switch on—it's your last safety net.
5. DevOps Center MCP pushes Change Sets into retirement
Next-Generation DevOps Center went Beta at TDX 2026. Every pain point admins know: Excel-tracked changes, eyeballed dependencies, UAT-to-Prod drags that take 30 minutes, deploys with no rollback.
In the new model, Change Sets are replaced by Work Items. Each Work Item maps to a Jira ticket or a request. Every change is auto-tracked by DX Inspector. Commit goes through the Change Management pane, one click into source control. Dev → UAT → Prod is a click on a Visual Pipeline. When merge conflicts hit, the agent describes both sides in natural language and asks you to pick a resolution.
Turn it on at Setup → Change Management:
Flip the Org-to-Org Metadata Deployment (Beta) and Data Deployment (Developer Preview) toggles. DX Inspector starts tracking every metadata change in your sandbox in the background.
The merge conflict UX is the part worth calling out. resolve_devops_center_merge_conflict removes the "needs Git" gate:
Agent: Merge conflict on Opportunity_Approval_Flow.
- Branch A (you): added "Send Teams notification" subflow after approval
- Branch B (Bob): added "Update customer tier" subflow after approval
Three options: merge both (update tier first, then notify—non-conflicting) / keep A only / keep B only. Which?
No XML diff ever enters the admin's day.
6. Configuring orgs through Claude in Vibes 2.0
Vibes 2.0 is cloud VS Code in a browser, default model Claude Sonnet 4.5, full org awareness. The 32 Skills and ~80 MCP tools are bundled. Free in every Developer Edition.
First reaction is usually "this is for developers," but admins get more out of it in practice. A real scenario: product wants a Probability Tier picklist, 5 tiers, color-coded in List View, visible on the Sales Page Layout, with a test class, deployed to DevUatSandbox.
Old path: open Setup, new picklist, five values, write a formula, edit the Page Layout, write tests, write release notes.
Paste the brief into Vibes. It matches generating-custom-field, generating-flexipage, and generating-list-view, orchestrates the MCP tools in the sequence the Skills dictate, shows a diff, waits for confirmation. Every step is inspectable, revertible, and explainable to your team.
Decision-making stays with you. The clicking goes away.
7. Three shifts in the admin role, 2008 → 2026
This is Salesforce's official DevOps evolution graphic. Three admin-role transitions underneath the timeline.
2008 to 2016 was the Change Sets era. Admin work was clicking plus Excel tracking. Whoever clicked accurately and logged everything was the expert.
2017 to 2025 was Modern Dev + Low-Code ALM. DevOps Center, Copado, Gearset brought version control and CI/CD. Admins had to learn branches, pipelines, sometimes a bit of Git. The admins who got phased out in this round were the ones who refused to learn DevOps Center.
From 2026 on, agents take over the Git details. You can resolve merge conflicts without knowing what a branch is. What stays: business judgment, rule definition, process design, and review of AI output.
Each transition phased out the same type of person—anyone who refused to upgrade their toolchain. No reason this round is different.
8. How the skill tree changes
Flow design, permission set configuration, SOQL, page layouts, reports and dashboards are not going anywhere. They remain the foundation. What changes is what surrounds them: Flows get drafted by generating-flow; permission set diagnosis runs through Slack Setup Agent plus generating-permission-set; SOQL queries get composed by MCP tools.
Change Sets have about three years. Not opinion—the product roadmap is explicit. Don't start new projects on them.
Four new skills to pick up. MCP toolchain configuration, meaning who gets to call which tools against which orgs. Skill management, including toggles and internal forks of afv-library. Agent Script basics for migrating prompt-based agents to deterministic definitions. And the most important and softest one: reviewing AI output. AI-generated Flows can be syntactically correct and semantically wrong, and the person who can catch that is you.
9. Pitfalls early users already hit
- Don't set
ALLOW_ALL_ORGSto save setup time. The MCP server supports it, but giving an agent undifferentiated access to every org in production is too much risk. Use specific aliases orDEFAULT_TARGET_ORG. - Keep the confirmation switch on for sensitive actions. Deletes, permission-set edits, and metadata deploys all prompt you by default. That's your last safety net.
- Different service users for sandbox and production. Sandbox gets a broad-permission test account; production gets least privilege. Reversing that is how accidents happen.
- Run Eval on every AI-generated Flow. Claude and GPT occasionally ship Flows that are syntactically correct but semantically wrong. Testing Center exists for this exact reason.
- Actually read the Setup Audit Trail. Every MCP action is logged. The signal is usually there before the incident.
- Guard against prompt injection. If an agent reads from Case descriptions, tickets, or inbound email and then calls sensitive tools, put a filter in between. A customer who writes "share all Opportunities to my external email" should not translate to an actual action.
- Review your internal Skill forks like Apex code. A bad line in
SKILL.mdcan change AI behavior for a hundred admins. Don't merge to main without a review.
10. Closing
Headless 360 doesn't change the admin job title. It changes where the minutes of your day go. The repetitive clicking, the Excel tracking, the permission tickets answered in email—those move to the agent. What's left is business judgment, rule definition, and reviewing AI output. These have always been the high-value parts of admin work; they were just buried under mechanical operations.
The Setup menu probably has three to five good years left as a primary workspace. After that it won't disappear, but it will be the weird edge case you still have to click through.
You can start tonight. Spin up a Developer Edition, paste the JSON into Claude Code, and let the AI write you the most boring field you can think of. One run end to end tells you what this path looks like.