---
title: "How Agents Actually Enter the Enterprise: Hong Yanqing on Beijing's Agent-Led Development Measures (Part 1 of 4)"
author: "DCC Editorial"
published: 2026-08-07T03:50:00.000Z
url: https://datacompliancechina.com/posts/beijing-agent-measures-adoption-gap/
description: "Part 1 of Hong Yanqing's three-part commentary on the Several Measures of Beijing Municipality on Accelerating Agent-Led Development (北京市关于加快智能体引领发展的若干措施, 京发改〔2026〕1185号, issued 21 July 2026). Hong maps agent supply along two axes — who builds and operates (enterprise self-build, standardized third-party products, joint co-construction with forward-deployed engineers, public/industry shared platforms) and how capability is delivered (whole solutions, componentized assembly via skill marketplaces, embedded in existing software and terminals) — and argues Beijing has covered supply almost completely. What the Measures have not yet answered is adoption: enterprise demand is not 'an agent' but a definable, delegable, verifiable task, and between agent supply and enterprise production processes stand six institutional thresholds — unformed procurement-ready demand, processes that lack the standardization agents require, blocked access to data and tools, missing authorization and responsibility regimes, procurement and acceptance mechanisms built for conventional software, and the absence of migration and exit capability. His prescription: the next phase of Beijing agent policy should pivot from expanding supply to promoting adoption — maturity assessment and process diagnosis, open and non-discriminatory agent access to enterprise software, capability-permission-responsibility inventories, first-purchase programs tied to real production tasks, staged funding tied to task outcomes rather than Token volume, and risk-sharing, insurance, and business-continuity mechanisms for early adopters."
tags: ["ai-agents", "beijing", "local-policy", "agent-adoption", "industrial-policy", "hong-yanqing", "commentary", "智能体"]
laws_cited: ["beijing-agent-led-development-measures"]
domains: ["ai-governance", "data-economy"]
account: "wangan-xunluren"
original_title: "智能体如何真正进入企业：评《北京市关于加快智能体引领发展的若干措施》之一"
original_author: "洪延青 (Hong Yanqing)"
original_publication: "网安寻路人 WeChat Official Account"
original_url: "https://mp.weixin.qq.com/s/FTiNJt381H31m-DSYWsrqw"
source_language: "zh"
---

> **Source: Data Compliance China** — https://datacompliancechina.com/posts/beijing-agent-measures-adoption-gap/ · China data law, translated and annotated for overseas counsel. Cite as: Data Compliance China, "How Agents Actually Enter the Enterprise: Hong Yanqing on Beijing's Agent-Led Development Measures (Part 1 of 4)", https://datacompliancechina.com/posts/beijing-agent-measures-adoption-gap/
> *Editor's Note — DCC.*
>
> On 21 July 2026 four Beijing municipal bodies — the Municipal Commission of
> Development and Reform, the Office of the Municipal Cybersecurity and
> Informatization Commission, the Municipal Science and Technology Commission
> (Zhongguancun Science Park Administrative Committee), and the Municipal
> Bureau of Economy and Information Technology — jointly issued the
> [**Several Measures of Beijing Municipality on Accelerating Agent-Led
> Development**](/laws/beijing-agent-led-development-measures/)
> (北京市关于加快智能体引领发展的若干措施, 京发改〔2026〕1185号): ten measures
> spanning base models, agent-native applications, smart terminals,
> one-person companies, a "Token (词元) economy," security governance, and
> open source, with up to RMB 100 million in support per key project. It is
> the most consequential local agent-industry policy since the national
> [AI Agent Implementation Opinions](/laws/ai-agent-standardization-innovation-opinion/)
> in May.
>
> **洪延青 (Hong Yanqing)** — among the most influential commentators on
> Chinese data and cybersecurity law, and a careful reader of exactly this
> kind of document — responded with a four-part commentary. DCC translates
> the full set: Part 1 (this brief) on why agent supply does not become
> enterprise adoption; [Part 2](/posts/beijing-agent-measures-security-as-foundation/)
> on security governance as the precondition rather than one measure among
> ten; [Part 3](/posts/beijing-agent-measures-process-maturity/) on a
> five-level maturity scale for agent-reshaped business processes;
> [Part 4](/posts/beijing-agent-measures-token-to-value/) on what should
> measure the value agents actually create.
>
> The series is worth overseas counsel's time for a reason that goes beyond
> Beijing: Hong writes the enterprise-side institutional agenda — agent
> identity, permission scoping, delegated authority, audit trails, exit
> capability — that Chinese regulators and standards bodies are now beginning
> to codify. Read it as a map of the compliance architecture likely to reach
> agent deployments in China ahead of the statutes.

