---
description: >-
  The cross-departmental case for Rosetta at Salesforce: consumption follows production, the architecture's missing unit of production, emergent uses, and the toolbox test.
---

# 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](../research/field-evidence.md)),
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](delivery-gap.md).

## 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.

![Two four-layer stacks compared: intent confined to a fifth layer, marked no; intent infused as a band across all four layers, marked yes](../assets/intent-infusion-light.svg#only-light)
![Two four-layer stacks compared: intent confined to a fifth layer, marked no; intent infused as a band across all four layers, marked yes](../assets/intent-infusion-dark.svg#only-dark)

## 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](delivery-professionals.md) 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](../rosetta-platform/util/plugins/d360-distiller/README.md)
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](../research/field-evidence.md#the-bake-off-the-product-teams-own-head-to-head)).

**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](../index.md), or read the evidence base in
[The delivery gap](delivery-gap.md).*