TL;DR Summary: Agentic fabric addresses the challenge of trust in AI agents by enforcing controlled execution and governance across systems. It establishes a framework for managing agent actions, enhancing operational trust through established protocols.
Agentic fabric is crucial for managing the increasing number of AI agents in enterprises.
Execution discipline ensures that agents operate with oversight, maintaining accountability and traceability.
CIOs and operations leaders have one concern about AI agents that outranks the rest. An agent changes a production system, and no one can say who approved the change or how to reverse it. Agentic fabric is the industry’s answer, and most of the conversation about it covers discovery, governance, and coordination. The part that determines whether an agent is trusted to act is execution discipline, and it gets the least attention.
The fabric conversation is about the agents themselves. How many there are, what they can reach, who owns them, how they obtain credentials. Those are fair questions, and in most companies the answers are overdue. But operations teams do not trust a process. They trust the controls around it, and the record it leaves when something goes wrong. That standard has held for scheduled jobs, for scripts, for integrations no one remembers writing. I see no reason it should change for agents.
The problem agentic fabric is meant to solve
Agentic fabric is a category, not a product. The term describes the architectural layer that connects, governs, and observes AI agents as they work across systems, data, and one another. The concern behind it is legitimate. Agents arrive through productivity suites, SaaS platforms, departmental initiatives, and internal development teams, and few organizations can count them accurately. Gartner predicts that the average global Fortune 500 enterprise will have more than 150,000 agents in use by 2028, up from fewer than 15 in 2025, and reports that only 13% of organizations believe they have the right AI agent governance in place.[1] At that scale, discovery, permissions, and visibility become baseline requirements.
The difficulty is that the term carries a different meaning depending on who uses it, and several vendors now attach similar names to products of their own. Identity providers describe an identity control plane for agents. Integration platforms describe a registry and a broker. Productivity suites describe a console for the agents within their own applications. Each account is partly correct, and each adds a layer that operations teams must reconcile with the ones they already run. No single product is the category. A fabric that deserves the name covers all of it, including the part that decides whether an agent acts.
A registry establishes which agents exist and what they may access, but not whether the work an agent performed should have proceeded, or how to reverse that work if it should not have.
Where operational trust comes from
Consider a bank after the close of business. Its systems post the day’s transactions, reconcile the accounts, and prepare the regulatory reports that must be ready by morning. No one reviews each step, and no one is expected to. Each job starts only when its inputs are present. It waits on upstream work, meets or misses a defined service level, halts when a condition fails, and leaves a record complete enough to reconstruct any outcome. The job may be simple or sophisticated. The trust lies in the execution that surrounds each job.
Agents change the worker without changing that principle. An agent reasons where a script follows instructions, and that flexibility is why teams hesitate to let agents act. The remedy is to bring agent actions inside the execution discipline that already governs the systems they affect. That discipline sets conditions a step must satisfy before it runs, requires approval where the consequences warrant it, and supports recovery when a result is wrong. It also keeps an audit trail that records what ran, on whose authority, and why. That discipline is where operational trust comes from, and it applies to agents as it does to everything else in production.
What mainframe practitioners are telling us
Why will practitioners accept an AI recommendation but hesitate to let AI carry it out? The teams responsible for the most critical systems have answered with a line they draw more sharply each year. In the 2026 BMC Mainframe Survey of more than 1,300 practitioners and decision makers, willingness to let AI recommend an action rose in each of the three operational tasks the survey tracks year over year, and willingness to let AI complete the action fell in each of them. Database reorganizations show the pattern most clearly. In a single year, the share of practitioners who welcome an AI recommendation rose from 37% to 43%. Over the same period, the share who would let AI complete the work fell from 27% to 21%. Problem diagnosis tells a similar story, as recommendation climbed to 41% while completion slipped to 23%. Code management, a newer line of questioning, lands in much the same place. There, 40% are willing to accept a recommendation, and only 23% are willing to let AI act on it.[2] The report draws the conclusion itself. Willingness to use AI to complete actions is trending downward, replaced by a preference for AI that recommends and a human operator who acts.
These results are sometimes read as reluctance. I read them as a boundary that practitioners have set deliberately. A recommendation asks them to trust the model. Execution asks them to trust the controls around the action, and those controls are what most agent deployments still lack. They accept AI’s advice more readily each year, and decline to let it act on that advice until execution carries the same controls as everything else in production. The same survey finds that 36% of respondents plan to invest in creating agents to manage the mainframe. The intent is clear. What remains unresolved is how to move from recommendation to action without lowering the standards that keep these systems running.
Extending autonomy in stages
No enterprise grants a new hire unrestricted production access on the first day, and agents warrant the same caution. Gartner cautions that applying uniform governance to every agent, regardless of its autonomy and scope, can lead to failure. It predicts that by 2027, 40% of enterprises will demote or decommission autonomous agents after governance gaps surface in production incidents.[3] Applying the same restrictions to every agent stalls the value agents exist to deliver. Extending the same trust to every agent invites the incident that ends the program.
Execution provides the intermediate position. A single workflow can permit an agent to act without review on a low-risk step, require human approval on the next, and hold a third for inspection until the agent’s record justifies more room. Evidence from each successful run can inform that decision, the same way a new engineer earns production access over time. That latitude can be withdrawn just as quickly when something goes wrong, because the controls reside in the workflow rather than in the agent.
Bringing agents into the existing control plane
Few organizations will want a separate operating model for agents alongside the one that already coordinates their applications, data pipelines, and infrastructure. From an architecture standpoint, I would advise against a separate model. A second control plane is a second place for policy to drift, a second set of credentials to protect, and a second audit trail to reconcile when an auditor asks what happened. The more durable approach treats agents as one more participant in the workflows enterprises already orchestrate, subject to the same dependencies, service levels, and audit requirements as everything else.
The question to ask before choosing a fabric
Agentic fabric is a category, and the market will keep adding products to it. The requirement behind the category will not change, and it is an execution requirement. Agentic fabric helps enterprises discover, govern, and coordinate agents. The execution discipline connected to it determines whether those agents are trusted enough to act. When those controls operate independently of any one agent, they can be applied consistently to every agent, regardless of how it was built. Autonomy can expand as evidence accumulates, and each step can be revoked when risk changes. Agents belong in the control plane an enterprise already operates, because a new layer adds reconciliation work and the existing one already holds work accountable.
Execution discipline is a practice enterprises have followed for decades. The work ahead is extending it to a new kind of worker. Before selecting a fabric, I would put a more demanding question to the work itself. When an agent acts on a critical system, can the organization show what ran, what it depended on, who approved it, and how to reverse or contain it if needed? Organizations that can answer yes will extend autonomy to agents with confidence. The others will keep AI in an advisory role, not because the models are inadequate, but because the execution is.
For BMC’s view of the agentic fabric category, see When It Comes to Agentic Fabric, What’s Interesting, Important, and Immediate?
For the full findings on where mainframe practitioners are drawing the line between AI recommendation and AI execution, see the 2026 BMC Mainframe Survey Report.
[1]: Gartner, “Gartner Identifies Six Steps to Manage AI Agent Sprawl,” press release, April 28, 2026. https://www.gartner.com/zh/newsroom/press-releases/2026-04-28-gartner-identifies-six-steps-to-manage-artificial-intelligence-agent-sprawl
[2]: BMC Software, 2026 BMC Mainframe Survey Report, “How AI Is Driving the Next Era of Mainframe Transformation,” pp. 4, 7, and 9. https://www.bmc.com/info/mainframe-survey.html
[3]: Gartner, “Gartner Says Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure,” press release, May 26, 2026. https://www.gartner.com/zh/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure
These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.