MCP is becoming an important building block for enterprise AI. But there is a misconception worth avoiding: connecting an LLM to many tools is not the same as building a reliable agent.
MCP solves an important part of the problem by providing a common way to describe, discover and invoke capabilities. It does not decide which operations are safe, which state is valid, how to recover after failure or when human approval is required.
The protocol is the beginning, not the architecture
A model is probabilistic. A business process contains elements that must remain deterministic: permissions, state transitions, constraints, versions, approvals and irreversible operations.
Enterprise architecture therefore cannot collapse into LLM → tool call. It needs a layer that turns model reasoning into governed action: the harness.
A real-world example: Headless 360
Salesforce chose a compact surface of Discover, Describe, Dispatch and Dispatch Read Only rather than exposing thousands of operations directly. Its developers explicitly cite context, token and time costs as part of the reason (Salesforce Developers Blog).
For the architectural shift behind it, see What Headless 360 really means for enterprise software.
What a good harness needs to do
An enterprise harness should control capability exposure, identity and permissions, input validation, persistent state, read-versus-write boundaries, approval gates, audit and recovery without repeating already committed actions.
This lets the model focus on what it does best: understanding intent, interpreting context, choosing strategies and composing capabilities.
More autonomy requires more determinism
The more autonomous the agent becomes, the stronger its deterministic boundaries must become. If an agent changes operational state, the system needs certainty about what has already happened.
Human-in-the-loop is part of the process
Putting a confirmation button in front of every tool call is not governance; it is friction. A good harness distinguishes risk and reversibility so that low-risk operations can execute inside policy while consequential actions can require human approval.
From orchestration to software construction
The issue becomes even more important when AI can build or modify persistent processes. We explore that transition in After Headless 360 and in Business Vibe Coding: when AI builds processes, not code.
The competitive advantage moves outward from the model
Models will continue to improve and often become interchangeable. Discovery, policy, state, audit, versioning, approval and recoverability are therefore not implementation details. They are what turns an agentic demo into enterprise infrastructure.
MCP can become the common language. The harness determines whether that language produces tool calls or work that is actually completed.
Frequently Asked Questions
No. MCP standardizes access to capabilities, while authorization, validation, persistent state, recovery and governance depend on the architecture around the model.
It is the runtime, rules, controls, state, permissions and execution mechanisms that constrain and govern what a model can do.
An agent can fail after some operations have already succeeded. The system must know persistent state and resume without duplicating or corrupting completed work.