Lexdatum.

Enterprise software is becoming a capability layer for agents

Salesforce’s Headless 360 direction shows the shift from exposing raw APIs to packaging governed business capabilities for any authorised agent.

First published31 August 2026

Read in Spanish →

Editorial diagram for Enterprise software is becoming a capability layer for agents

Salesforce’s Headless 360 direction shows the shift from exposing raw APIs to packaging governed business capabilities for any authorised agent.

Salesforce’s August expansion of Headless 360 makes a useful distinction: most MCP servers expose APIs; its stated aim is to expose trusted business capabilities.

That distinction points to the next layer of enterprise architecture. Agents should not have to reconstruct decades of business logic from raw endpoints. Nor should every team wrap the same API differently. The reusable asset is a governed capability that carries identity, permissions, validation and business semantics with it.

An API is not yet a capability

An API exposes an operation. A capability defines the business meaning and conditions around that operation.

Consider customer credit. A raw API might allow an account balance to be updated. A governed capability might:

  • verify the requesting identity;
  • retrieve the applicable customer and order state;
  • calculate eligibility under the current policy;
  • limit the maximum amount;
  • require evidence and a reason code;
  • route higher values for approval;
  • write the transaction and audit record atomically;
  • return a structured explanation.

An agent can use that capability without being granted arbitrary access to the account object.

Business logic must travel with the tool

Salesforce describes reusable skills that package orchestration, validation, resources and business logic. Whether implemented through Salesforce, another platform or custom software, the pattern matters.

When an agent discovers a tool, it should discover more than a function name. It needs:

  • purpose and intended users;
  • required permissions;
  • input and output schema;
  • preconditions;
  • consequence and risk level;
  • approval requirements;
  • idempotency behaviour;
  • expected evidence;
  • failure and retry semantics;
  • owner and version.

This metadata allows orchestrators to select tools more safely and gives security teams something concrete to govern.

Preserve the systems of record

The agentic narrative is often framed as replacing enterprise applications. In practice, large organisations cannot discard the identity, workflows, data models and controls accumulated in CRM, ERP, HRIS and service systems.

The more credible strategy is to make those systems callable through narrow, policy-aware interfaces.

The existing stack remains the system of record. Agents become an intelligence and execution layer across it.

That approach has three advantages:

  1. it preserves established controls and ownership;
  2. it reduces the amount of business logic recreated in prompts;
  3. it allows humans and agents to operate on the same underlying state.

Capability design prevents agent sprawl

Without shared capabilities, each new agent creates its own connector, validation and policy. In six months, the organisation has five ways to create a customer case and no confidence that they behave consistently.

A capability platform can reduce duplication. Domain owners publish approved operations. Agent teams consume them. Security and audit observe one contract.

The governance model should remain federated: finance owns finance capabilities; HR owns HR capabilities; the platform team owns common standards and runtime controls.

Do not confuse a skill catalogue with strategy

Salesforce reports more than 100 reusable skills in its repository. A large number is not automatically valuable. Tool abundance can make model selection worse, increase latency and expand attack surface.

Capabilities should be curated around real units of work. Discovery should be dynamic and permission-aware. An agent should see the smallest set relevant to the current task.

The catalogue also needs deprecation, compatibility tests and usage telemetry. A capability no one owns becomes operational debt.

A practical capability map

For each business domain, identify:

  • authoritative systems and data owners;
  • high-value operations;
  • current manual handoffs;
  • permissions and approval boundaries;
  • reusable reads, proposals and executions;
  • events emitted when state changes;
  • evidence required for audit;
  • consumers: people, workflows and agents.

The map often reveals that the highest-value work is not a new agent interface. It is cleaning and governing the capabilities that many interfaces can share.

The Lexdatum view

The future enterprise stack is not “one agent replacing every application”. It is a network of trusted capabilities available to authorised humans, workflows and agents.

MCP can make those capabilities discoverable. Skills can package how to use them. The existing enterprise platform can preserve state and policy.

The strategic asset is the contract between intelligence and operations.

Sources


Research note: This analysis is based on public information available on 31 August 2026. Product capabilities, prices and regulatory interpretations can change. Vendor-reported metrics are identified as such. This is not legal, security or investment advice.

Discuss this architecture with Lexdatum

Discuss this architecture

A 60-minute conversation with a partner. No commitment, no sales script. If this architecture fits a real problem, we will tell you how to start.

Discuss this architecture