AI Agent Growth Analysis: Third Place’s Net Gain Is Nearly Twice the Leader’s as Office Agent Growth Concentrates

1. Data First: Rankings Stayed the Same, but the Increment Shifted

Note: The data in this article are example data or simulated rankings, used only to demonstrate how to interpret ranking data. They do not represent real market conclusions. The first principle of ranking analysis is this: do not look only at ranking positions; also look at net increase, structure, and metric definitions.

1.1 Overseas General-Purpose Assistants: The Third Place Captured More Net Additions

Product	Monthly visits	Month-over-month growth	Estimated monthly net increase
General Assistant A	6.05 billion	+2.15%	~127 million
General Assistant B	2.64 billion	-0.15%	Decrease
General Assistant C	1.25 billion	+23.78%	~241 million

The top three positions were the same as in the previous month, but the distribution of growth changed significantly:

• The leading product grew 2.15% month over month, adding about 127 million visits in a single month.
• The third-place product grew 23.78% month over month, adding about 241 million visits in a single month.
• The third-place product’s net increase was nearly twice that of the leading product.
• The second-place product experienced a slight decline.

A key point here is that the third-place product did not grow at twice the leader’s growth rate. Rather, its net increase was nearly twice the leader’s. Growth rate and net increase are two different concepts and should not be confused.

1.2 Office AI Agents: The Category Grew, but the Increment Was Concentrated

Product	Monthly visits	Month-over-month growth	Monthly active users	Month-over-month growth
Office Agent A	27.46 million	+59.62%	12.69 million	+36.21%
Office Agent B	24.45 million	+37.17%	7.38 million	+43.24%
Other 5 agents combined	—	Net decrease of ~280,000 visits	—	—

The two leading products had combined monthly active users of about 20.07 million, up about 38.71% month over month. The overall office AI agent category grew 41.74% month over month.

On the surface, this looks like collective growth across the category. After breaking the data down by product, however, a different picture emerges: the two leading products contributed almost all of the net increase, while the remaining five agents slightly declined.

This shows that category-level growth does not mean every product is growing. The increment may be concentrated in only a few products.

1.3 High Growth Does Not Equal Large Scale

One product in a personal AI agent category grew 265.24% month over month, about ten times the 23.78% growth rate of the third-place general-purpose assistant. This comparison is about growth rate, not scale.

There are two main reasons:

• The scale base is relatively small.
• Personal scenarios have relatively simple demand, making it easier for product forms to stabilize quickly.

High-growth products deserve attention, but their significance must be validated with scale. A high-growth product may not be able to absorb large-scale increments. Conversely, a large-scale product with slowing growth may still contribute the largest number of new users.

1.4 A Warning Sign: The Second Place Slightly Declined

The high growth of the third-place product shows that later entrants still have opportunities. The slight decline of the second-place product reminds us that once the market structure becomes fixed, incumbent positions are not necessarily safe.

Head users have already been highly covered. If a product wants to continue growing, it must either take user time from other entry points or deepen usage within existing workflows.

1.5 Three Conclusions

Putting the same monthly data together leads to three conclusions:

1. Rankings reflect existing scale, while monthly net increase reflects user flow.
2. Category-wide growth does not mean every individual product is growing.
3. High-growth products deserve attention, but their significance must be verified by scale.

For office AI agents, the key question is not whether the category grew, but whether an individual product acquired enough new users and retained them.

2. Data Calibration: Four Metric Definitions to Clarify Before Drawing Conclusions

Before drawing conclusions, the underlying metrics need to be calibrated. Otherwise, statements such as “ten times the growth rate” or “net increase nearly doubled” are easy to misread.

2.1 Data Definition Statement

The data in this article are example data or simulated data, used to explain how to interpret rankings. If real monitoring reports are used later, the report name, publishing organization, statistical period, and metric definitions should be clearly specified.

Web and app data usually use different statistical systems:

Metric	Meaning	Main limitation
Web visits	Number of page visits	Repeated refreshes by the same user may be counted multiple times, and crawler traffic can distort the data
Web monthly active users	Unique users who visited the site during the month	Depends on browser-side identifiers; cross-device visits may be split
App downloads	Number of app store downloads	Reinstalls after device changes may be counted multiple times; downloads may not reflect actual usage
App monthly active users	Unique active users during the month	Accounts that have been deactivated may still be counted, creating a gap from real human users
In-app purchase revenue	Amount paid by users	Usually includes channel fees; the actual amount received may be lower

In this article, these metrics are not summed or combined into total values. Unless otherwise specified, category totals refer to products within the corresponding Top 100 rankings and do not represent the true size of the entire category market.

2.2 Do Not Multiply Month-over-Month Growth Directly by the Current Value

A common misreading is: “current value × growth rate = current increment.” That is not correct.

If the current-month value is V₁ and the month-over-month growth rate is r, then the previous-month value is V₁ / (1 + r), and the current-month net increase is V₁ - V₁ / (1 + r).

def estimate_increment(current: float, mom_growth: float) -> tuple[float, float]:
    """Estimate the previous-month value and current-month net increase from the current value and MoM growth.
    :param current: Current-month value, such as web visits.
    :param mom_growth: Month-over-month growth rate; 0.2378 means +23.78%.
    :return: (previous-month value, current-month net increase)
    """
    previous = current / (1 + mom_growth)
    return previous, current - previous
print(estimate_increment(12.53, 0.2378))  # (10.12, 2.41), unit: 100 million visits
print(estimate_increment(60.48, 0.0215))  # (59.21, 1.27), unit: 100 million visits

This shows that a product with nearly 24% growth added about 241 million visits, while a much larger leading product with only slightly more than 2% growth added about 127 million visits. Without restoring the base value, it is easy to confuse “fast” with “large.”

2.3 Weighted Growth Is Not the Simple Average of Individual Product Growth Rates

The monthly active user growth rates of two office AI agents were 36.21% and 43.24%. A simple average is 39.73%.

However, the two products have significantly different monthly active user bases. The correctly weighted growth rate is about 38.71%.

def weighted_growth(items: list[tuple[float, float]]) -> tuple[float, float]:
    """Calculate weighted growth from current values and MoM growth rates.
    :param items: [(current value, MoM growth rate), ...]
    :return: (weighted growth rate, current total)
    """
    current_sum = sum(v for v, _ in items)
    previous_sum = sum(v / (1 + g) for v, g in items)
    return (current_sum / previous_sum - 1), current_sum
print(weighted_growth([(1269, 0.3621), (738, 0.4324)]))  # (0.3871, 2007), unit: 10,000 users

2.4 Single-Product Totals and Category Totals May Not Reconcile

Using the two leading products to estimate the category total:

• The category’s previous-period value was about 51.91 million / 1.4174 ≈ 36.62 million visits.
• The two leading products’ previous-period value was about 27.46 million / 1.5962 + 24.45 million / 1.3717 ≈ 35.02 million visits.
• The gap is about 1.6 million visits.

This 1.6 million visits is about 5% of the combined total of the two leading products and roughly matches the theoretical previous-period size of the remaining five agents. If those five agents indeed declined by about 280,000 visits in total, the two sets of numbers are difficult to fully reconcile.

Common reasons include:

1. The ranking may include products that are not listed individually.
2. Different metrics may come from different statistical windows.
3. Growth rates may involve rounding.

Therefore, single-product data is suitable for trend judgment, but it is not suitable for precisely estimating the share of other products within the category.

3. Why Growth Went to Only a Few Products: Four Structural Reasons

3.1 Office Scenarios Are Essential, and High-Frequency Tasks Support Retention

General-purpose assistants cover a broad user base, but their demand is dispersed. Office AI agents target a narrower user group, but their demand is highly concentrated.

Tasks such as document writing, spreadsheet processing, meeting summaries, information retrieval, and email replies occur almost every workday. High-frequency demand plus closed-loop task completion provides the most stable foundation for retention.

3.2 Entry-Point Migration: From “Humans Finding Tools” to “Tools Completing Tasks”

The logic of traditional office software is “humans find functions.” Menus are deep and paths are long.

The logic of an AI agent is “state the goal, and the agent completes the task.”