The *Several Measures of Beijing Municipality on Accelerating Agent-Led
Development* is, by the standard of local policy documents, technically
front-line and industrially comprehensive. It does not reduce the AI agent
(智能体) to "a large model plus a chat box." Instead it addresses, in one
document, base models, harness-layer engineering (驾驭层工程), the middleware
stack, tool calling, long-term memory, multi-agent collaboration, development
platforms, skill marketplaces, terminal embedding, scenario building,
computing-power supply, the open-source ecosystem, and security governance.
Arrangements such as on-site co-creation by forward-deployed engineers
(前沿部署工程师), an agent skill marketplace, and an agent software store show
that the drafters understand something many policies miss: industrializing
agents is not only a matter of raising model capability, but of engineering
adaptation, system integration, business-process transformation, and
continuous operation.

Still, by the basic logic of industrial development, an agent is first of all
a technological form — a digital production tool that can embed into
enterprise processes and assist or replace people in completing tasks.
Whether a production tool generates industrial value depends not only on how
much agent supply the market offers, but on whether enterprises have real
demand, whether they are willing to hand concrete tasks to agents, and
whether agents can obtain the data, systems, and permissions those tasks
require.

An agent policy therefore cannot be judged by how many models, platforms,
software stores, skill marketplaces, and "Token factories" (词元工厂) get
built. It must be judged by whether that supply enters enterprises, embeds in
real production processes, and completes tasks continuously, stably, and
accountably.

Measured that way, Beijing's document answers "how to expand agent supply"
quite fully. On "how to form effective enterprise demand" and "how to lower
the institutional cost of enterprise adoption," there is room to go further.

## 1. Agent supply is more than build-versus-buy

The most intuitive way to classify how an enterprise obtains agent capability
is self-build versus procurement. From an industrial-policy perspective, that
binary is not enough. Agent supply needs to be understood along at least two
dimensions: who builds and operates the system, and in what form it is
delivered to the enterprise.

By builder and operator, there are roughly four classes.

**First, enterprise self-build and self-operation.** The enterprise designs
its own business processes and completes agent development, system
integration, permission configuration, and operational management itself. It
may use a self-developed model, an open-source model, or procured base-model
services — but the agent system is ultimately controlled and operated by the
enterprise. This model suits business involving core competitiveness,
sensitive data, and complex internal systems, and suits high-responsibility
sectors such as finance, healthcare, and manufacturing. Its advantages are
deep business fit and strong control over data and systems; its obstacles are
high cost, high talent requirements, and long-term maintenance burden.

**Second, standardized third-party supply.** Agent vendors package
relatively general-purpose capabilities as standard products, which
enterprises consume by software subscription, API calls, or
Agent-as-a-Service. Office work, customer service, human resources, finance
processing, and code generation fit this mode. It deploys fast with low
upfront investment — but a standard product may not fit an enterprise's
particular business rules and organizational processes, and the enterprise
may develop long-term dependence on a model, platform, or vendor.

