Enterprise Agents: Why the Real Work Starts After Deployment

The enterprise agent market is heating up. Alibaba Cloud launched AgentCore targeting "from personal productivity to enterprise productivity"; Tencent integrated WorkBuddy Managed Agents (WMA) into WorkBuddy Enterprise emphasizing production-grade foundations; Salesforce and Anthropic released Claudeforce followed by Salesforce's AIforce; Meta established Enterprise Platform with Muse connecting Asana, QuickBooks, Stripe, Shopify; ByteDance merged Feishu and Doubao teams launching Doubao Work deeply integrated with Feishu. Despite different product forms, a common trend emerges: industry competition is shifting from "how to build agents" to "how to make agents shoulder real work."

The Real Difficulty Begins After Agents Go Live

Building a demonstrable agent is no longer hard. Integrate models, knowledge bases, and MCP, configure a few Skills, and assemble via agent configuration — prototypes run quickly. Enterprises can self-build on open-source components like LangGraph or use cloud vendors' managed Runtime, Sandbox, Harness, and Trace capabilities.

After the prototype runs, problems appear: can it handle a specific job? The agent must access required data, knowledge, permissions, and tools, understand true user intent and business context, distinguish automatable actions from those needing human confirmation, and embed into actual work touchpoints to receive both human-initiated tasks and process/event/scheduled triggers.

Even achieving that, production is just the start. SOPs update, business problems shift, new Bad Cases emerge continuously, so evaluation sets, knowledge, and handling rules need ongoing maintenance, and someone must diagnose and regress when quality drops. "Runnable" does not equal "working," let alone forming organizational productivity.

Case Study 1: Internal Efficiency Agent — Usage Without Value Proof

An internal efficiency agent saw growing call volume and positive user feedback. But at quarterly review, management asked how many man-hours saved and which process segments shortened — no usable data existed. Because no value baseline was established at design time, and no recording of which manual steps were truly replaced occurred during operation. Call volume only proves usage, not value magnitude.

Case Study 2: Health Diagnosis Agent — Accuracy Collapse From 95% to 60%

A health diagnosis agent scored near 95% on its initial evaluation set. Six months later, re-evaluation on new business samples yielded ~60%. This cannot be simply blamed on model capability; business kept changing: SOPs updated, problem distribution shifted, new samples weren't added to evaluation sets promptly, and Bad Cases lacked continuous iteration and regression mechanisms.

Both agents completed development and launch smoothly, yet one couldn't articulate value, the other couldn't sustain quality. The real problems all occur after "built."

An agent truly entering production means it stably completes a real job and enters a continuous feedback and improvement loop.

Industry Solution Analysis: Four Routes

Reviewing the mentioned products reveals they each fill a segment of capabilities needed for agents to enter production. Four routes have formed, often combined in a single enterprise solution.

1. Infrastructure Route: Stable Agent Operation

AgentCore, WMA focus on infrastructure for agent runtime: Runtime, Harness, Sandbox, Identity, Trace, Eval, MCP/API, plus managed elastic execution. Agent runtimes are rapidly standardizing; long-task execution, environment isolation, fault recovery increasingly purchasable off-the-shelf. This route solves stable, secure, scalable operation — not how specific business should judge and execute. Vendors provide generic run/governance/security, but business semantics, metric definitions, process rules, and action boundaries still require enterprises to define against their own systems.

2. Work Touchpoint Route: Agents Where Work Happens

Focus is not adding another standalone AI page but placing agents where tasks occur. Tasks can be employee-initiated in chat or auto-triggered by processes, events, or schedules. Key is whether the agent can catch the task in time. In practice, one agent typically offers three entry points: IM bot, AI workbench, and API — handling employee chat, centralized task processing, and system auto-calls respectively. Doubao Work and WorkBuddy bring agents into messages, docs, meetings, OA, inheriting org relationships, identity permissions, and current context; Muse connects multiple SaaS tools forming a cross-system work layer while retaining human confirmation for high-risk actions. Different forms, same goal: give agents context in real work and let them act within clear boundaries.

General agents only become organizational productivity when they enter work touchpoints and inherit organizational context.

3. Business System Route: Software as Agent's Work Environment

Salesforce/Anthropic's Claudeforce and AIforce embed agents into Salesforce's product suite. Not unique to Salesforce — DingTalk, WeCom, Yonyou, Kingdee do the same: embed agents into systems that own data and permissions. Logic: business software no longer just records results; it becomes the environment where agents directly work. Models provide reasoning; business systems provide trusted context and controlled actions. When data, rules, permissions, and Actions connect inside the system, agents can understand, judge, and execute business within explicit boundaries.

4. Enterprise Self-Built Route: Own Context, Own Outcome

Engineering-capable enterprises can self-build Runtime, MCP, knowledge, evaluation, and governance on open-source components like LangGraph. But a self-built foundation doesn't automatically yield productivity; enterprises must still handle data unification, business semantics, metric definitions, permission boundaries, process rules, Skills, and operational mechanisms. The enterprise's unique advantage: it holds real business context and bears final outcome responsibility.

