Delivery and operating ownership
AgentOps vs DevOps
Connect DevOps delivery practices with agent behaviour, source changes, action authority and continuing business ownership.
AgentOps and DevOps are complementary. DevOps provides practices for building, changing and operating software reliably across team boundaries. AgentOps applies additional attention to agent behaviour: which tasks are accepted, what authority an agent has, which actions occur, when people intervene and whether the business outcome is confirmed.
The distinction should improve ownership, not create an organisational contest. A mature DevOps team already manages configuration, testing, observability and recovery. An agent service needs to connect those capabilities to its task and action contract. The right question is what evidence and decisions must be added to the existing delivery and operating process.
DevOps already covers more than code deployment
DORA's continuous delivery guidance addresses reliable release of different kinds of change, supported by collaboration, testing and observability. Its current version-control guidance explicitly includes AI artifacts such as instructions and agent configuration. Therefore, describing DevOps as code-only and AgentOps as the first discipline to manage configuration would be misleading.
The practical addition is agent-specific acceptance. A deployment can be technically sound while the service chooses an unsuitable tool, relies on an obsolete source or leaves an external action unresolved. Those failures need task evidence and business authority in the same operating process that handles application health.
Similarly, DevOps is not automatically responsible for deciding which employee may approve an agent action or what a business function considers an acceptable result. Those decisions need the service owner and relevant control owners. AgentOps, MLOps, LLMOps and AIOps explains the adjacent responsibilities when several AI components are involved.
Illustrative example: equipment request ER-38
Consider an internal equipment-allocation assistant. It reads an approved catalogue, prepares an allocation proposal and submits it to a responsible manager before any reservation is made. Task ER-38 concerns a display unit. The example is hypothetical and uses synthetic inventory records.
The application release remains unchanged, but a catalogue update marks that unit as restricted to a specialist team. An old cached catalogue still allows the general allocation path. The deployment pipeline has not failed: the behaviour changed because the source and its freshness contract changed. The service needs a clear owner for that relationship.
The agent should not turn a catalogue description into permission. The allocation control must evaluate the current applicable rule. Monitoring should identify which catalogue revision and authorisation decision were used. If a reservation was already confirmed before the restriction changed, reverting the application image alone does not cancel that reservation.
Use one change register with different acceptance owners
| Change | Delivery evidence | Agent-specific acceptance |
|---|---|---|
| Application or runtime | Build, dependency, security and deployment checks | Representative task behaviour and preserved operating evidence |
| Instructions or orchestration | Versioned artifact and tested promotion path | Task choices, escalation and action boundaries |
| Catalogue or retrieval source | Source revision and controlled update procedure | Freshness, applicability and effect on accepted work |
| Tool contract or permission | Interface compatibility and security validation | Allowed actions, uncertainty handling and external confirmation |
| Human review process | Workflow configuration and access tests | Decision rights, queue ownership and resumed-task behaviour |
| Telemetry configuration | Exporter, schema and pipeline verification | Continued ability to reconstruct and judge tasks |
The table is a proposed division of evidence, not a requirement to create separate release boards. One coordinated process can collect the technical and business approvals it needs. The important property is that a change cannot bypass relevant acceptance merely because it lives outside the application repository.
For ER-38, catalogue ownership sits with the responsible business function, cache behaviour with engineering, action permission with the appropriate control owner and end-to-end operation with the service owner. Record those named roles rather than assigning everything to a generic AI team.
Extend the pipeline with behavioural evidence
Keep automated builds, deployment checks and security tests. Add representative task cases that exercise valid completion, rejection, missing information, human review and uncertain external results. Define the expected state and prohibited effects before running the cases. A test that merely checks that the agent returned text does not establish task correctness.
Separate deterministic assertions from judged qualities. The current catalogue revision and a permission result can be verified directly. Whether an explanation is clear may require reviewed criteria. Preserve the evaluator or reviewer version so a changed judgement is not mistaken for a changed application.
Include the combination of artifacts in the release evidence: code, model configuration, instructions, source reference, tools and operating policy. A component approved alone may interact badly with another revision. Agent release control provides the deeper promotion and stop decisions. Integrate those decisions with existing delivery automation rather than maintaining an unconnected approval trail.
DORA's deployment automation guidance supports repeatable execution of deployment work. Repeatability remains valuable for agents, but it does not eliminate behavioural uncertainty. Use automation to apply the approved configuration consistently and expose results quickly; retain accountable decisions for consequences the tests cannot establish automatically.
Operate the service after deployment succeeds
The delivery pipeline ends a release step; the task service continues. Someone must own ageing review queues, rejected outcomes, tool failures, resource consumption and changes in input conditions. Microsoft's agent lifecycle guidance includes monitoring, improvement and retirement, reinforcing the need for continuing ownership.
For ER-38, the operator should be able to identify the current state, the manager responsible for review and whether a reservation is merely requested or confirmed. A technical team can diagnose a timeout, but the business owner must establish the appropriate disposition when the unit is no longer eligible.
Use production agent monitoring to connect task states with service health. Keep application incidents and business exceptions distinguishable, while assigning a coordinator for cases that cross both. An infrastructure recovery can restore the service while leaving earlier tasks unresolved.
Separate software rollback from business recovery
Rolling back a software or configuration artifact changes future execution. It does not automatically undo messages sent, records updated or reservations confirmed by an earlier attempt. Maintain a separate reconciliation process for external state, including who may cancel, correct or accept an outcome.
In the equipment example, first identify whether the reservation exists. Then apply the authorised business decision. Do not repeatedly replay the task while guessing about the receiving system. The versioning and rollback guide explains the evidence needed to restore a compatible operating configuration without confusing it with reversal of business effects.
Capture the incident as a shared learning record. Platform engineering may improve cache invalidation; the business owner may clarify catalogue effective dates; the agent team may add a task test and escalation path. A blame-oriented handoff to “the model” would miss the actual control gap.
Choose a team arrangement that fits the service
A small team can combine application engineering, platform operation and agent evaluation if the decision rights are clear and the workload is supportable. It still needs a business owner for acceptance and a route for independent review where consequences warrant it. Creating a separate AgentOps department is not a prerequisite.
A larger enterprise may use a central platform team for common telemetry, runtime and deployment capabilities, with service teams owning tasks, data sources, evaluation and exceptions. The boundary should specify which incidents the platform resolves and which decisions remain with the service. Shared tools do not imply shared authority over every business action.
An external partner can supply agreed setup, specialist review or operating support, but the contract must identify the customer's retained decisions. Managed AgentOps covers that scope, while human oversight defines the roles inside the task process. Avoid assuming that a support contract transfers business accountability without explicit agreement.
Measure delivery and task performance separately
Delivery measures help the team improve how changes reach production. Task measures help the owner determine whether the service accomplishes its intended work. Both are useful, but an increase in deployment frequency does not by itself prove better agent outcomes, and an outcome improvement does not excuse an unreliable release process.
Review the connection: which changes improved accepted outcomes, reduced unresolved work or made investigation easier? Keep the measurement definitions and eligible task population clear. Do not reward an apparent improvement that comes from excluding rejected tasks or moving manual work outside the reporting boundary.
Use incident evidence to choose the next engineering investment. If failures come from unclear permission rules, a faster build pipeline alone will not resolve them. If releases are inconsistent, additional manual review of outputs will not repair deployment reproducibility. Assign the work to the layer that can change the cause.
Make the operating handover explicit
A useful handover contains more than source code and a deployment pipeline. Include the task contract, approved artifact combination, ownership map, review queues, monitoring definitions, recovery procedure and evidence from representative failure tests. Identify who can pause the agent and how pending work is treated.
The AgentOps handover guide turns those responsibilities into acceptance evidence. A recipient should be able to operate the service and make its permitted decisions without depending on undocumented knowledge held by the original developer.
Discuss how AgentOps fits your existing DevOps model with an ownership map and one change that altered agent behaviour without a new application release. AgentOps services can be scoped to the missing controls, setup or handover work while preserving a coherent delivery and operating process.
FAQ
Your questions, answered.
Does AgentOps replace DevOps for AI applications?
No. Agent services still need reliable builds, configuration control, testing, deployment, observability and recovery. AgentOps connects those capabilities to task behaviour, action authority, human intervention and confirmed outcomes. Use the existing delivery foundation and add the evidence and decision rights the agent service requires, rather than treating the disciplines as competing departments.
Can prompts and agent configuration use the existing CI/CD pipeline?
Yes, where the pipeline can version, validate and promote those artifacts with appropriate acceptance evidence. DORA guidance already includes AI artifacts in version-control scope. Add behavioural tests and accountable approval for material effects. A text-file change can alter tool choices or escalation behaviour even when no application binary changes.
Who should approve a source-data change that affects agent behaviour?
The source owner should establish the data meaning and effective revision, while engineering verifies ingestion and freshness. The service owner coordinates task-level acceptance, with security or other control owners involved where permissions are affected. Document the handoff explicitly. A source update outside the code repository should not bypass relevant operating review.
Does rolling back the agent deployment undo completed actions?
No. It changes the software or configuration used for later execution. Previously sent messages, confirmed reservations or external record changes may remain. Reconcile the external state and apply an authorised correction or cancellation process. Keep that business recovery decision separate from restoring a known software combination.
Do we need a separate AgentOps team if our DevOps team is mature?
Not necessarily. The important requirement is explicit ownership and sufficient capacity for evaluation, task exceptions, permissions and business outcomes. A shared team can work if those decisions are covered. Larger organisations may centralise platform capabilities while service teams retain outcome ownership. Choose the arrangement from workload and decision rights, not terminology.
What should be added to a conventional software handover for an agent?
Include the task acceptance contract, approved artifact combination, action boundaries, review queues, evidence model, operator runbook and external-state recovery procedure. Provide representative failure-test results and name who may pause the service. The recipient should be able to explain and resolve pending work without relying on the original developer’s undocumented knowledge.