How to Scale Operations When AI Agents Multiply

Scaling Agent Operations

When a company moves from a handful of AI agents to dozens or hundreds, the product‑research team quickly runs out of capacity. New scenarios, knowledge updates, bad cases, evaluation, permission changes, skill versioning, and user‑question handling all increase, but the team cannot expand at the same rate.

Attempting to shift part of the work to the business side fails because business staff cannot independently analyse traces, adjust prompts, maintain evaluation sets, or perform gray‑release. Building autonomous mechanisms also requires goals, rules, evaluation and governance, which still need human operators.

Key question: How to ensure a large fleet of digital employees remains usable over time?

The problem is not who does more work, but that each agent still requires separate maintenance of knowledge, rules, evaluation, and versions, so maintenance effort grows linearly with the number of agents.

To reduce duplicate work, the article looks at Salesforce and Palantir practices, both of which converge on a "unified business semantics + outcome‑driven management" model, though their implementation paths differ.

Salesforce Approach

Salesforce first creates a unified data layer (Data Cloud) and semantic layer that provides consistent customer data and business concepts to all agents. An "Agentic Work Unit" records how much work each agent completes and links the result to opportunities, service tickets, quotes, and revenue. Operators can see not only call success but also task completion, bottlenecks, and business impact, then decide whether to update shared data, business processes, or a specific agent's instructions.

Palantir Approach

Palantir stores customers, orders, contracts, and related objects, rules, metrics, permissions, and actions in an Ontology. Agents call these shared capabilities at runtime and write results back to business objects. If a problem originates from contract status, customer definition, or permission, the Ontology entry is corrected once, instantly benefiting all agents that reference it. Only when the agent's own behavior is faulty does the fix go back to the agent layer, creating an AgentOps feedback loop.

Both approaches demonstrate that scaling agents requires a shared business‑semantic foundation and a unified outcome‑evaluation system. The semantic layer reduces duplicate maintenance, while business metrics clarify goals and responsibilities, allowing product owners, capability owners, and the AI platform to jointly sustain the digital workforce.

Agent Ops Begins After Launch

Before launch, an agent's scope is clear: model selection, skill authoring, knowledge‑base integration, system connectivity, testing, and release. Once in production, problems become more complex:

Business rules change but knowledge is not updated;

New user questions fall outside existing intents;

Tool calls succeed but the task is not truly completed;

Agent answers look reasonable but business users reject them;

New versions fix one issue while introducing another;

Call volume grows while business impact remains unmeasured.

Traditional monitoring only shows interface health; agents often fail silently, doing the wrong thing without errors.

Asset Management: who owns it, who is responsible, what knowledge and tools it has</code>
<code>Runtime Observation: what tasks were completed and where they failed</code>
<code>Continuous Evaluation: whether a version regresses and if changes are effective</code>
<code>Continuous Improvement: how Bad Cases enter a diagnosis‑repair‑validation loop</code>
<code>Security Governance: permissions, approvals, audits, circuit‑breakers, and human takeover

DevOps guarantees software continuity, MLOps guarantees model continuity, and AgentOps guarantees digital‑employee continuity.

Industry often cites a "5% model capability + 95% engineering, operations, and governance" split. This is an anecdotal ratio, not a strict statistic, but it highlights that models set the capability ceiling while engineering, operations, and governance determine whether that capability can be reliably delivered.

Consequently, the management target shifts from "Software Assets" to a "Digital Workforce" that includes agent versions, knowledge, tools, tasks, performance, permissions, cost, and lifecycle.

Three Seemingly Reasonable Approaches That Stall

1. Hand Everything to R&D

R&D excels at building systems—developing agents, integrating tools, maintaining runtimes, and handling performance. However, post‑launch issues are often non‑technical. For example, a customer‑service agent may generate 300 Bad Cases daily, stemming from missing knowledge, rule changes, prompt misunderstandings, tool failures, or model hallucinations. Engineers can fix the API but cannot decide which product policy expired, which customer demand is rising, or what answer meets business standards. If R&D bears this load long‑term, new scenario delivery slows and operational priorities become unclear.

2. Hand Everything to Business

Business teams understand the value agents should create. Customer‑service supervisors know complaint drivers; sales leads know which suggestions close deals; finance knows which statements must not be mixed. They should define goals, provide knowledge, maintain rules, and accept results. Yet they lack full agent‑engineering skills. Expecting them to view traces, edit prompts, maintain evaluation sets, manage versions, and control costs creates new learning overhead and quality risk. Business can own the agent’s business side but cannot shoulder all operational work alone.

