Skip to main content
AI Development

Salesforce's AI Harness: what to reuse now and what to defer

The new architecture promises reuse across enterprise AI. Evaluate existing capabilities now, and keep future consolidation separate from work you can deliver today.

Sean McLellan profile photo

Sean McLellan

Lead Architect & Founder

6 min read
A constructed availability guide separates existing Salesforce foundation technologies, the planned early fiscal FY28 rollout, and commercial details still to come.
Constructed diagramSalesforce announcement summary, not a product test. The planned rollout begins in early fiscal FY28; it is not a date for complete availability.

Salesforce has announced an Enterprise AI Harness that brings data, agent planning, actions, governance, security, and model choice into a common architecture. For a business already using Salesforce, the useful question is how much of its existing investment can support agent work without another layer of custom integration.

The announcement describes a direction for that consolidation, not a single finished package. Many underlying technologies are available now; new capabilities and the unified experience are planned to begin rolling out in early fiscal FY28. That difference should shape both an implementation proposal and the list of systems a team intends to retire.

What Salesforce is bringing together

In its September 11 announcement, Salesforce describes an AI harness as the surrounding capabilities that let a model understand a business and act within its rules. The model supplies reasoning. The surrounding software supplies business context, available actions, permissions, and operational controls.

Salesforce groups that software into six capabilities. Context supplies data, definitions, knowledge, signals, and memory. Agency supplies planning, state, collaboration, and orchestration. Action connects agents to applications, APIs, and workflows. Governance covers the data and policies that agents rely on. Security covers identity, permissions, privacy, and runtime protection. Models covers model choice and routing.

These are Salesforce's architecture categories, not six independently verified product guarantees. The company says the architecture draws on Data 360, Informatica, MuleSoft, Agent Fabric, Tableau, Agentforce, Salesforce Guardian, and the Salesforce Platform. It also describes customers using the capabilities together or selecting the parts they need alongside third-party technology.

The practical appeal is reuse. If a business already maintains customer permissions, approved workflows, and shared definitions in these systems, it should not have to recreate them separately for every agent. Whether a particular integration achieves that reuse is something a customer can demonstrate, rather than infer from the architecture name.

A common management layer is part of the proposal

Salesforce also describes a new AI Control Plane: a common place to discover and register agents, establish identity and policy, manage their lifecycle, evaluate performance, observe behavior, and control cost. Its stated scope includes Salesforce and third-party AI.

A common view could help a team answer which agents exist and who owns them. It could also make management less fragmented as agents spread across applications. Those are useful reasons to examine the proposal, especially when different departments have built separate agent inventories.

But visibility and enforcement are different functions. For each permission or approval that matters, an implementation design should still name the system that enforces it. A dashboard showing an agent does not tell an architect which component rejects an unauthorized action. Our AgentCore Gateway analysis examines that narrower tool-call boundary; the Salesforce announcement addresses a broader architecture.

Salesforce says the harness is being built for headless access through technologies including MCP, APIs, Skills, and Plug-ins. Here, headless means capabilities can be used outside a single application interface. The announcement names experiences such as Claude, Slack, Microsoft Teams, and Agentforce. It does not provide a complete connector support table or establish that every control works identically on every surface.

Separate today's scope from the planned rollout

The availability section is unusually important for anyone receiving a proposal under the new name. Salesforce says many foundation technologies are available today. It places the start of the rollout for new capabilities and the unified experience in early fiscal FY28, with more availability, packaging, pricing, and upgrade details to follow.

Keep that fiscal wording in the proposal. The statement is not a calendar-date commitment to deliver every capability, nor a promise that an existing subscription includes the whole architecture. Salesforce also qualifies availability by region and customer agreement, and says customers should base purchasing decisions on currently available products and services.

For work that must begin now, ask the implementer to identify the exact product, licensed feature, and configuration that will perform each required function. Put roadmap-dependent work in a separate scope with its own prerequisites. This lets a team proceed with useful integration while keeping an announced future experience out of today's acceptance criteria.

Retire an integration only after its replacement works

The most consequential consolidation decision may be what to remove. An existing connector, policy service, or monitoring job can look redundant in a diagram while still performing work the proposed replacement has not demonstrated.

Start with one real workflow already in use. Record where it gets its business definitions, how it authenticates, where an approval is enforced, and where operators investigate a failed action. Then ask which existing Salesforce capabilities the proposed design reuses and which parts it changes. Keep the comparison at the level of actual components and responsibilities.

A constructed guide recommends keeping working controls, verifying reuse of licensed capabilities, and deferring integration removal until a replacement works.
Constructed diagramBaristaLabs recommendations for evaluating consolidation; not Salesforce product behavior or a test result.

Before removing an old component, have the replacement demonstrate the function that justified keeping it. If the old service prevents an unauthorized update, test the rejected update. If it records failed actions for operators, show where those failures can be found in the new design. Include the return path to the existing workflow if the trial fails. These are recommended acceptance tests, not results from a BaristaLabs trial of the announced harness.

This approach also makes a commercial conversation more concrete. A proposal can distinguish reuse of a capability already licensed, additional products needed for current work, and optional future consolidation. It need not guess a price for packaging Salesforce has not yet announced.

Salesforce's announcement gives existing customers a reason to revisit duplicated integration work. The next step is to prove where reuse is available now, while retaining controls and connections that still do necessary work. A future unified experience can become a later migration decision rather than an assumption built into today's project.

BaristaLabs' AI consulting can help review one existing workflow, identify reusable capabilities, and define the tests required before replacing an integration.

Source

AI integration review

Review one integration before replacing it

BaristaLabs can help identify reusable capabilities and define the checks a replacement must pass.

Bring a redacted workflow diagram and the products you already license.