**Third, joint co-construction between enterprise and vendor.** The vendor
brings models, platforms, and engineering capability; the enterprise brings
business knowledge, data, processes, and internal resources; together they
design, deploy, and iterate the agent. The Measures' proposal of on-site
co-creation and continuous iteration by forward-deployed engineers (FDEs)
corresponds mainly to this mode. For scenarios with strong sectoral
specificity — where standard products do not directly apply and the
enterprise lacks full development capability of its own — joint
co-construction may become the main route by which enterprise-grade agents
land over the coming period.

**Fourth, public or industry-shared supply.** Governments, industry
associations, industrial alliances, or large platforms build common agent
capabilities and serve small and medium-sized enterprises, research
institutions, and solo founders: shared development and testing platforms,
sectoral knowledge agents, tax-finance-legal agents for SMEs, security
testing platforms. This mode lowers the threshold for smaller players, but
public platforms usually address only common needs and struggle to reach deep
into any one enterprise's idiosyncratic processes; they also have to resolve
data isolation, sustained operation, and the boundary between public service
and commercial service.

By delivery form, agents divide into three basic modes.

**Whole-solution delivery** — the enterprise obtains a relatively complete
agent product: model, knowledge, tools, workflow, and operational management
included.

**Componentized assembly** — the enterprise or an integrator separately
obtains base models, sectoral models, knowledge bases, plug-ins, skills,
memory modules, workflow-orchestration tools, security components, and
evaluation tools, then assembles them into a concrete agent. The skill
marketplace, the capability-resource sharing platform, interconnection
protocols, development frameworks, and the open-source toolchain proposed in
the Measures mainly serve this form of supply.

**Embedded supply** — the agent does not appear as an independent product but
is embedded directly in the software, platforms, or terminals the enterprise
already uses: an expense-reimbursement agent inside finance software, a sales
agent inside the CRM, design and scheduling agents inside industrial
software, system-level agents inside phones, cars, and robots. For the mass
of ordinary enterprises, acquiring agent capability "as the software
upgrades" may spread far more easily than procuring a standalone agent
platform.

Seen this way, open versus closed source, public cloud versus private
deployment, per-Token versus per-result billing are not parallel supply
modes; they are dimensions of technology licensing, deployment, and pricing.
The questions policy must actually answer remain: who builds, who operates,
whether the enterprise obtains a whole product or component capabilities, how
much control the enterprise has over the system, and who is responsible when
something goes wrong.

Against that classification, the Beijing Measures' coverage of supply is
already fairly complete. Base models and harness-layer engineering support
enterprise self-build and the growth of professional vendors; forward-deployed
engineers correspond to joint co-construction; the skill marketplace and
open-source platforms correspond to componentized supply; smart terminals and
the AI operating system correspond to embedded supply; public service
platforms and computing-power support aim to lower the adoption threshold for
SMEs.

Which means the binding constraint on Beijing's agent industry is probably no
longer the richness of supply forms — it is how this supply connects to real
enterprise demand.

## 2. Enterprises do not need "an agent" — they need tasks completed

An enterprise rarely generates a real purchase because it "needs an agent."
What an enterprise actually cares about is whether an agent can cut a cost,
shorten a processing time, raise production efficiency, reduce errors,
improve customer service, or complete tasks that staffing, cost, or
technology previously put out of reach.

The basic unit of agent demand is therefore not "number of agents," nor even
the loose "application scenario." It is a concrete task or segment of a
business process that can be defined, delegated, measured, and accepted.

By depth of entry into the enterprise, demand divides into roughly four
levels.

**Level one: personal and single-task assistance** — retrieving materials,
summarizing documents, drafting text, organizing meeting notes, assisting
with code. These tasks rarely require deep access to core enterprise
systems; standardized third-party products or embedded features suffice.

**Level two: departmental process assistance** — customer service, sales
management, procurement review, expense processing, internal knowledge
lookup. The agent needs access to departmental data and software, but mostly
produces suggestions, prepares materials, and assists processing. Standard
products plus limited customization can cover this.

