Personalized AI infrastructure
What Is AgentOps? How to Run an AI Agent Day to Day
AgentOps is the daily and weekly work of keeping a live AI agent accurate, safe and useful. Here is what that work involves and who should own it.

AgentOps is the daily and weekly operating work that keeps a live AI agent accurate, safe, affordable and useful after it launches. It covers watching what the agent does, testing its quality on a schedule, maintaining its connections and permissions, and changing it under control. Think of it as operations for a new kind of team member: someone has to supervise the work even when the work is going well.
Key takeaways
- AgentOps is the recurring routine for a live agent: observe, evaluate, maintain, govern and improve.
- Agents drift without anyone breaking anything, because documents, tools, models and staff requests keep changing around them.
- Daily work is short and focused on exceptions. Weekly work tests quality against a fixed set of realistic tasks.
- Monthly and quarterly work covers permissions, cost per completed task, restore tests and whether the role still matches the business.
- Every task needs a named owner, and the business keeps the decisions about scope, risk and approvals.
What does AgentOps actually cover?
An AI agent is not a program you install and forget. It is a model combined with instructions, memory, knowledge sources, tools that act on other systems, permissions and channels such as email or chat. Each of those parts can change without anyone on your team touching the agent.
A model provider updates a model. A policy document is replaced. A connected system changes how it signs people in. A new employee asks something nobody planned for. AgentOps is the routine that notices these shifts before a customer or a colleague does.
The work falls into five activities:
- Observe: keep records of what the agent did, which tools it called, what it cost and where it failed. The ideas of logs, metrics and traces from the [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) apply directly.
- Evaluate: run a fixed set of realistic tasks on a schedule and compare the results with what good looks like.
- Maintain: keep integrations, credentials, knowledge sources and memory current and working.
- Govern: review what the agent can access, keep approval boundaries in place and keep an audit record.
- Improve: make changes in small, reversible steps, each with a reason and a way back.
This is different from building. Building decides what the agent is. Operating keeps it that way, and improves it on purpose.
What happens every day?
Daily work is deliberately small. It is about exceptions, not about reading every conversation. When things are healthy, a trained operator should be able to finish it quickly, and when things are not healthy the routine should make that obvious.
- Read the overnight summary: how many tasks were handled, how many were passed to a person and how many ended without a clear result.
- Read the exceptions: failed tool calls, refused actions, timeouts and anything the agent itself marked as uncertain.
- Check connections: confirm that email, calendar, CRM or file access still works and that no credential is close to expiring.
- Check usage against limits: a sudden jump in activity can point to a loop, a misconfiguration or misuse.
- Triage staff reports: when someone says the agent got something wrong, log it, reproduce it and decide whether it is a one-off or a pattern.
The last item matters most. Reports from the people who use the agent are the cheapest quality signal you will ever get, and they dry up quickly if nobody answers them. Also look at the approval queue. If the agent must ask before it acts and the queue sits untouched, a helpful agent quietly becomes a bottleneck.
What belongs in the weekly review?
The weekly review steps back from single incidents and looks for patterns. Its central tool is a test set: a small collection of realistic tasks, taken from real work, each with a known good outcome. Running it every week, and after every change, tells you whether quality moved. Anthropic's guide to [evaluations for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) explains why this habit matters more as agents take on longer tasks.
A practical weekly checklist:
- Run the fixed test set and compare it with the previous run.
- Read a handful of completed tasks end to end, including some that looked fine.
- Review corrections: each time a person edited, rejected or redid the agent's output, note why.
- Check knowledge sources for stale, duplicated or contradictory documents.
- Look at unusual inputs, such as emails or files that contain instructions aimed at the agent. Outside content that tries to steer an agent is a known risk, described in the [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/).
- Review open change requests and decide what ships, what waits and what is declined.
Keep the test set small enough that someone actually runs it. Each time a real failure appears, add a case that would have caught it. Over time the test set becomes the memory of everything that has gone wrong, which is how an agent becomes steadily more reliable instead of randomly different.