Dimension	Traditional office software	Office AI agent
Interaction mode	Menus, buttons, keyboard shortcuts	Natural-language conversation
Feature discovery	Depends on user familiarity with the software	The system selects capabilities based on intent
Task execution	Users operate step by step	Planning, tool invocation, and validation are integrated
Data source	Users import data manually	Connects to enterprise knowledge bases and business systems

The entry point is shifting from a feature list to an intent-understanding layer. Whoever understands intent more accurately, connects to more tools, and executes more reliably is more likely to occupy the new entry point.

3.3 Data Flywheel and Capability Thresholds Reinforce Each Other

The lead of a top product is often not a single capability advantage, but a combination of multiple factors:

1. Scale accumulation: More real tasks generate more failure samples, driving model and policy optimization.
2. Connection network: The more systems a product connects to, the broader its task coverage and the higher the switching cost.
3. User trust: In office scenarios, users are more willing to delegate tasks to products that rarely make mistakes.

These three factors reinforce each other, creating a positive feedback loop and raising the barrier for challengers.

3.4 Cost Structure Determines Who Can Keep Investing

AI agent inference costs increase with context length and the number of tool calls. Products that can quickly accumulate users are better able to spread costs through scale, then reinvest budget into model optimization and new scenarios.

Unit economics determine whether an AI agent can sustain long-term investment.

4. Building an Office AI Agent: Six Key Engineering Questions

For development teams, the question raised by this shift is not whether to build an office AI agent, but which things to build correctly.

4.1 How Do You Decompose Office Tasks into Executable Steps?

Office tasks are often vaguely defined, involve multiple steps, and depend heavily on context. The system needs to decompose natural-language instructions into executable steps, then invoke tools step by step.

# Example: decompose an office instruction into dependent subtasks.
TASK_PLAN = {
    "intent": "Generate weekly report",
    "steps": [
        {"id": 1, "tool": "query_tasks", "args": {"owner": "me", "range": "week"}, "depends_on": []},
        {"id": 2, "tool": "query_meetings", "args": {"range": "week"}, "depends_on": []},
        {"id": 3, "tool": "summarize", "args": {"inputs": ["$1", "$2"]}, "depends_on": [1, 2]},
        {"id": 4, "tool": "render_report", "args": {"template": "weekly"}, "depends_on": [3]},
    ],
}
def collect_arg_refs(value):
    """Recursively collect $id references in arguments to avoid false positives from simple string slicing."""
    refs = set()
    if isinstance(value, str):
        if value.startswith("$") and value[1:].isdigit():
            refs.add(int(value[1:]))
    elif isinstance(value, dict):
        for v in value.values():
            refs.update(collect_arg_refs(v))
    elif isinstance(value, list):
        for v in value:
            refs.update(collect_arg_refs(v))
    return refs
def can_run(step: dict, done: set[int]) -> bool:
    """Allow execution only when explicit dependencies and argument references are satisfied."""
    depends_ok = all(dep in done for dep in step.get("depends_on", []))
    refs_ok = all(ref in done for ref in collect_arg_refs(step.get("args", {})))
    return depends_ok and refs_ok

Engineering considerations:

• Task classification: Distinguish retrieval tasks, generation tasks, calculation tasks, and action tasks, and select execution strategies accordingly.
• Dependency management: Record each subtask’s prerequisites and outputs. If an upstream step fails, downstream steps should not execute.
• Recoverability: Save intermediate results so that a task can resume from the failure point after interruption.
• High-risk operations require human confirmation: Actions such as sending emails, modifying documents, or deleting data should not be executed automatically.

4.2 How Should Tool Calls Be Structured?

When a model invokes external tools, the tools should describe their names, purposes, parameter formats, and permission requirements in a structured way. The model should generate parameters according to the agreed schema.

Recommendations:

• Parameter constraints: Use JSON Schema to define parameter types, required fields, and value ranges.
• Read-only first: Query tools can be allowed by default, while write, delete, and send tools should require secondary confirmation.
• Timeout and retry: Set timeout controls and idempotency mechanisms to avoid duplicate writes.
• Permission inheritance: An AI agent’s operation permissions should not exceed the initiating user’s permissions. All data access must go through a unified authorization layer.

