Why Salesforce should care¶
The short version: Agentforce consumption grows when projects reach production, and the field evidence says too many are not getting there. In Keenan Vision's field research — eighteen enterprise engagements, chosen purposively — 87% of the projects that cleared scoping, received budget, and entered build never went live. That is a signal from one sample, not a market-wide rate (its limits), and the wider surveys point the same way. It 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) is therefore a consumption signal, not just a services statistic — bounded by its sample, but pointing at revenue. 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 plugin: governed knowledge, recompiled onto Salesforce's own tools, at the initiative of Salesforce's own product team. And the recombination has had a first test — in that team's own head-to-head, one scenario with three agents, only the agent equipped with the distilled skills reached the correct architectural outcome (the bake-off, and its limits).
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.
This page as Markdown — for pasting into Claude or another assistant · llms.txt