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 (北京市关于加快智能体引领发展的若干措施, 京发改〔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 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 on security governance as the precondition rather than one measure among ten; Part 3 on a five-level maturity scale for agent-reshaped business processes; Part 4 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.)
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:
- Support maturity assessment and process diagnosis, converting abstract AI demand into tasks that can be delegated, procured, and accepted.
- 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.
- 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.
- 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.
- 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.
- 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). 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.