3. Rely on Fully Autonomous Agents

Automation that detects Bad Cases, drafts knowledge, and suggests prompt improvements reduces repetitive labor, but it does not eliminate operations—it merely changes its form. Questions arise: Who defines success? Who validates a business rule? Who approves high‑risk actions? Who reconciles evaluation metrics with real business outcomes? Stronger autonomy raises the demands on goals, evaluation, permissions, and audit.

Autonomous agents cut execution cost but cannot replace operational responsibility.

The Bottleneck: Per‑Agent Operations

With five agents, maintaining each agent’s prompt, knowledge, and rules is manageable. With hundreds, the same customer may be called "Customer" in a sales agent, "User" in a service agent, and "Account" in an analytics agent; a refund rule may be duplicated across many prompts; product knowledge is copied into multiple knowledge bases.

Hundreds of Prompt sets</code>
<code>Hundreds of Knowledge bases</code>
<code>Hundreds of Business rule sets</code>
<code>Hundreds of Permission configurations</code>
<code>Hundreds of Evaluation criteria

Any rule change can trigger a cross‑agent manual audit and modification, inflating operational cost. The deeper issue is that the wrong object is being operated on. The visible "sales agent" or "service agent" is merely a shell; the real asset to maintain is the shared business capability they rely on.

Customer</code>
<code>Order</code>
<code>Contract</code>
<code>Invoice</code>
<code>Product</code>
<code>and the relationships, rules, metrics, permissions, knowledge, actions, and workflows built around them

This is the Ontology: a unified repository of business objects, rules, and relationships that multiple agents can share. Fixing a single ontology entry—e.g., correcting a "customer health score" calculation—automatically updates every agent that references it, avoiding fragmented fixes.

When the operational object shifts from individual agents to shared capabilities, a single repair can improve a whole family of agents, and new agents can immediately reuse existing capabilities, reducing duplicate construction.

Agents are merely execution vessels; shared capabilities are the long‑term operational asset.

AgentOps as a Collaboration Mechanism

Post‑launch problems rarely belong to a single team. A wrong answer may stem from a changed business definition, outdated shared knowledge, a faulty tool, a broken workflow, or a model issue. Business staff can judge the outcome but may not know the root cause; engineers can see the full trace but may not know the correct business standard.

Therefore, AgentOps cannot be owned solely by business or R&D. It first translates online feedback into diagnosable issues, then routes them to the appropriate owner: business rules go back to the business team, shared objects and capabilities to the capability owner, and runtime or governance issues to the AI platform. After correction, a unified evaluation and release process returns the fix to production.

AgentOps is thus a cross‑team operating mechanism that discovers problems, assigns them to the right asset layer, validates fixes, and checks whether business results improve.

The mechanism typically involves three role layers:

1. Business Owner

Responsible for business outcomes, defines agent goals, boundaries, and acceptance criteria. They answer:

What problem should the agent solve?

Which business rules must be obeyed?

Which tasks can be automated?

When must human intervention occur?

Which KPI (resolution rate, revenue, cost, satisfaction) matters?

Business teams also maintain knowledge and rules but do not perform all technical actions.

2. Capability Center (Ontology / Digital Workforce Center)

Maintains the shared business objects, metrics, rules, permissions, lifecycle, knowledge, skills, tools, workflows, evaluation sets, versions, and reuse mechanisms. It requires people who understand both business semantics and agent engineering (e.g., agent product managers, ontology architects, knowledge‑ops engineers).

Enterprise objects and their relationships;

Unified metrics and business definitions;

Rules, permissions, and lifecycle management;

Knowledge, skills, tools, and workflows;

Evaluation sets, versioning, and capability‑reuse mechanisms.

3. AI Platform

Provides a stable, secure, low‑cost runtime: model integration, trace collection, evaluation tools, release system, permissioning, auditing, cost tracking, and governance. It does not define business rules but must allow business owners and the capability center to observe, edit, validate, and publish with low friction.

Business Owner → defines value, rules, and business results</code>
<code>↓</code>
<code>Capability Center → maintains Ontology and shared capability assets</code>
<code>↓</code>
<code>AI Platform → provides Runtime, Evaluation, and Governance

Whether a dedicated AgentOps department is created can be decided later, once responsibilities and workload stabilize.