{
  "name": "query_employee_directory",
  "description": "Look up basic employee information by name or employee ID and return only fields the current user is authorized to view",
  "parameters": {
    "type": "object",
    "properties": {
      "keyword": {"type": "string", "maxLength": 64},
      "limit": {"type": "integer", "minimum": 1, "maximum": 20}
    },
    "required": ["keyword"],
    "additionalProperties": false
  },
  "access": "read_only"
}

4.3 How Can Enterprise Knowledge Retrieval Improve Accuracy?

In office scenarios, answers are often located in enterprise documents, spreadsheets, and system data, rather than only in model parameters. Retrieval-augmented generation, or RAG, is the standard approach for introducing enterprise knowledge.

1. Document parsing: Support formats such as Word, PDF, Excel, and PPT, while preserving heading hierarchy, tables, and page numbers.
2. Chunking strategy: Split content along semantic boundaries to avoid truncating tables or list items.
3. Hybrid retrieval: Vector retrieval handles semantic similarity, while keyword retrieval handles exact matches for proper nouns, IDs, and other specific terms.
4. Permission filtering: Carry the user’s identity during retrieval and filter candidate results according to document permissions.
5. Citation tracing: Key conclusions should be traceable to their source locations so users can verify them.

4.4 How Do You Preserve Task Continuity in Long Conversations?

During a workday, users may handle multiple tasks within the same conversation, and historical context can expand rapidly. Common practices include:

• Short-term memory: Preserve the full conversation and tool-call results within the current task window.
• Long-term memory: Extract structured items such as user roles, frequently used templates, and preferences, then inject them as needed.
• Context compression: When approaching the context-window limit, summarize earlier content while preserving key tool results.
• State persistence: Store task state in external storage so that interrupted conversations can be resumed.

4.5 How Do Human-Machine Collaboration Points Reduce Risk?

Office tasks often involve irreversible actions such as external sending or data modification. Human intervention points must be clearly defined.

Intervention mode	Applicable scenarios	Design considerations
Pre-execution confirmation	Sending emails, modifying shared documents	Show the exact action and parameters that will be executed
Result review	Data aggregation, report generation	Mark data sources and flag low-confidence conclusions
User takeover at any time	Task deviates from expectations	Preserve options for users to manually modify and continue execution

4.6 How Can Cost and Latency Be Optimized?

Different tasks place very different demands on model capability. Not every step requires the most powerful model.

• Model tiering: Use lightweight models for simple steps such as intent recognition and information extraction; use stronger models for complex reasoning and long-form writing.
• Result caching: Cache retrieval results and generation results for repetitive queries.
• Streaming output: Return content while generating it to reduce perceived waiting time.
• Cost accounting: Track model invocation counts, input/output tokens, and tool invocation counts per task.

Task stage	Capability requirement	Suggested model tier	Main cost source
Intent recognition, parameter extraction	Low	Lightweight model	High-frequency calls
Knowledge retrieval and reranking	Medium	Retrieval model + reranking model	Vector computation
Long-document understanding and summarization	Medium-high	Long-context model	Input tokens
Complex reasoning and writing	High	High-performance model	Output tokens

5. Engineering Practice: Make the Agent Useful, Reliable, and Measurable

5.1 Reference Architecture

[Access layer]    Chat UI / office software plugins / API gateway
                  | Authentication, authorization checks, rate limiting
[Orchestration]   Intent recognition -> task planning -> step scheduling -> result aggregation
                  |            \-> pre-execution confirmation / user takeover
[Tool layer]      Retrieval tools | document read/write | calendar and email | spreadsheet calculation | third-party system connectors
[Knowledge layer] Document parsing -> chunking -> vectorization -> hybrid retrieval -> reranking -> citation tracing
[Data layer]      Task state storage | session and memory storage | logs and metrics
[Model layer]     Lightweight model <- routing strategy -> high-performance model

Responsibilities of each layer:

