A large company can discover that it operates hundreds of AI agents long before it has agreed who owns them. Some were built by engineers using APIs; others were assembled in a low-code platform by a business unit; still others arrived as a feature inside a purchased software service. ModelOp is targeting that organisational problem with version 3.5 of its Center platform, announced on 22 October. The release brings Microsoft and Amazon agent environments into a common discovery, approval and usage-reporting workflow. It is a product-development announcement, not independently demonstrated proof that enterprise AI incidents are falling.[1]
The vendor describes deeper integrations with Microsoft Agent 365, including Copilot Studio and Foundry, and with Amazon Bedrock AgentCore, Amazon Bedrock and Amazon Quick. The product is meant to give central risk, technology and finance teams a single view of AI activity even when the agent itself lives in another provider's platform. That is increasingly attractive as AI deployment moves beyond a small central machine-learning group to operational teams with their own budgets, suppliers and permissions.[1]
First discover what the organisation has
An inventory is the unglamorous foundation of governance. A company cannot assess an agent's ability to read customer data, send email or change records if it does not know the agent exists. ModelOp says new integrations can identify agents across connected services and feed them into intake and approval workflows, assigning ownership and controls proportional to risk. These are distinct jobs. Discovery records an object; approval defines who may put it into service; runtime enforcement prevents an unauthorised action.[1]
That sequence has practical failure points. An integration can list a service object but miss a private script calling a model directly. An approval workflow can be completed while the agent's API permissions are later expanded. A central platform can record a risk policy that the underlying cloud system does not actually enforce. Buyers should therefore ask what each connector can enumerate, how often records are refreshed, what permissions it needs and exactly which control decisions propagate back to the execution layer.[1]
Counting tokens by business purpose
What is new in the enterprise governance release
| Measure | Verified result or scope |
|---|---|
| Version and date | ModelOp Center 3.5; 22 October 2026Source 1 |
| Microsoft integrations | Agent 365, Copilot Studio and FoundrySource 1 |
| Amazon integrations | Bedrock AgentCore, Bedrock and Amazon QuickSource 1 |
| Administrative workflow | Discovery followed by intake and risk-proportional approvalSource 1 |
| Usage reporting | Tokens by business use case, model and providerSource 1 |
| Not independently demonstrated | Reduction in incidents, breaches or overall costSource 1 |
The release also introduces an AI usage dashboard that connects token consumption with individual use cases, providers and models. Traditional cloud cost centres often show an invoice for the shared team or infrastructure account that hosts the agent. They do not always reveal whether usage came from drafting contracts, customer-support triage or a poorly designed loop that repeatedly calls an expensive model. A use-case register can make that distinction visible to the managers who decide whether the work is worth its cost.[1]
Token accounting is only a partial picture of economic value. The cost of a business workflow also includes retrieval infrastructure, storage, application licensing, monitoring, staff reviews, failed calls and compliance obligations. Likewise, a falling price per token does not prove that a business process is more efficient if the agent makes more calls or generates work requiring extensive corrections. Proper AI FinOps needs a denominator tied to useful completed work, not just a colourful dashboard of requests.[1]
Governance claims need tests
ModelOp markets its system as a control centre that moves agents from unmanaged to governed through lifecycle workflows. That may reduce administrative friction, but the launch material does not provide a neutral before-and-after comparison demonstrating reductions in data leaks, agent misuse or approval times. The most important buyer questions are therefore concrete: can a test agent be blocked from accessing a restricted record? Does the central workflow prevent publication before approval? What happens when the cloud integration fails? Can auditors reconstruct the exact version, owner, policy and permissions active at the time of an incident?[1]
Enterprises should also treat discovered records as sensitive assets. An inventory of agents can reveal business processes, connected systems and access paths. The oversight tool needs strong role separation, least-privilege connector credentials and a defensible retention policy. A central governance database is valuable partly because it concentrates context—and risky for exactly the same reason if its security is weak.[1]
A useful infrastructure layer, subject to proof
ModelOp's release illustrates the next competitive layer in enterprise AI: not another chatbot, but software that supervises many chatbots and agents from different suppliers. Centralising ownership, risk intake and spend analysis is a reasonable design response to fragmented deployment. Whether the specific connectors reliably find shadow agents and enforce policy will depend on customer configuration and independent testing. The durable principle is that knowing which agents exist, knowing what they can access and actually constraining their actions are three different requirements. Mature governance has to meet all three.[1]
Sources & further reading
- What’s New in ModelOp Center 3.5 ModelOp · 22 Oct 2026 · Accessed 26 Oct 2026