Enterprises are learning how to build AI agents faster than they are learning how to operate them. AgentOps will emerge as the discipline that connects ownership, identity, permissions, observability, evaluation and intervention across the agent lifecycle – without turning operational control into a brake on useful innovation.
An AI agent can be impressive in a demonstration and dangerous in production for exactly the same reason: it can decide what to do next.
Once a system can select tools, retrieve data, call an application programming interface, update a record or trigger another agent, its performance can no longer be judged only by the quality of its final answer. The organisation also needs to know what authority it used, which path it took, what it changed, whether the outcome was acceptable and how to stop it when something goes wrong.
Most enterprises do not yet have one discipline responsible for answering those questions. They have fragments spread across AI engineering, DevOps, identity and access management, cybersecurity, workflow automation, risk, compliance and internal audit.
That gap is where AgentOps is beginning to form.
AgentOps will not necessarily arrive as a new department with a fixed reporting line. It is more likely to emerge first as a federated operating capability: a shared management layer, a common set of lifecycle practices and explicit decision rights spanning existing teams. In organisations where agents become a material part of how work is executed, that capability could become as important as DevOps. The category may remain contested. The operational need will not.
The management gap
The problem appears when agents start acting
The term AI agent is often applied too broadly. A conversational assistant that answers a question presents a different operational problem from an agent that can plan a sequence, use credentials and change the state of an enterprise system.
The distinction is authority.
A conventional software service follows logic that engineers have designed and can usually reproduce. An agent may choose among tools, adapt its plan to new information, retry failed steps, retrieve additional context or delegate work to another agent. Its actions remain bounded by software and policy, but its execution path may not be fully predetermined.
Consider a procurement agent asked to resolve a low-stock alert. It could examine demand, compare approved suppliers, check contractual terms, draft a purchase order and route it for approval. Each step may be individually reasonable. The enterprise risk appears in the chain: which demand data was trusted, whether the supplier was genuinely approved, which commercial threshold required escalation, whose authority the agent carried and whether a later model or policy change altered its behaviour.
This is not simply a model-monitoring problem. It is an operating problem involving identity, process, controls, evidence and accountability.
NIST's 2026 work reflects that shift. Its AI Agent Standards Initiative focuses on secure and interoperable agents acting on behalf of users, while its report on deployed AI systems says post-deployment monitoring practices, validated methods and common terminology remain nascent. NIST has also opened a specific programme of work on software and AI agent identity and authorisation. The signals point in the same direction: the difficult questions begin after an agent is connected to real systems and real authority.
The control gap
Existing disciplines miss the accountability chain
It is reasonable to ask whether AgentOps is merely a new name for work that mature enterprises should already be doing.
DevOps manages software delivery, infrastructure and service reliability. MLOps and LLMOps manage models, data, prompts, evaluations and deployment pipelines. Identity teams manage authentication and access. Security teams manage threats and controls. Workflow platforms manage orchestration and approvals. Governance, risk and compliance teams define policy and assurance requirements.
AgentOps overlaps with all of them. That is not evidence that it is unnecessary. It explains why the gap exists.
No single established discipline normally owns the complete chain from business intent to delegated authority, agent action, system outcome and audit evidence. DevOps can show that a service was available. An evaluation platform can show that an output met a quality threshold. Identity systems can show that a credential was valid. A workflow engine can show that an approval occurred. Internal audit can test whether a policy exists.
AgentOps must connect those records into one operational account of what happened and why.
The academic use of the term began largely around observability: tracing goals, plans, tasks, tool calls, knowledge retrieval, errors and evaluations across an agent's lifecycle. That remains foundational, but the enterprise discipline is becoming broader. It must govern the conditions under which an agent is allowed to act, not only explain its behaviour afterwards.
For small numbers of narrow, read-only agents, existing teams may absorb this work without creating a separate operating model. The case changes when agents become numerous, write-capable, cross-functional or customer-facing. At that point, local controls produce enterprise blind spots: duplicated agents, shared credentials, inconsistent approval rules, fragmented logs and unclear ownership.
The discipline becomes necessary when the seams become riskier than the components.
The analogy
The DevOps comparison is useful but incomplete
DevOps became strategically important because software delivery speed and operational reliability could no longer be managed as separate concerns. It created shared practices, automation and accountability across the release lifecycle.
AgentOps faces a comparable coordination problem, but the operational object is different.
Software services execute code. Agents combine code with probabilistic model behaviour, dynamic context and delegated authority. They may be technically healthy while making a poor decision. They may produce a plausible answer while selecting the wrong source, calling an inappropriate tool or acting beyond the user's intent. They may complete the task while creating a compliance, customer or commercial problem elsewhere in the workflow.
This changes what reliability means. Availability and latency still matter, but they are insufficient. An enterprise also needs to measure whether the agent chose an acceptable path, respected policy, stayed within its authority, used current information, escalated at the right point and improved the intended business outcome.
AgentOps will therefore borrow heavily from site reliability engineering, platform engineering, MLOps, security operations and governance. Its distinctive role will be to integrate those practices around an acting, non-human principal.
That is why the thesis should be qualified. AgentOps is unlikely to replicate DevOps as a single universal organisational pattern. It could, however, become equally important as an enterprise capability wherever agents mediate significant decisions and workflows.
The foundation
Identity creates operational control
The first AgentOps question is not which dashboard to buy. It is: who, or what, is acting?
An enterprise agent needs a unique identity, a named owner and a defined authority model. It may act on its own limited service authority, on behalf of a specific user or on behalf of a business process. Those are different conditions and should produce different permissions, approval requirements and evidence.
This is becoming visible in platform architecture. Google's Agent Identity assigns a distinct cryptographic identity to an agent and supports both agent-owned and user-delegated authority. Microsoft's Foundry Control Plane provides central visibility and lifecycle management for agent fleets. AWS Agent Registry provides a governed catalogue with approval workflows for publishing agents, tools and related resources. These vendor capabilities do not prove that one product category has won. They do show convergence around registry, identity, lifecycle and control.
The practical model should be least privilege by design. An agent should see only the tools required for its task, access only the necessary data, receive write permission only at the workflow stage that requires it and use short-lived authority wherever possible. A procurement agent may be allowed to read approved supplier data and draft an order, but not release payment. A service agent may amend a delivery address below a defined risk threshold, but require approval to issue a refund.
This turns autonomy from a vague product characteristic into a set of explicit permissions and escalation thresholds.
The evidence chain
Observability must connect intent to outcome
Traditional application monitoring asks whether the system is available, fast and error-free. Agent observability must ask a longer sequence of questions:
- What objective was the agent given?
- Which identity and permissions did it use?
- What context and sources shaped its decision?
- Which tools did it call, with what parameters?
- Where did it branch, retry or delegate?
- Which policies were evaluated?
- What changed in the business system?
- Was the final outcome useful, safe and economically sensible?
The answer cannot live in one model trace. AgentOps needs a linked evidence chain across agent runtime logs, identity records, policy decisions, workflow approvals, tool calls, evaluation results and business metrics.
This matters commercially as much as technically. A customer-service agent can reduce handling time while increasing rework. A coding agent can generate more changes while weakening maintainability. A finance agent can complete reconciliations faster while creating more exceptions for human review. Token cost, latency and task completion are operational metrics; they are not proof of value.
The control layer must therefore connect technical telemetry to outcomes such as cycle time, resolution quality, error rates, capacity released, customer impact and risk exposure. Without that connection, organisations may optimise the agent while degrading the process.
Runtime governance
Policies must operate during execution
Written policies cannot govern an agent at the moment it chooses a tool or attempts a transaction.
AgentOps translates governance intent into executable controls. That includes tool allowlists, data-access rules, transaction limits, approval gates, policy checks, anomaly thresholds, kill switches and rollback procedures. It also includes continuous evaluation, because an agent's behaviour may change when its model, prompt, toolset, retrieved knowledge or surrounding systems change.
The threat model is already wider than conventional application misuse. OWASP's Top 10 for Agentic Applications includes risks such as goal hijacking, tool misuse, identity and privilege abuse, memory poisoning, insecure inter-agent communication and cascading failures. These risks are significant because the model output can influence actions elsewhere in the technology estate, not simply the text shown to a user.
Human oversight remains important, but universal approval is not a scalable operating model. The stronger pattern is bounded autonomy: automate low-consequence actions inside clear limits, require approval where an action changes material state and route exceptions according to risk. OpenAI's agent tooling, for example, includes human-approval nodes before consequential actions such as sending an email through a connected service. The general principle is broader than any one platform: intervention should be designed into the execution path, not added as a policy statement after deployment.
Operational control also requires a credible stop mechanism. The enterprise must be able to suspend an agent, revoke its credentials, remove a tool, revert a version and preserve the evidence needed to investigate. An agent that cannot be rapidly constrained is not production-ready, regardless of its task accuracy.
The operating model
AgentOps should be federated, not isolated
Creating a new silo would reproduce the problem AgentOps is meant to solve.
The more durable model is likely to combine central standards with distributed delivery. A platform or AgentOps capability team can own the registry, control patterns, telemetry standards, evaluation infrastructure and lifecycle requirements. Business and product teams can own the purpose, workflow and performance of individual agents. Identity and security teams can own credentials, permissions and threat controls. Risk and audit teams can define evidence and assurance requirements.
Every material agent still needs three forms of ownership:
- A business owner: accountable for purpose, value and process outcomes.
- A technical owner: accountable for deployment, reliability and change.
- A risk owner: accountable for autonomy, permissions and control effectiveness.
These may be roles rather than new job titles. What matters is that the decision rights are explicit.
The operating model should also distinguish the lifecycle of an agent from the lifecycle of its underlying model. An enterprise may change the model without changing the agent's business purpose. It may add a tool without changing the prompt. It may alter a policy without redeploying the runtime. AgentOps must track these dependencies because each can change behaviour, risk and economics.
The leadership agenda
The capability matters before the category settles
Leaders do not need to wait for a complete AgentOps platform or a universally accepted definition. They need to establish a minimum viable discipline around every production agent that can take consequential action.
The immediate agenda is practical:
- Build the inventory: Register each production agent, its purpose, owners, models, tools, data sources, autonomy level and critical dependencies.
- Give every agent a controllable identity: Avoid shared credentials, define whether authority is agent-owned or delegated and make access revocable.
- Tier autonomy by consequence: Set explicit rules for read-only actions, reversible changes, financial or customer commitments and regulated decisions.
- Create the evidence chain: Link intent, identity, context, tool calls, policy decisions, approvals, outcomes, cost and evaluation results.
- Design intervention and retirement: Test pause, rollback, credential revocation, incident response, recertification and decommissioning before scale makes them urgent.
This agenda is designed to preserve speed. Reusable controls, standard identities, approved tool patterns and common telemetry reduce the need to reinvent governance for every use case. The alternative is not unconstrained innovation. It is a growing portfolio of agents that each move quickly while the enterprise becomes progressively less able to understand or control them.
AgentOps will become important for the same underlying reason DevOps did: a new production model creates a coordination problem that existing structures cannot solve separately.
The leadership test is not whether the organisation has adopted the label. It is whether it can prove, for every material agent, who owns it, what authority it carries, what it did, why it was allowed and how it can be stopped.
Where those answers are weak, the enterprise does not have an AI innovation problem. It has an operations problem that has not yet been named.
