Agentic operations: AgentOps, LLMOps, and AIOps
Agentic operations is the work of running agent workloads as services with named owners: introducing them, controlling their access, observing their activity, changing them, and retiring them. “AgentOps” is also used for this work, though teams and products use the term differently.
An agent framework can coordinate a reasoning loop. It does not, by itself, decide who handles a failed job on Monday or who can withdraw the job's access.
Explore Dome: Dome Platform · Docs: Platform admin tutorial.
Similar names describe different work
| Term | Typical focus |
|---|---|
| Agent orchestration | Coordinating steps, tools, state, and multiple agents |
| LLMOps | Developing and operating applications built around language models |
| AgentOps | Operating agent workloads and their actions as services |
| AIOps | Applying AI to IT operations, such as event analysis and diagnosis |
An AIOps tool might help diagnose an infrastructure alert; AgentOps includes deciding who responds when an agent's job fails. IBM's AIOps overview describes the use of AI to support IT operations.
These scopes overlap. An agent team may use LLMOps practices for evaluation and an AIOps product for infrastructure alerts. Clarify which team owns each responsibility, even when the tools cover more than one area.
Suppose a nightly agent reconciles purchase orders and prepares exceptions for a finance team. Orchestration determines the sequence of reads and comparisons. Operations determines its schedule, access owner, spending limits, failure notification, and recovery procedure. If both teams expect the other to handle recovery, a failed job may sit unattended.
Explore Dome: Agent Registry · Docs: Manage agents.
Prepare the service handoff
Before another team takes over an agent service, make sure it can answer:
- What work does this agent perform, and how do we recognize completion?
- Who owns the workload and who receives failures?
- Which tools, model routes, and credentials does it depend on?
- What changes require review before deployment?
- How do we pause, recover, and retire the service?
Link to the records and instructions an operator would need to do each of these jobs. A completion signal should identify the run and its output. A recovery procedure should say whether to retry, inspect the backend, or ask the business owner. Give operators a current team contact, not just the name of the person who built the prototype.
Dome's Agent Registry provides records and lifecycle controls for registered agents. It is one part of the handoff, alongside the scheduler, application repository, and backend runbook. The registry and inventory comparison explains how to reconcile those records.
Explore Dome: Agent Registry · Docs: Agent lifecycle.
Update the operating plan when the work changes
Adding a tool that can change records or send messages changes the operating plan, too. The team may need approval rules, duplicate-action protection, recovery steps, and different evidence of completion. Moving to another model provider may require new compatibility checks and cost assumptions.
Review new tools and provider changes before relying on the original launch approval. The NIST AI RMF treats risk management as work that continues throughout AI development and use.
Another operator should be able to use the service record without the original builder present. Lifecycle management explains how to manage changes and retirement. Incident response covers what to do when something goes wrong.
Explore Dome: Audit · Docs: Audit events.