What changes with the Enterprise AI Harness
Salesforce has released a new architecture, the Enterprise AI Harness, designed to give agents a shared understanding of the customer and the enterprise, as reported on the official page[1].
The project combines six capabilities, called context, agentic, action, governance, security and models, distributed across a common and composable architecture. Around these capabilities a new Control Plane is born, designed to give companies a single point from which to view, manage and control agents as they multiply across the enterprise.
The stated objective concerns the execution of complex tasks, such as answering the question "can we fulfill this order today?", which requires data scattered across CRM, ERP, contracts and internal policies. An agent must understand that context, decide the right action, and act within the boundaries set by the enterprise. The technical promise is high: open reasoning connected to controlled execution.
Six capabilities, one control point
The architecture allows customers to use the six capabilities as an integrated system, or take only the useful pieces, with Salesforce technology, existing systems, or both. This includes third-party models, agents and systems, a detail that shifts the discussion from a single product to the orchestration layer.
Context becomes shared between agents and models, and actions become workflows reusable across the organization.
On paper, composability reduces duplicate work across teams that today build isolated agents. Reality described in AWS's monthly report shows a similar trend: shared frameworks to accelerate agent deployment, as noted in the AWS August 2026 summary[2]. The open question concerns what happens when one of these composable pieces fails inside a chain of connected agents.
The architectural gap: missing circuit breakers
The public documentation of the Enterprise AI Harness describes capabilities and objectives, and lacks technical details on validation mechanisms between agents.
A multi-agent system without explicit circuit breakers fails in cascade when the output of one agent becomes the input of the next, in the absence of independent control. Their absence allows error to propagate along the entire chain.
The Control Plane promises visibility into who does what, where and when. On the official page, the documentation lacks references to execution limits per agent, error thresholds that block the chain, or automatic rollback processes. This documentation gap counts as technical debt from day one of adoption.
Agent identity: the missing control plane
The Control Plane manages agents at scale, and scale requires verifiable identities, nominative logs, and the ability to revoke a permission pointwise. The Salesforce page lists "governance" and "security" among the six capabilities, and lacks specification of how each agent's identity is assigned, tracked or revoked.
An enterprise adopting agents at industrial scale, in the absence of formal identities for each one, finds itself unable to revoke a permission when an agent takes action outside policy.
The issue concerns the entire industry: 91% of enterprises claim to have agents in production, and only 22% treat them as formal identities, according to data cited in previous desk analysis. Salesforce describes a control plane capable of seeing agents, and lacks clarity on whether each agent receives its own distinct credentials from those of the user who launched it. The distinction matters, because agent identity is the control plane of the next cycle of enterprise adoption.
The recurring pattern: infrastructure faster than security
The gap between orchestration and governance follows a pattern already seen in agentic frameworks over the past two years.
Semantic Kernel, Langflow, PraisonAI and Cursor have shown critical vulnerabilities capable of turning a retrieved document into remote execution, with CVSS scores near maximum. The sequence repeats: rapid production adoption, security hardening that comes after, when damage is already measurable.
Kinaxis, in the report published by Microsoft on its supply chain, shows a case of agents applied to complex processes with documented operational benefits, as described in the Microsoft Kinaxis story[3]. The case confirms that multiple agents, orchestrated with care, bring measurable value in real production environments. What remains to be understood is how much of that value depends on specific controls, built case by case, and how much on the generic framework adopted.
Three questions for enterprise AI teams
Before signing a contract with any agentic Control Plane vendor, three operational questions deserve documented answers.
- What mechanism interrupts a chain of agents when an output exceeds a defined error threshold?
- How is each individual agent's identity in the system assigned, tracked and revoked?
- What nominative audit trail exists for every action taken by an agent on production data?
Decisions for CTO, Head of Engineering, CFO and Procurement
For the CTO, the question concerns which part of the existing stack needs to be re-evaluated before adopting a composable Control Plane. For the head of engineering, the choice shifts to which framework to test in an isolated environment before connecting it to production systems with real data.
For the CFO, the infrastructure investment becomes riskier when the contract lacks clauses on independent security audits and SLAs for agent revocation.
The technology procurement committee should renegotiate every vendor contract that describes "governance" and "security" as generic capabilities, in the absence of verifiable mechanisms explicitly listed. The composability of the architecture, in the absence of these details, shifts risk from vendor to customer. Those adopting today a Control Plane lacking public specifications on execution boundaries, sign a contract that accumulates technical debt from day one.
Trap or competitive advantage?
The Enterprise AI Harness remains a technically coherent architecture, capable of bringing together capabilities that today many companies build in isolated and redundant ways. The competitive advantage truly exists when the company adopting it accepts building, above the Salesforce layer, the validation controls that public documentation currently lacks specification of.
The promised composability becomes an architectural trap when teams believe that "governance" and "security," listed as capabilities, automatically coincide with circuit breakers and verifiable identities already ready to use.
Google Cloud, in the KDDI case on RAG performance optimization through Agent Development Kit, shows how the context layer requires specific tuning to work in production, as reported in the case published by Google Cloud[4]. The parallel with Salesforce is direct: no agentic architectures arrive ready to use, in the absence of dedicated engineering work on the control layer.
The question every technical team must ask before the next procurement cycle concerns what happens when this architecture breaks, and who, inside the company, has the responsibility to respond.
This article was written by an AI editorial author with human supervision, in compliance with the transparency obligations of Regulation (EU) 2024/1689 (AI Act, Art. 50). Sources are linked in the text.
Article by LEON
Sources
- official page 10 Sep 2026 (salesforce.com)
- AWS August 2026 summary (aws.amazon.com)
- Microsoft Kinaxis story (news.microsoft.com)
- case published by Google Cloud (cloud.google.com)