• The access layer handles identity authentication and permission checks in a unified way.
• The orchestration layer handles task planning, step scheduling, and human intervention control.
• The tool layer packages capabilities as structured tools and enforces unified parameter validation, timeout, and idempotency policies.
• The knowledge layer is independent from the model. After document updates, only the index needs to be refreshed.
• The data layer stores task states and interaction logs for recovery, evaluation, and cost analysis.
• The model layer uses routing strategies to assign tasks of different complexity levels to models with appropriate capabilities.

In engineering implementation, teams can combine cloud services as needed. For example, they can reference general capabilities such as those offered by Baidu AI Cloud: object storage for documents and indexes, vector retrieval for recall, container platforms and message queues for runtime and traffic smoothing, API gateways for authentication and rate limiting, and monitoring/data warehouses for evaluation loops. The key is not to lock into a single vendor, but to form replaceable, observable modules.

5.2 Reliability Design: Failures Are Inevitable, but They Can Be Controlled

Failure type	Typical symptoms	Mitigation strategy
Tool invocation failure	Timeout, invalid parameters, interface errors	Timeout control, idempotent retries, front-loaded parameter validation
Permission violation	Retrieval or operations on unauthorized data	Unified authorization layer, field-level filtering, operation auditing
Hallucination or outdated information	Invented data or citations	Enforced citation tracing, confidence thresholds, freshness detection
Context overflow	Answer quality degrades after long conversations	Summarization compression, external memory, session isolation by task
Prompt injection	Document content contains instruction-like text that induces unauthorized actions	Strict separation between system instructions and external content; human confirmation for sensitive operations

Prompt injection deserves separate attention. External documents, emails, and web pages read by an AI agent may contain content that looks like instructions.

From an engineering perspective:

• System instructions and external content must be strictly isolated.
• External content should be treated only as data, not as instructions to execute.
• Any sensitive operation must return to a human confirmation step.

5.3 Evaluation and Observability: Replace “Feels Good” with Task-Level Metrics

Conversational products are often evaluated based on subjective impressions. A more reliable approach is to use task-level metrics: each record represents one complete task, and metrics are aggregated across records.

The following code applies to Python 3.10 and later and has no third-party dependencies.

from dataclasses import dataclass, field
from typing import Literal
Risk = Literal["none", "write", "irreversible"]
@dataclass
class ToolCall:
    name: str
    ok: bool
    duration_ms: int
    risk: Risk = "none"          # Risk level: read-only / write / irreversible
    input_tokens: int = 0
    output_tokens: int = 0
@dataclass
class TaskRecord:
    session_id: str
    task_type: str               # search / write / calc / compose
    success: bool                # Whether the task was truly completed, manually or automatically judged
    first_pass: bool             # Whether the first submission passed manual validation without modification or retry
    turns: int = 0               # Number of interaction turns
    tool_calls: list[ToolCall] = field(default_factory=list)
# Example: build a set of offline evaluation records.
records = [
    TaskRecord("s001", "compose", success=True, first_pass=True, turns=3,
               tool_calls=[ToolCall("query_tasks", True, 320, input_tokens=1200, output_tokens=80),
                           ToolCall("render_report", True, 540, "write", 800, 900)]),
    TaskRecord("s002", "write", success=False, first_pass=False, turns=5,
               tool_calls=[ToolCall("send_email", False, 1500, "irreversible", 300, 60),
                           ToolCall("send_email", False, 1600, "irreversible", 300, 60)]),
    TaskRecord("s003", "search", success=True, first_pass=False, turns=4,
               tool_calls=[ToolCall("hybrid_search", True, 210, input_tokens=2000, output_tokens=120)]),
]
def summarize_tasks(rows: list[TaskRecord]) -> dict[str, float]:
    """Summarize task-level metrics: completion rate, first-pass rate, tool failure rate, average turns, and P95 latency."""
    if not rows:
        raise ValueError("No records provided")
    n = len(rows)
    completed = sum(r.success for r in rows)
    first_pass = sum(r.first_pass for r in rows)
    calls = [c for r in rows for c in r.tool_calls]
    errors = sum(not c.ok for c in calls)
    latencies = sorted(c.duration_ms for c in calls)
    p95_index = max(0, int(0.95 * len(latencies) - 1) if len(latencies) > 1 else 0)
    return {
        "completion_rate": round(completed / n, 4),
        "first_pass_rate": round(first_pass / n, 4),
        "tool_error_rate": round(errors / len(calls), 4) if calls else 0.0,
        "avg_turns": round(sum(r.turns for r in rows) / n, 2),
        "p95_latency_ms": latencies[p95_index] if latencies else 0,
    }