Each Digital Employee Needs a "Dual Owner"

Every agent should have two owners:

Business Owner → accountable for business goals, rules, and outcomes</code>
<code>Capability Owner → accountable for the agent's capability, evaluation, versioning, and continuous improvement

For example, a sales agent's business owner is the sales leader, while its capability owner comes from the capability center. The AI platform team does not own business outcomes but owns the runtime, tools, and governance.

Dual ownership solves two common problems: (1) after launch, no one is responsible, turning every issue into a temporary ticket; (2) business and technical teams each optimise their own metrics, leaving the overall result ownerless.

Business owners must not only raise requirements; capability owners must not focus solely on model scores. Together they map business KPIs to agent KPIs (e.g., first‑contact resolution, hand‑off rate, satisfaction for service; qualified opportunities, follow‑up efficiency, conversion for sales; adoption rate, analysis latency, decision impact for analytics). Call volume, token usage, and tool success rates remain useful signals but cannot replace business outcomes.

How an AgentOps Platform Operates

With the division of labor defined, the platform stitches problem discovery, handling, and verification into a chain:

Collect Trace, task results, and business feedback</code>
<code>↓</code>
<code>Use rules and analysis skills to detect anomalies and cluster Bad Cases</code>
<code>↓</code>
<code>Provide preliminary attribution and assign to the appropriate Owner</code>
<code>↓</code>
<code>Generate knowledge, rule, or test‑case drafts; humans confirm critical changes</code>
<code>↓</code>
<code>Run regression evaluation, gray‑release, and effect comparison

Permissions, cost, risk, and audit span the entire flow. Low‑risk operations can be gradually automated; high‑risk changes involving business definitions, critical rules, or production permissions still require human confirmation.

This reduces the need for operators to manually scan every conversation; instead they prioritize aggregated high‑frequency issues. Knowledge drafts, test cases, and regression evaluations can be auto‑generated, with humans only judging the reasonableness of suggestions.

If the root cause lies in shared knowledge, rules, or ontology, a single fix propagates to all dependent agents, avoiding repetitive per‑agent patches.

Start with a Minimal Closed Loop

Instead of building a full AgentOps platform immediately, begin with a lightweight pilot on a high‑value, stable‑traffic agent. In 1–2 weeks, verify a minimal loop:

Collect agent conversations → Identify Bad Cases → Assign fixes → Compare pre‑ and post‑release effects

For a customer‑service quality‑check agent, store conversation summaries, issue types, owners, status, agent version, and verification results in a multi‑dimensional spreadsheet (e.g., Feishu). A scheduled task pulls new conversations, applies rules and a large model to flag potential Bad Cases, and aggregates the top‑10 frequent issues.

Operators spend 15–30 minutes daily confirming, ignoring, or assigning issues; weekly they review the top‑10 with owners to decide whether to add knowledge, adjust rules, tweak prompts, or fix tools/workflows. After a fix, record version and timestamp, then compare the number and proportion of similar issues over the following seven days. If the metric improves, the loop can be closed; otherwise, return to diagnosis.

Success of the MVP is judged by three criteria: (1) the team can continuously surface major problems, (2) it can regularly complete high‑impact fixes, and (3) it can roughly gauge the effect of each fix with data.

After the loop stabilises, gradually add knowledge‑draft generation, regression testing, and gray‑release capabilities. If the same issue appears across multiple agents, consider extracting the related object, rule, permission, or knowledge to the shared layer, further reducing duplicate work.

Regardless of automation depth, business‑standard validation and high‑risk decision approval must remain human‑driven—AI boosts efficiency but does not replace responsibility.

Final Thoughts

When agents are few, run a closed loop for a single agent. As numbers grow, address recurring shared capabilities. When collaboration becomes the bottleneck, adjust division of labor and platform capabilities.

The path may not suit every enterprise; agent count, business complexity, and risk level dictate the appropriate organization.

Continuously treating each agent as an isolated system inevitably turns agent growth into headcount growth. Handing all work to product‑research, business, or fully autonomous agents does not fundamentally change this.

A more effective approach lets business own value and rules, lets capability owners maintain shared semantics and assets, and lets the AI platform provide runtime, evaluation, and governance tools.

In this sense, AgentOps is not necessarily a new department; it is a collaborative mechanism where problems are owned, fixes are verified, and solutions are reusable across agents.

Agents can keep increasing, but the real long‑term operational focus should be the evolving shared business capabilities behind them.