**Level three: reconstruction of core enterprise processes** — supply-chain
scheduling, R&D and design, production planning, quality control, risk
management, cross-departmental coordination. The agent spans multiple systems
and organizational units, continuously manages task state, and has material
effect on business processes. This typically requires self-build or joint
co-construction.

**Level four: acting externally on the enterprise's behalf, or directly
changing real-world state** — automatic contracting, payment, submitting
regulatory filings, making commitments to customers, modifying account
permissions, controlling production equipment. An agent at this level no
longer merely generates information; within some scope it acts for the
enterprise. Whether it lands depends less on technical performance than on
whether authorization, responsibility, security, and external legal effect
have been properly arranged.

Different depths of demand should be matched with different supply and
governance modes. Low-risk, standardized, reversible tasks can go first to
mature third-party products. Tasks touching core data and core processes fit
self-build or co-construction. Tasks that act externally with irreversible
consequences require the strictest permission, approval, recording, and
responsibility mechanisms.

The policy implication: government cannot exhort all enterprises alike to
"build agent platforms," nor apply one set of subsidies, evaluations, and
regulatory requirements to every agent project. Effective policy helps
enterprises find the tasks that are suitable to hand to agents — and select
the supply mode that matches each task's complexity, data sensitivity, and
execution risk.

## 3. Six thresholds between agent supply and enterprise production

Agents can already generate text, code, and plans of fairly high quality. But
being able to generate is not the same as being able to enter an enterprise's
production processes. Between technical supply and enterprise productivity
stand demand formation, process transformation, system access, permission
granting, responsibility arrangement, and acceptance of results.

### Threshold 1: Latent demand has not become procurable, acceptable tasks

Many enterprises have registered that AI and agents matter, but their demand
stays at the level of concepts — "build an enterprise agent," "create digital
employees," "form multi-agent collaboration." That is technology and
project-construction language, not a clear business requirement.

A requirement that can actually land must at minimum specify: who performs
the task today, at what time and cost; what the main problems are; which
step the agent is meant to enter; what outcome improvement is expected; how
much error can be tolerated; and who signs off and bears responsibility.

Without answers to those questions, an enterprise that builds the platform
and connects the model still ends up with "systems without tasks" and
"agents without users."

Beyond publishing scenario-demand lists, government should therefore support
enterprises in running business-process diagnosis and agent-application
maturity assessments. A business pain point is not yet effective demand.
Only when the task can be clearly defined, the investment estimated, and the
result accepted does latent demand become a real purchase.

### Threshold 2: Many enterprise processes lack the foundation for intelligence

An agent cannot automatically repair a business process whose
responsibilities are unclear, whose rules are chaotic, and whose data is
missing.

In practice, many enterprise processes run on personal experience and
offline coordination. Approval rules have never been standardized; several
departments process the same matter redundantly; exceptions are handled by
ad hoc communication; no one owns the end-to-end result. Under those
conditions, even a model with strong reasoning and planning cannot execute
stably.

Agent adoption is therefore, first of all, process governance. The
enterprise needs to fix task boundaries, operating rules, data sources,
exception handling, and responsible parties — then decide which parts to
hand to an agent.

The Beijing Measures' direction — using agents to restructure product
architecture, service models, and core business processes — is right. The
follow-through should support process standardization and organizational
transformation, so that agents are not simply stacked on top of disorder.

### Threshold 3: Agents cannot obtain the necessary data, systems, and tools

To complete real tasks, an agent usually cannot stop at generating content:
it must read data, invoke software, use tools, and execute operations inside
business systems. But enterprise data and systems are scattered across
departments; legacy systems lack standard interfaces; different software
uses different identity and permission schemes; and some platforms restrict
third-party agent access outright.

Enterprises carry a parallel set of worries: which data may be given to an
agent at all; which may be handed to an external vendor; how the personal
information of employees, customers, and third parties is protected; whether
trade secrets may enter an external model; and how an agent's long-term
memory and execution records are to be managed.