if __name__ == "__main__":
    for k, v in summarize_tasks(records).items():
        print(f"{k}: {v}")

In addition to basic metrics, four categories of metrics are worth attention:

• Segmentation by task type: Writing, retrieval, and calculation tasks have different difficulty levels. Looking only at overall averages can hide local problems.
• Human takeover rate: The proportion of tasks that users had to take over. This reflects whether the agent can handle tasks independently.
• Cost per task: Aggregate model invocation and tool invocation costs at the task level.
• Failure sample feedback: Automatically add failed tasks to the evaluation set and run regression tests before each iteration.

5.4 Cost Estimation: Build a Unit-Economic Model per Task

AI agent costs can be broken down into model inference costs, retrieval and storage costs, and tool invocation costs. A simplified model can be built first:

def estimate_task_cost(rows: list[TaskRecord],
                       price_in_per_1k: float = 0.003,
                       price_out_per_1k: float = 0.015) -> dict[str, float]:
    """Estimate model inference cost per task from token usage.
    Note: The prices are illustrative only; actual billing should follow the latest rules of the selected model service.
    """
    n = len(rows)
    tokens_in = sum(c.input_tokens for r in rows for c in r.tool_calls)
    tokens_out = sum(c.output_tokens for r in rows for c in r.tool_calls)
    cost = tokens_in / 1000 * price_in_per_1k + tokens_out / 1000 * price_out_per_1k
    return {
        "avg_tokens_per_task": (tokens_in + tokens_out) / n,
        "avg_cost_per_task": cost / n,
    }
if __name__ == "__main__":
    for k, v in estimate_task_cost(records).items():
        print(f"{k}: {v:.4f}")

Combined with a unit-economic model, this can answer a key question: for each additional active user, how much cost is required, and how much retention value can be generated?

6. Selection Checklist: How to Choose an Office AI Agent?

Check item	Key question	Pass criteria
Task orchestration	Can it decompose multi-step tasks and handle dependencies?	Supports task planning, dependency validation, and failure recovery
Tool permissions	Are tool invocations controllable?	Has parameter validation, read/write classification, and permission inheritance
RAG traceability	Can answers be traced to source documents?	Supports hybrid retrieval, citation display, and permission filtering
Memory strategy	Can it maintain continuity in long conversations?	Has short-term memory, long-term memory, and context compression
Cost monitoring	Can per-task cost be observed?	Can track tokens, tool invocations, latency, and failure rates

When evaluating options, do not rely only on demo effects. Look at completion rate, first-pass rate, human takeover rate, and cost per task in real office tasks.

7. Conclusion: After the Entry Point Is Reshuffled, What Determines Retention?

Three patterns can be extracted from the example rankings:

1. Look at increments, not just rankings. Rankings reflect existing scale; net increase reflects user flow. The third-place product’s net increase was nearly twice the leader’s, indicating that attention is shifting.
2. Look at structure, not just totals. Category-wide growth does not mean all products are growing. The increment may be concentrated in a few products.
3. Look at retention, not just growth rate. High-growth products are still small in scale. Whether they can convert new users into long-term retention is the decisive factor.

Four metrics are worth tracking continuously:

• Monthly active user growth: (Current-month MAU - Previous-month MAU) / Previous-month MAU, collected monthly with deduplication.
• Task completion rate: Number of truly completed tasks / Total number of tasks, judged by humans or rules.
• Human takeover rate: Number of tasks requiring user takeover / Total number of tasks.
• Cost per task: Total model, retrieval, storage, and tool-invocation costs / Number of tasks.

For office AI agents, the reshuffling of entry points has just begun. What ultimately determines the winner is not a single ranking position, but whether tasks can be executed reliably, whether knowledge can be retrieved accurately, whether permissions can be strictly isolated, and whether costs can be continuously optimized.