What changes monthly and quarterly?
Some risks move slowly enough that a weekly look would be wasted effort, but they still need a fixed date on the calendar. Monthly work is mostly about access and cost. Quarterly work is about whether the whole arrangement still fits.
- Monthly permission review: list every system the agent can read or change, remove what is no longer needed and confirm that each approval boundary still reflects your intent. The steps are laid out in how to run a permission review for your AI agents.
- Monthly cost review: look at cost per completed task, not only total spend. Rising spend with a steady cost per task usually means more useful work. The reverse is a warning.
- Monthly restore test: confirm that configuration, memory and knowledge sources can be brought back from a saved copy, not only that a copy exists.
- Model and tool updates: treat each as a change. Test it against the fixed set before release and keep a rollback ready, as described in how to update an AI agent in production without breaking it.
- Quarterly role review: compare the written role with what people really ask the agent to do, then widen it, narrow it or split it.
- Quarterly incident drill: practice the pause procedure. Who can stop the agent, how fast, and who is told afterwards.
If you want a broader frame for this loop, the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) describes the same cycle of governing, mapping, measuring and managing in general terms.
Illustrative scenario: drift caught in a weekly review
This is an illustrative scenario, not a description of a real client. A distribution company uses an agent to answer customer questions about delivery and returns. During the month the company revises its returns policy and uploads the new document, but the old version stays in the knowledge folder. Nobody complains, because both versions produce answers that sound reasonable.
In the weekly review, the fixed test set includes a returns question with a known correct answer. This week the answer differs from last week's. The operator traces it to the old document and takes these steps:
- Retire the old document from the knowledge folder.
- Run the test set again to confirm the answer is correct.
- Add a second test case that fails if two policy versions ever coexist.
- Tell the support lead what happened and why.
- Record the change in the change log.
The effort was small. Without a routine, the first signal would have been a customer quoting the agent's wrong answer back to the company.
Who owns which part of AgentOps?
Operating well depends on clarity about who decides what. Use this as a decision guide and write your own version down.
- What the agent is allowed to do: the business owner decides.
- Whether a new tool connection or wider permission is approved: the business owner approves, after the operator explains the risk in plain terms.
- Whether the agent is working today: the operator answers, from monitoring.
- Whether answers are still correct: the operator runs the evaluations, and a named business contact confirms what correct means.
- Whether a document is the current policy: the internal owner of that document decides.
- When to pause the agent: anyone on the agreed list can pause it, the operator investigates and the business owner decides when it resumes.
Written ownership prevents two common failures: everyone assumes someone else is watching, or the person watching has no authority to act. The shared responsibility model for AI agents shows how to divide these duties between a provider and your company.
How does Be Human handle AgentOps?
Be Human designs, implements and operates AI agents for companies. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. After launch, managed operations run the routines described here: monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. The service is remote and available in English and Portuguese, and the company keeps control over scope and approvals. The recurring work is listed in more detail in what managed AI services include.
Frequently asked questions
Is AgentOps the same as DevOps or MLOps? It overlaps but is not identical. DevOps keeps software deployed and running, and MLOps manages the training and release of models. AgentOps adds the supervision of behavior: what an agent decided, which tools it used, whether its answers are still right and whether its permissions still make sense.
How much time does AgentOps take? It depends on how many tasks the agent handles and how many systems it touches. Daily checks should be short when things are healthy, while the weekly review and the monthly access and cost reviews need protected time. If nobody has that time, the work will be skipped, and that is the usual reason to hand it to a provider.
Can our own team do AgentOps? Yes, if someone has the time, the technical skill to read logs and trace failures, and the authority to pause the agent. Many companies keep the decisions, such as scope, approvals and what counts as a correct answer, and hand the technical routine to an operator.
How can I tell whether AgentOps is actually happening? Ask to see five things: a written routine with owners, the current test set with recent results, a change log, an incident and pause procedure, and a short periodic report on usage, cost and open issues. If any of these does not exist, the agent is being watched informally at best.
Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.