An agent that can only read public information remains an information
assistant. An agent that can read and modify systems at will is an
uncontrollable security risk.

Scaled adoption therefore requires a controlled-access mechanism: the agent
has an identifiable, traceable identity; the enterprise can bound the data
it may read, the tools it may call, and the operations it may execute;
third-party agents that meet uniform security conditions can access
software, platforms, and terminals fairly; and incumbent platforms cannot
use interface control to unreasonably exclude third-party agents. (For the
security baseline now emerging on exactly these points, see DCC's brief on
[TC260's agent-deployment security guidelines](/posts/tc260-ai-agent-deployment-security-guidelines/).)

This is not merely a technical interconnection problem. It is the
institutional question of whether the agent industry will form an open
market.

### Threshold 4: Enterprises lack authorization and responsibility regimes built for agents

Traditional enterprise permission systems are designed around natural-person
employees: a person belongs to a department, holds a position, and receives
system and business permissions accordingly. Once agents enter, the
enterprise must answer new questions. In whose name does the agent act? Who
may authorize it, and for how long? Which data may it access, which tools
may it call, to whom may it pay money, send mail, or submit filings?

More important, an agent's task plan can change mid-execution. If the
actions actually taken exceed the approved counterparties, amounts, data
scope, or task purpose, does the original authorization still hold? When an
employee leaves or changes roles, are the permissions of agents that
employee created or used revoked in step? May an agent inherit an employee's
long-term credentials?

Until these questions are answered, enterprises will not dare hand agents
anything important.

What adoption requires is not an undifferentiated "human in the loop," still
less a user clicking confirmation on every step. It is a configurable,
machine-executable authorization regime: low-risk, repetitive, reversible
actions run continuously within defined counterparties, time limits,
amounts, and data scope; high-risk actions — payment, contracting, external
data transmission, account modification, equipment control — or any action
that exceeds the originally authorized boundary trigger renewed approval.

Every production-grade agent project should likewise name its business
owner, technical operations owner, permission approver, final decision-maker,
and exception handler. An agent is not a legal subject that bears
responsibility on its own; "agent responsibility" always resolves into
internal enterprise responsibility and supply-chain contractual
responsibility.

### Threshold 5: Conventional procurement and acceptance do not fit agent projects

Traditional software procurement assumes requirements fixed in advance,
development against a feature list, and one-time acceptance at launch. Agent
projects need continuous tuning in live business, while the enterprise's own
processes change in parallel. Vendors cannot promise every business outcome
up front; enterprises cannot specify every requirement at signing.

Agent outputs also carry irreducible variance — the same task may produce
different results. Acceptance that only checks whether features exist misses
long-term stability; demanding that an agent never err keeps almost every
application out of production.

The sounder approach is acceptance criteria built around the task: task
completion rate, first-pass success rate, error rate, share of output
requiring human review, average processing time, cost per valid completed
task, abnormal-termination rate, human-takeover rate, sustained stable
runtime.

This is also why Token consumption and call volume cannot serve as primary
policy performance indicators. Tokens are production input, not final
output. The longer the context, the more idle loops, the more retries after
failure — the higher the Token count. What the enterprise buys is not Tokens
but reliably completed tasks.

The general lesson of industrial policy points the same way: what needs
measuring is not input or nominal scale but whether input becomes usable,
sustainable real effect — the research literature calls it the shift from
measuring inputs to measuring outcomes.

Agent projects should accordingly run staged procurement and acceptance:
process diagnosis and small-scale validation first; then pilot runs in real
business; expanded deployment once task-effect and security requirements are
met; payment released in stages against stable operation and business
results. Projects that cannot meet the bar should stop promptly, rather than
surviving indefinitely on subsidy.

### Threshold 6: Enterprises lack migration and exit capability

Once core processes ride on an agent, the enterprise binds itself deeply to
particular models, platforms, plug-ins, and vendors. If data, memory,
business rules, and workflows cannot be exported, switching becomes
practically impossible.

Hence a contradiction: the deeper an agent reaches into core processes, the
more value it can create — and the stronger the dependence on its vendor. If
the vendor discontinues service, changes pricing, alters interfaces, or
suffers a major security incident, the enterprise may be unable to restore
manual processes or migrate in time.

Policy should therefore secure not only entry but exit. A production-grade
agent should at minimum export its data and run records; business rules and
workflows should be reasonably portable; key interfaces should use
relatively open standards; the enterprise should be able to swap models,
plug-ins, and vendors; a withdrawing vendor should bear transition
obligations; high-risk processes should retain human-takeover and
business-continuity plans.

Without exit capability, enterprises dare not delegate critical tasks.
Without portability, the agent ecosystem drifts toward a closed market
controlled by a few platforms.

## 4. The next phase: from expanding supply to promoting adoption

On the supply side, Beijing has laid out the industry's main links fairly
completely: supporting base models and harness-layer engineering, building
development platforms and skill marketplaces, encouraging on-site co-creation
by forward-deployed engineers, pushing agent integration with software,
terminals, and sector scenarios, and lowering innovators' supply costs
through computing power, data, talent, open source, and public services.

The more important next task is a policy for enterprise adoption. Hong
proposes six elements:

1. **Support maturity assessment and process diagnosis**, converting abstract
   AI demand into tasks that can be delegated, procured, and accepted.
2. **Open agent access** — push enterprise software, internet platforms,
   operating systems, and smart terminals to expose secure, transparent,
   non-discriminatory agent-access capability, so agents meeting uniform
   security conditions can obtain the data and tool permissions their tasks
   require.
3. **Build capability-permission-impact-responsibility inventories** for
   agents: where in the workflow the agent sits, what it can access and
   change, which actions run automatically, which require renewed approval,
   who answers for the final result.
4. **First-purchase, first-use (首购首用) programs on real production tasks**
   by government departments, state-owned enterprises, and key-sector users —
   not procurement of abstract platforms, and not project goals denominated
   in model or agent counts.
5. **Reform procurement and fiscal support**: tie disbursement to real
   usage, task completion rates, cost per valid result, stable operation,
   and replicability; build declining subsidies and failure-exit mechanisms.
6. **Risk-sharing, insurance, migration, and business-continuity
   mechanisms** to cut the risk of being an early adopter, especially for
   SMEs.

Ultimately, what matters to agent-industry development is not how many
products called "agents" reach the market, but how many agents actually
enter enterprises, how many enterprises are willing to hand them real tasks,
and whether those tasks are completed stably, cheaply, and accountably.

Beijing's document has answered the first question well — who supplies
agents, and what technology, platforms, and inputs the industry needs. Two
questions remain: why would enterprises adopt agents, and on what basis does
an agent enter an enterprise process and obtain the authority to act?

Agent policy, Hong concludes, has three interlocking layers. The supply side
resolves who can provide usable agents. The demand side resolves what tasks
enterprises are willing to delegate. The institutional side resolves how an
agent enters a process, obtains permissions, produces results, and bears
responsibility. Only when the three connect do models, platforms, skill
marketplaces, software stores, computing infrastructure, and scenario
projects convert into reliably completed tasks, sustainable enterprise
revenue, and real industrial value.

---

*This brief translates and condenses 洪延青 (Hong Yanqing), "智能体如何真正进入
企业：评《北京市关于加快智能体引领发展的若干措施》之一," published on the
网安寻路人 WeChat Official Account on 2 August 2026
([original](https://mp.weixin.qq.com/s/FTiNJt381H31m-DSYWsrqw)). Details of
the Measures (document number, issuing bodies, dates, and the ten-measure
structure) are taken from the official text published at beijing.gov.cn on
23 July 2026. The section structure follows the original; headings are
lightly edited for English readers. Parts 2, 3, and 4 of the series are
translated in separate DCC briefs.*

— Not legal advice.