Why Salesforce should care¶
The short version: Agentforce consumption grows when projects reach production, and most enterprise Agentforce projects are not reaching production. Keenan Vision's field research puts the stall rate at 87% — projects that cleared scoping, received budget, and entered build, and still never went live. That is not only a delivery problem. Under consumption-based and outcome-based pricing, it is a revenue problem that belongs to the platform, and fixing it requires an artifact the current architecture does not yet name. This page makes that case in five steps. The evidence behind it is laid out in The delivery gap.
1. Consumption follows production¶
An agent that never ships resolves nothing, and under outcome-based pricing an agent that resolves nothing bills nothing. The pricing model is the right one — it aligns the platform with customer results — but it has a consequence worth stating plainly: delivery quality is now the platform's own margin. A badly architected implementation is no longer just a partner's problem or a customer's disappointment; it is unrealized platform revenue. The 87% stall rate documented in the Data 360 Strategy Sprint (18 enterprise engagements, 858 coded findings, late 2025 – early 2026) should therefore be read as a consumption forecast, not a services statistic. Every project that reaches production is a consumption stream; every project that stalls is one that never starts.
2. The architecture is missing its unit of production¶
Salesforce's published Agentic Enterprise Architecture — Engagement, Agency, Work, and Context, over a Trust foundation — is coherent and well-factored. What it does not yet name is the artifact that carries business intent across those layers. Every engineering discipline is organized around a unit of production: the part, the schematic, the deployable. Agentic systems have entered production without one — the agent is a runtime, the prompt is unstable, the workflow assumes determinism, the model is an input owned upstream.
The research reaches a positive conclusion here, not a critique: intent should not be a fifth layer on the diagram. Decades of software engineering say cross-cutting concerns fail when confined to layers — modularity, security, and observability all had to be infused throughout the stack before they worked. Intent belongs in that lineage. Each of the four layers has an intent behind every action it takes, and when intent is confined anywhere, the other layers reconstruct it from context — and reconstruction is where projects die. The working papers propose the Spec Manifest as the carrier: a versionable, auditable statement of what the business wants, addressable from every tier, compiled down to configuration with its provenance intact. Not a fifth box — the property that makes the existing four boxes agent-ready.
3. A compass, a map, and a Geiger counter for the field¶
The stall is felt first in the field. An Account Executive or Solution Engineer in a discovery call, a Professional Services or GSI team contracting a delivery, a delivery crew landing an agent in a real org — each needs a fast, confident way to show a customer why the data foundation is required and exactly what to build on it. Rosetta hands all three the same governed instruments: a compass (where the engagement should go), a map (what to build there), and a Geiger counter (the anti-patterns that click before you step on them) — drawn from one body of patterns, decisions, and evidence, so the architecture story a customer hears in pre-sales is the one that gets contracted — and the one that gets built. The delivery professionals makes the full case role by role. The approach has been validated hands-on by a Salesforce Distinguished Solution Engineer.
4. The toolbox test — uses we did not design¶
There is a moment every product designer waits for: the moment users take the toolbox and recombine it into something the designer never imagined. If a product only ever does what it was designed to do, it is a tool. When its users start designing with it, it has become a platform. Rosetta has already passed that test twice — and both times, the new designers were Salesforce's own people.
The distiller. Salesforce's Data 360 product managers, after working hands-on with Rosetta's governed knowledge, asked for something that was never in the original design: compile that knowledge into task-level builder skills that run on Data 360's own MCP tool surface — so the expertise travels even to builders who never touch Rosetta itself. That request became the d360-distiller, the seventh plugin: governed knowledge, recompiled onto Salesforce's own tools, at the initiative of Salesforce's own product team. And the recombination has already been put to the test — in that team's own independent head-to-head, only the agent equipped with the distilled skills reached the correct architectural outcome (the bake-off).
The Trailhead lane. The same team, having watched Rosetta surface field knowledge that official content had not yet caught up with, proposed a second recombination: point the same distillation discipline at enablement — accelerating governed field knowledge into content for Trailhead, the platform's learning home and the Trailblazer community's front door. A stakeholder group the original design never listed — enablement and education — was written onto the roadmap by the product team's own proposal.
Emergent use is the one adoption signal that cannot be faked: it only happens when outsiders find value the designer did not put there on purpose. Two recombinations in, the pattern is visible — Rosetta's governed knowledge plus its compilation discipline is a toolbox, and the ecosystem has started building with it.
5. Cross-departmental by construction¶
Because intent crosses every layer, the initiative crosses every department: Sales (the AE and SE motion in pre-sales), Customer Success (the Professional Services and GSI organizations that contract deliveries, and the delivery teams they field, with Forward Deployed Engineers as the accelerant that gets them started), Product (Data 360 and Agentforce — and not only as a home for the artifact: a governed body of field implementation knowledge is a feedback loop, putting what actually happens in customer orgs at product teams' fingertips), Enablement (the same knowledge distills naturally into learning content — the Trailhead lane the product team itself proposed in step 4), and Partners — because the proposal is deliberately headless, a compilation contract that partner tools consume and extend rather than a product that competes with them. That is why the working papers' recommendation is organizational, not just technical: charter a Spec Manifest working group under Data Foundations, with participation from platform engineering, Agentforce engineering, Slack engineering, and the trust organization, to draft a first-class-object specification.
Honest scoping, in the papers' own words: no claim of generality beyond layered agentic enterprise platforms. Salesforce is the worked setting. Rosetta is designed for this ecosystem — its metadata, its delivery professionals, its economics — not a generic tool wearing a logo.
The papers close on a deadline worth taking seriously: the eighteen months after such a specification is published will determine whether the Salesforce ecosystem leads the agentic enterprise transition or follows it. We believe it can lead.
Start at the beginning, or read the evidence base in The delivery gap.