Together, these practices outline a clear picture: capabilities for agents to stably complete work distribute across at least three layers — runtime foundation, business context & execution capability, work touchpoints & operational mechanisms. No single route covers all; competition core is not role classification but who can truly combine these layers.

How Agent Platforms Extend From Development Capability to Production Capability

Enterprise context cannot be equated simply to "MCP, knowledge base, and Skill." It describes information the agent needs to understand business in the current task:

Enterprise Context
├── Data: Customer / Contract / Order / Ticket …
├── Semantics: Objects / Relations / Metrics / Definitions …
├── Knowledge: SOP / Rules / Cases / Product Knowledge …
├── Identity & Permissions: Roles / What Can Be Seen / What Can Be Done
└── State: Current Task / Process State / Historical Actions …

Enterprise Capability
├── Tool / MCP
│   ├── Query
│   └── Action
└── Skill

Context solves what the agent should know right now; Skill solves how it should act; Tool/Action solves what it can do. Knowledge alone limits agents to Q&A tools alone make them mere API callers; without Skills they don't know how to judge, when to execute, or when to escalate to humans.

If Runtime forms the development platform base, then Business Context & Enterprise Capability and Production Operations are the two layers extending the platform toward productivity. They are not three independent systems but expanding capability boundaries of one agent platform:

Agent Runtime (bottom): development & run capability — create and stably run agents. This layer is standardizing; purchasable or self-built.

Context & Capability (middle): application capability — enable agents to do the job right. Enterprises lack not a knowledge base but a capability system letting agents understand, judge, and safely execute business. Example: instead of letting agents directly modify databases, wrap actions into business Actions with identity verification, scope limits, approval, and audit trails. This is the long-term capability asset.

Work / Production (top): organizational capability — enable agents to continuously create value. Includes work touchpoints, process integration, plus business owners, evaluation, Bad Case handling, feedback, and value measurement. These mechanisms may not all appear as software features but determine whether platform capability converts to organizational productivity.

The Real Moat: Accumulation Speed of Three Asset Types

First, Enterprise Semantic Assets . Agent data access ≠ business understanding. How "customer" maps across CRM, ticketing, finance; whether "revenue" means signed, invoiced, or collected — all need unified definitions. Only after objects, relations, metrics, definitions, rules, permissions, and states are clarified can agents make trusted judgments on consistent semantics.

Second, Agent Capability Assets . Each agent shouldn't re-integrate systems or rewrite processes. MCP, Tools, their encapsulated Actions, and business Skills must precipitate into reusable, composable, governable capabilities. Test: can the next agent directly reuse problems the previous agent already solved?

Third, Production Operational Mechanisms . Post-launch, business and quality keep changing, so someone must continuously own: version evaluation, Bad Case handling, knowledge/Skill updates, regression testing when quality drops, final value accounting. Building an agent resembles a project; continuously operating a fleet of agents tests whether the enterprise has established long-term mechanisms.

These three accumulations are interdependent: semantic assets help agents understand business; capability assets turn understanding into executable work; production operations drive the first two to update with business changes. They cannot be simply split and assigned to separate departments.

Typically: business owners define goals, work completion standards, value metrics; domain experts/business makers precipitate business semantics, knowledge, rules, process Skills, and continuously handle Bad Cases; engineering & data teams implement business definitions into data and systems, encapsulate execution capabilities into safe, reusable Tools and Actions; platform teams provide Runtime, permissions, release, evaluation, governance mechanisms. Who leads depends on agent risk and complexity: low-risk scenarios allow business makers to self-configure; high-risk or cross-system scenarios need joint business-engineering delivery.

Evaluation Metrics: Look at How Much Real Work Is Completed

If the goal is organizational productivity, core metrics shouldn't be agent count, user count, or call volume, but Work Completion : how much real work agents stably complete.

Work Completion is no universal formula. Each scenario must first define what counts as completing a job; then record original time, cost, and manual effort; after launch, track success rate, human takeover rate, rework rate.

Customer service: measure problems resolved, not sessions deflected.

Sales: measure information organization, customer follow-ups, opportunity updates completed, not call count.

Finance: measure analysis tasks completed, cycle time reduced, not query initiations.

First see how much work agents completed, then see how much business value those completions brought.

Summary

Building agents is no longer the main barrier. The real difficulty is stably handing real work to them: results verifiable, errors traceable, experience reusable, value measurable. Achieve these, and agents cease being merely demonstrable features and become part of organizational productivity.

Organizational productivity growth ultimately shows in one thing: more and more real work stably completed by agents — faster, more accurately, at lower cost.

Thus, moving from "development platform" to "productivity platform" changes not only the platform's capability boundary but its delivery target: from delivering a runnable agent to delivering verifiable work results; from a one-time project launch to continuous accumulation of capability and value.