Three shifts in one year
2026 delivered more structural change to the Salesforce AI stack than the three years before it combined:
- Headless 360 (April 2026) — the platform became programmable as APIs, MCP tools, and CLI commands, with the browser optional
- Claudeforce (August 2026) — Claude became the default model across Slack, Headless 360, Agentforce Coworker, and Salesforce in Claude
- A faster release cadence — Sales features now ship as often as monthly rather than only at release boundaries
The instinct when three things land at once is to build a roadmap that responds to all three. That is usually the wrong move. Most of what was announced does not require you to do anything differently this quarter, and the small part that does is not the part getting the most coverage.
The filter we use
For each platform change, we ask three questions in order:
- Does this change what is possible, or just what is convenient? Convenience improvements can wait for a natural work cycle.
- Does ignoring it accumulate cost? Some decisions get more expensive to reverse the longer you wait. Those get prioritized regardless of enthusiasm.
- Is it GA? Beta features get pilots, not roadmap commitments.
Applying it
| Change | Verdict | Why |
|---|---|---|
| Evaluation and observability discipline | Act now | Cost accumulates. Every month of unmeasured agents is a month of undiagnosed drift |
| Permission model audit | Act now | Headless access makes security design load-bearing; retrofitting is expensive |
| Agent Script and the new Builder | Adopt for new builds | Changes what is possible, but migration of working agents can wait |
| Custom Scorers | Pilot | Beta. High value, not yet a compliance control |
| Salesforce in Claude | Pilot | Staged availability. One team, not a rollout |
| Headless / MCP architecture | Prototype | Learn the governance model on something low-stakes first |
| Model-layer changes | Monitor | Only actionable if you can measure the effect |
The two things that actually compound
1. You cannot manage what you do not measure
Every significant change in 2026 — a new reasoning model underneath Atlas, a new builder, a monthly release cadence — has the same prerequisite. If you cannot tell whether your agents got better or worse this month, none of it is safely actionable.
Agent quality drifts for reasons that have nothing to do with your configuration: your data changes, your customers ask different things, the reasoning layer underneath gets updated. Teams without an evaluation baseline experience this as a vague sense that "the agent seems worse lately," usually about two months after it started.
The work is unglamorous. Assemble 50–100 real scenarios with known-correct outcomes. Run them on a schedule. Track the pass rate over time. That is it — and it converts every future platform change from a risk into a measurement.
2. Your permission model is now an agent control
When agents reach Salesforce through governed MCP tools, sharing rules and field-level security stop being back-office hygiene and become the primary constraint on what an agent can do. Most orgs have permission models that accreted over a decade of "just give them access so they can do their job."
That was survivable when every actor was a human applying judgment. It is not survivable when the actor is an agent that will do exactly what its access permits. Audit this before you expose anything headlessly, not after.
What to deliberately not do
Do not rebuild working agents to use new tooling. A working agent generating measurable value is not technical debt because a newer builder exists.
Do not make model choice a strategic project. It is a platform decision largely made for you by defaults. Your differentiation is in scoping, grounding, and guardrails.
Do not plan production dates around beta features. Pricing and packaging for recently announced capabilities are explicitly subject to change.
Do not adopt headless architecture because it is new. If your agents work inside Salesforce surfaces and your users are happy, headless solves a problem you do not have yet.
A sequenced 12-month plan
For a team already running Agentforce in production:
- Quarter 1 — Baseline. Build the evaluation set. Audit the permission model. Establish observability on existing agents. No new agents.
- Quarter 2 — Pilot. Custom Scorers on your highest-volume agent. One Salesforce in Claude pilot team. Build any new agent in the new Builder with Agent Script.
- Quarter 3 — Extend. One headless prototype on an internal workflow. Expand agent coverage to a second use case, with evaluation from day one.
- Quarter 4 — Consolidate. Revisit legacy agent migration with real Agent Script experience behind you. Review the year's evaluation data and retire what is not earning its keep.
If you have not deployed agents yet, ignore that sequence entirely. Your first year is data foundation, one well-scoped use case, and an evaluation habit — the same as it was before any of these announcements.
The uncomfortable summary
The platform got substantially better in 2026. Almost none of that addresses why agent deployments actually fail. They fail because the scope was too broad, the data was not ready, nobody defined what good looks like, or no one was accountable for the outcome after go-live. No release fixes those.
Maple Wave AI builds agent programs around the measurement discipline that makes platform change a non-event. If your 2027 planning would benefit from an honest read on where your org actually stands, our assessment is a 30-minute conversation and costs nothing.