Why the same model delivers different results: enterprise agents read through five layers, agent · harness · MCP · zero trust · multi-agent
October 7, 2026 | SKYWARE INSIGHT
More and more companies are saying, “We adopted an AI agent, but it doesn’t do as much as we expected.” In most cases, the model isn’t the problem. With the same model, one company receives an automated operations report every morning while another stalls at chatbot level. The difference lies in the structure surrounding the model: the harness, the connection standard and the permission design.
This article explains enterprise agents in five layers: the agent (the one doing the work), the harness (the framework that makes it work), MCP (the standard for connecting tools), zero trust (permissions and records), and, on top of these, multi-agent systems in which agents assign work to other agents. We use a single example throughout: “Analyze yesterday’s message delivery failures and create an operations report.”
Figure 1 · The five layers of an enterprise agent
- 5Multi-Agent05A lead agent divides work by role, and permissions shrink with every delegation
- 4Zero Trust04Identity · least privilege · execution approval · access logs for every agent, enforced at the MCP server and API
- 3MCP03Exposes enterprise systems such as sOMP · SCOS · monitoring as standard tools
- 2Harness02Tool definitions · context management · approval points · rollback · evaluation loops · everything outside the model
- 1AI Agent01The actor that takes a goal, plans, calls tools, reviews results and chooses the next task
Each layer stands on the one below it. There is no harness without an agent, and multi-agent systems are risky without permission controls.
01. Agent · An Actor That Takes a Goal and Chains Tasks on Its Own
A chatbot answers a question and stops. An agent, given a goal, makes a plan, retrieves the data it needs, reviews the results and chooses the next task. Asked to analyze delivery failures, it pulls the delivery result logs, groups them by error code, cross-checks them against carrier outage notices, drafts a report, and queries again if the evidence is insufficient.
The decisive change here is that models can now call external systems. From that moment, the focus of design shifts from “what the AI knows” to “what the AI can execute.” The other four layers are all mechanisms for answering this question.
02. Harness · The Framework That Wraps the Model and Puts It to Work
The harness is everything that runs outside the model. It is why the same model can produce vastly different results.
- Tool DefinitionsWhich tools to show the agent, and with what descriptions. Vague descriptions lead it to call the wrong tool.
- Context ManagementWhat to remember and what to discard during long tasks. Feed it tens of thousands of log lines at once and it forgets the beginning.
- Approval PointsWhere to stop and get human confirmation. Queries run automatically; resends require approval.
- Rollback · RetryHow to recover when something goes wrong, and how many times to retry.
- Evaluation · LoggingHow to verify results and which logs to keep.
The coding agent Claude Code reliably repeats the flow of “read the file → fix it → run the tests → fix again if they fail” not so much because the model is special, but because the harness holds this loop in place. Skyware found the same while using Claude Code in its development work: deciding when to run tests and where a person checks changes before they reach production made a bigger difference to results than deciding which tasks to assign.
03. MCP · A Common Standard for Connecting the Harness to Enterprise Systems
To analyze delivery failures, the agent needs access to delivery results from the unified messaging system (sOMP), monitoring metrics, carrier outage notices and past incident history. In the past, integration code had to be written separately for each system. MCP (Model Context Protocol) is a protocol that publishes, in a standard format, “these are the tools and data this system provides, and this is how to call them.”
Attach one MCP server to sOMP, and any agent can use a “query delivery results” tool in the same way; attach one to SCOS for “query orders,” or to monitoring for “query metrics.” In other words, MCP standardizes the harness’s tool definition layer on the enterprise system side.
The added convenience brings added risk. If an MCP server exposes both “query delivery results” and “resend,” the agent can call either. It could even be tricked by instructions hidden in an external document (prompt injection) into calling resend. Deciding which tools to open becomes security design in itself.
04. Zero Trust · Controlling Agents Like Employees
Zero trust is the principle of “don’t trust something just because it’s on the internal network; verify identity and permissions every time.” The moment an agent connects to a system through MCP, it becomes an access subject in its own right, so the same principle must apply.
- Independent Identity Distinguishes which agent made a call on behalf of which user.
- Least Privilege A reporting agent gets only query tools. “Resend” is not even visible to it.
- Execution Approval The MCP server rejects sending · payment · deletion without an approval token.
- Access Logs Keeps an audit log of which tools were called with which inputs.
The key is to enforce these controls through the permission systems of the MCP server and API, not through prompts (“don’t resend”). Instructions can be manipulated, but calls without permission simply don’t execute. This is also the point addressed by the US NIST in 2026 when it published a concept paper on the identity, authorization, access delegation and logging of AI agents, along with guidance on agent token security (IR 8587).
05. Multi-Agent · Agents Assigning Work to Agents
In real work, a single agent doesn’t do everything. Much like a human organization, a lead agent breaks the work down, hands it out to role-specific sub-agents, and combines the results into a final answer. Organizing the delivery failure analysis as a team looks like this.
Figure 2 · An agent team assigned to analyze delivery failures
- Log Collection AgentDelivery results · error codes · totals by carrierMCP: sOMP delivery result query · monitoring metricsPermission: read
- Root Cause Classification AgentFailure type classification · comparison with past cases · candidate causesMCP: incident history · internal document searchPermission: read
- Report Writing AgentSummary · items to verify · draft recommendationsMCP: document templates · report saving (drafts)Permission: save drafts
Permissions only ever shrink with each delegation. Even if the lead agent says “resend,” a sub-agent with read-only permission cannot execute it, and every call is logged along the path “manager → lead agent → sub-agent.”
There are three reasons to split the work. If one agent handles a long task alone, its memory (context) overflows and it forgets the beginning; when the work is split, each agent only needs to remember its own share. Each role can be given different tools and permissions. And because the agents are independent, they can run in parallel, and if one gets something wrong, the verification agent catches it. Claude Code uses the same structure on complex tasks: it launches separate research sub-agents to sweep the codebase, while the main task simply takes their results and carries on.
There are pitfalls, too. Agents confirming one another can end up wrong together, an “illusion of consensus.” The verification agent must look at actual logs and numbers, not at what other agents say. And as the number of steps grows, cost and time multiply. This is one reason Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027 due to costs and unclear business value. Not splitting a job that two or three agents can handle into ten is also part of good design.
06. Five Layers in One Flow
The agent receives a goalThe harness runs the plan · tool · approval · logging loopMCP opens enterprise systems as standard toolsZero trust enforces permissions for each toolThe lead agent delegates by role
That is why the real work of enterprise AX is not “choosing a good model.” It is designing how far to open your systems through MCP, where to place approvals in the harness, and how to scope permissions. This design can only be done by those who know the APIs, data structures and permission systems of existing business systems.
This is why Skyware says it is carrying more than 20 years of experience building and operating commerce, messaging and business systems into AX. Which tools to open in sOMP and SCOS, and where to place approvals, is a line best drawn by those who built those systems.
An agent’s performance is determined by the harness, not the model, and an agent’s safety by permissions, not prompts.
References: Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027” (June 2025) · NIST NCCoE, “Software and AI Agent Identity and Authorization” concept paper (February 2026) · NIST IR 8587 (September 2026) · Model Context Protocol specification