In Summer ’24, Salesforce AI capabilities were changing faster than most enterprise release cycles. Waiting for the product surface to stabilize was not a strategy; neither was rebuilding every pilot around the latest announcement.
The durable work sat underneath the interface: trusted customer context, reusable actions, permission discipline and a repeatable way to evaluate behavior.
Cloud Group point of view
Architect for replaceable experiences and durable contracts. The model, assistant and user interface may change; the definition of an approved customer fact or a safe business action should not.
A practical playbook
The strongest next step is narrow enough to govern and useful enough to produce evidence. We would structure the work around these moves:
- Define governed data products for the first three AI use cases.
- Wrap high-value business actions in stable, permission-aware interfaces.
- Create evaluation cases from actual service and sales work.
- Track product dependencies and avoid undocumented preview features in critical paths.
- Use each seasonal release to retire redundant customization.
The architecture and operating implication
Introduce a thin orchestration layer that keeps prompt configuration, retrieval, actions and telemetry legible. Favor native capabilities when they satisfy the control requirement, but maintain clear boundaries so a model or interface change does not force a data redesign.
Measure what changes
Model activity is not a business result. Track a small set of indicators that connect behavior to accountable work:
- Percentage of new use cases using existing data and action contracts
- Time required to adopt a platform change
- Regression coverage across releases
- Custom footprint retired
Speed comes from preserving the right things. A stable AI foundation lets the product surface evolve without turning every release into a new architecture.
Primary sources
This field note is grounded in the product and market context available at the time of publication.
