On September 11, 2026, China's Ministry of Industry and Information Technology (MIIT) published the Implementation Plan for the “AI Plus Software” Special Action. Numbered Gong Xin Bu Xin Fa [2026] No. 209 and dated September 2, the document was issued to industry and information technology authorities in all provinces, autonomous regions, municipalities and the Xinjiang Production and Construction Corps, asking them to implement it in light of local conditions.
The title might suggest a simple call for software companies to use more AI. But the eight-page plan and its 19 tasks address much more than AI-assisted coding.
The document tackles three fundamental questions for the software industry.
First, how will software be produced?
Second, what will software itself become?
Third, when software starts acting continuously as an agent, who will provide the execution frameworks, skills, markets, standards, security and boundaries of responsibility?
Document No. 209 therefore matters for more than adding another “AI Plus” policy. China is beginning to organize intelligent programming, agent software and intelligent services as new growth drivers for the software industry. Agents, previously often grouped together with large models, chatbots and automation tools, now sit within a complete software value chain: development tools, execution frameworks, software products, skill packages, application marketplaces, delivery services, and standards for identity, interfaces, behavior and security.
Agents are moving from a model feature toward a distinct form of software.
Understanding Document No. 209 in Six Terms
- Intelligent programming — Transform software production
- Intelligent companions — Upgrade existing software
- Agent software — Develop new product forms
- Skills — Package specialist capabilities
- Intelligent services — Deliver value continuously
- Verifiable behavior — Inspect execution and outcomes
I. Beyond Document No. 414: Adding Products and Infrastructure
To understand Document No. 209, it helps to place it in the sequence of policies released in 2026, without treating the documents as interchangeable.
Document No. 414, published on August 31, organizes a resource pool, service teams, real use cases, delivery arrangements and ongoing evaluation around AI application service providers. Its question is: who brings AI into enterprises, and who takes responsibility for consulting, implementation, operations and security governance?
The Artificial Intelligence SME Entrepreneurship Support Plan (2026–2028), published on September 4, brings AI-native firms, agent developers, open-source contributors, “one-person companies” and highly capable individual entrepreneurs into the scope of startup support. Its question is: who starts new AI businesses, and how will the computing, data, use cases, capital and services they need become available?
We analyzed those documents in MIIT Document No. 414 Explained: From Model Supply to Application Delivery and MIIT's AI SME Entrepreneurship Support Plan Explained: An AI Startup Ecosystem Is Taking Shape.
Document No. 209 addresses a third question:
What software will these entrepreneurs and service providers actually produce, run and deliver?
It takes policy further inside the software industry. From production tools, technical foundations, product forms and service models to open source, computing, data, standards, talent and security, it offers a more complete plan for building the industry.
The three documents have distinct roles:
| Document | Main subject | Central question |
|---|---|---|
| Document No. 414 | AI application service providers | Who handles consulting, integration, delivery, operations and governance? |
| Entrepreneurship Support Plan | AI SMEs and entrepreneurs | Who starts businesses, and how do they obtain computing, data, use cases and capital? |
| Document No. 209 | Software and information technology services | How is next-generation software produced, how does it run, and what industrial foundations does it need? |
If Document No. 414 organizes the delivery teams and the entrepreneurship plan cultivates new companies, Document No. 209 defines the software industry system they will help build.
Figure 1. The three policies address delivery providers, startup support and the software industry: distinct but complementary roles. Source: Relevant MIIT policy documents; compiled by the author.
II. Why “AI Plus Software” Means More Than Adding AI to Software
The opening of the document identifies three things AI is changing: development methods, product forms and service models.
Each represents a different transformation.
The first transformation: how software is produced
AI will no longer be merely a completion tool used while a programmer writes a piece of code. It will participate throughout a project: understanding requirements, designing architecture, coding, testing, checking security, deployment, operations and ongoing changes.
The plan therefore calls for agent-driven intelligent programming tools, stronger project-level autonomous development across the full process, and deeper integration with code hosting platforms, cloud services and open-source communities. The relevant unit is no longer how quickly a function can be written, but whether an entire software project can be completed more efficiently and reliably.
This also explains the call for intelligent upgrading within software companies. Genuine upgrading means more than installing a chat plugin for every programmer. It requires redesigning development processes, quality control, security checks and collaboration, with results assessed through code quality, development effectiveness and other practical outcomes.
The second transformation: what a software product is
Traditional software mainly waits for users to click menus, fill in forms and issue commands. Agent software can receive goals, understand its environment, select tools, execute successive steps and adjust subsequent actions based on results.
The document therefore treats agent software as a new product form in its own right, rather than discussing only AI features added to existing software. It covers capabilities embedded in operating systems, databases, industrial software and devices, as well as general-purpose agents, specialist industry agents and industrial agents.
This raises the agent from an interface feature to a software product category.
The third transformation: how software services work
Traditional software services tend to revolve around licenses, implementation projects and maintenance. Intelligent software services may instead become a continuously operating service chain: models keep changing, knowledge is updated, agents keep executing, permissions and costs evolve, and results need ongoing verification.
The plan calls for an end-to-end intelligent application service chain, encourages software firms to become AI application service providers, and promotes a shift from one-off delivery to ongoing service and value delivery.
Together, these three changes express the full meaning of “AI Plus Software”: AI is reorganizing software production, products and business models.
III. 2028 and 2030: From Adoption at Scale to Industry Upgrading
Document No. 209 sets two stages of objectives.
By 2028:
- Intelligent programming tools and intelligent development platforms should reach 20,000 software enterprises above the designated size.
- A total of 100 intelligent upgrading projects should be implemented in software companies.
- Priority industries should develop 100 benchmark agent software applications.
- At least 15 hardware–software adaptation centers should be established.
- At least five high-quality open-source projects should be incubated.
By 2030:
- Key software should have undergone comprehensive intelligent upgrading.
- Intelligent programming, agent software and intelligent services should become new industry growth drivers.
- A number of internationally influential open-source communities and industry clusters should be established.
These figures should not simply be added together: each serves a different policy purpose.
Reaching 20,000 companies measures diffusion of production tools. The 100 upgrading projects are meant to produce reusable examples of company transformation. The 100 benchmark agent applications test whether new products can enter real industries. Adaptation centers support hardware–software coordination and industrial validation. Open-source projects contribute to a shared technical ecosystem.
The plan is therefore building adoption at scale, demonstration projects, validation facilities and open-source foundations at the same time.
Read together, the targets emphasize adoption and validation at scale by 2028, followed by upgrading key software, growing new business forms, and developing internationally influential open-source communities and industry clusters by 2030. They describe a policy path from broader adoption toward industry upgrading, rather than suggesting that the industry's structure will be settled by then.
Figure 2. The 2028 targets cover firms, projects, applications, compatibility centers and open source; 2030 points toward industry transformation. Source: Relevant MIIT policy documents; compiled by the author.
Agents Are a New Growth Area, but Document No. 209 Is Not an Agent-Only Policy
The implementation plan also addresses intelligent upgrading of foundational and industrial software itself. Operating systems and databases are to improve agent scheduling, performance tuning, operations and security, with chip and server manufacturers collaborating on hardware–software compatibility and adaptation centers. Industrial software such as CAD, CAE and EDA is to apply AI to drawing, design and simulation, while industrial internet platforms strengthen data analysis, production scheduling and multi-agent decision-making.
Document No. 209 should therefore be read as combining upgrades to existing software with the development of new software forms. Foundational software, industrial software and development methods all need intelligent upgrading. Agents are an important emerging form within that broader software-industry transformation.
IV. The Most Consequential New Concept Is Agent Software
Intelligent programming matters: it directly affects software production efficiency and can scale relatively quickly. From an industry-structure perspective, however, the most notable part of Document No. 209 is its fourth section, on cultivating new forms of agent software and accelerating their continuous evolution.
It introduces at least four layers.
1. Agent execution frameworks
The plan calls for engineering research into agent execution frameworks, improving reliable execution of complex tasks and collaboration among multiple agents.
The emphasis on execution frameworks shows attention to engineering foundations beyond models. From an enterprise engineering perspective, a large model can generate an answer, but it does not automatically solve persistent state, tool use, permission constraints, failure recovery, concurrency conflicts, handoffs and acceptance of results over a long-running task. These are engineering questions the author derives from reliable execution and multi-agent collaboration, not a feature checklist prescribed item by item in the document.
2. Agent software development platforms
The document proposes agent software development platforms and better toolchains for development, testing, deployment and operations.
Agent development cannot remain a collection of prompts, demonstration pages and temporary scripts. Like mature software, it needs design, testing, releases, monitoring, upgrades and maintenance, supported by repeatable engineering processes.
3. Agent software products
The plan separately addresses general-purpose agents, device agents, specialist agents for vertical domains and industrial agents. Each category brings different reliability and accountability requirements.
An office information-processing agent can work under human review. Device agents need lightweight inference and privacy protection. Vertical-domain agents need knowledge graphs and industry data. Industrial agents may enter core production processes and interact with industrial control systems and critical business systems. They therefore require greater safety, reliability and verifiable behavior.
4. Agent software application markets
The document also proposes agent software application stores and skill-package repositories, with rules for listing reviews and operational management.
This is a consequential step. Agents, skills and components must be discoverable, installable, composable, updatable and tradable if an agent software ecosystem is to develop, instead of every project starting from scratch.
Together, these four layers form a complete chain:
Execution frameworks provide the foundation; development platforms produce software; agent products enter real use cases; marketplaces distribute them; service providers handle delivery and operations.
Figure 3. Execution frameworks, development platforms, agent products and distribution form an industry, with delivery and governance spanning the chain. Source: Relevant MIIT policy documents; compiled by the author.
V. Skills Are Formally Included in Agent Software Markets: More Than a Prompt Marketplace
Document No. 209 explicitly proposes repositories for skill packages, or Skills, and encourages developers to build high-quality specialist skills, knowledge bases and functional components for agents.
A skill may appear to be a packaged capability: organizing contracts, analyzing equipment faults, generating quotations or operating a business system. Once it enters an enterprise or an application marketplace, however, it cannot remain a few paragraphs of prompts.
From an enterprise engineering perspective, a commercially usable skill package raises the following questions. They are the author's deductions from the proposed skill repositories, listing reviews and operational management, rather than requirements individually prescribed by the document:
- Who publishes it, and can that identity be trusted?
- Which agents and execution environments can use it?
- Which models, data and tools does it depend on?
- What permissions can it receive?
- How are versions upgraded and rolled back?
- What external effects does execution produce?
- Can it stop, recover or undo work after an error?
- Who approves its listing, and who handles ongoing operations?
- Are its intellectual property, data sources and security risks clear?
A mature Skills market will therefore resemble a software-package ecosystem for agents. Capabilities are modular, dependencies and permissions are explicit, effects can be inspected, and versions and responsibility can be traced.
This also creates new specializations. Some firms will build general-purpose skills; others will provide industry knowledge packages, maintain internal enterprise repositories, review security and compatibility, or operate agent marketplaces for particular industries.
Many small AI firms may not need to train their own foundation model. They can instead package knowledge, tools and workflows around a valuable business process. This connects directly with the entrepreneurship plan's emphasis on agent developers, open-source contributors and small specialist businesses.
VI. Why Verifiable Behavior Could Be the Dividing Line for Industrial Agents
In its provisions for industrial agents, the plan calls for safety, reliability and verifiable behavior.
The final requirement is easy to overlook, yet it may determine whether agents can enter actual production and business processes.
When a chatbot says something wrong, a user can often ignore or correct it. If an industrial agent changes production schedules, operates equipment, adjusts parameters, writes to a business system or triggers procurement, an error can become a real loss. A chat history alone cannot prove what happened or whether the result stayed within authorization.
From an enterprise engineering perspective, the author breaks verifiable behavior into the following questions. This is an analytical framework, not an acceptance standard itemized in the document:
- What task did the agent receive?
- Who authorized execution?
- Which tools did it call?
- What effects did those tools actually produce?
- Did the results meet the business objective?
- Who has authority to accept results and resolve disputes?
- Did recovery repeat external effects whose status was unknown?
A model's account of its own behavior cannot answer all these questions. Model output can contribute evidence, but does not automatically establish facts. Software can inspect files, states, hashes and tool results, but cannot assume the business owner's authority to judge whether the result is acceptable.
Industrial agents therefore need more than higher model accuracy. They need task agreements, identity and authorization, execution records, evidence of effects, independent verification and recovery mechanisms. Providers that turn these engineering capabilities into affordable, integrable infrastructure can help agents move from convincing demonstrations to systems that enterprises can actually trust to use.
Figure 4. Verifiable behavior separates task, authority, execution, effects and acceptance; recovery also requires state and side-effect checks. Source: Relevant MIIT policy documents; compiled by the author.
VII. Four Main Directions for Agent Standards
Document No. 209 does not announce a completed set of national agent standards. It commissions and advances subsequent standards development. That distinction matters.
The document proposes:
- Graded maturity assessment standards for intelligent programming capabilities.
- Agent interface standards supporting hardware–software coordination.
- Research into intelligent service standards, including Model as a Service and Agent as a Service.
- Research into agent identity, trusted interconnection, data security and behavior control.
- Security management requirements covering agent development, deployment and application.
These provisions suggest four main directions.
The first is capability standards: how broad a task can a coding tool or development platform complete, and how should maturity be classified? Vendor claims are insufficient.
The second is interface standards: how should different models, devices, hardware, software systems and agents connect, without locking every capability into a single platform?
The third is service standards: how should MaaS and AaaS define scope, quality, measurement, responsibility and requirements for ongoing operations?
The fourth is governance standards: under what identity does an agent enter a system, how does it obtain permission, how can it connect trustworthily, and how are data and behavior protected, recorded and controlled?
The direction is now clear, but standards are still taking shape. The most useful work companies can do is accumulate real execution evidence, interface experience, security mechanisms and failure cases that can support standards development and pilot validation. Claiming compliance with unpublished national standards is premature.
VIII. Open Source as a Mechanism for Discovery, Validation and Diffusion
The plan makes collaborative open-source innovation part of the foundation for intelligent software development. It calls for nationwide open-source foundations and AI communities to encourage firms to release work on intelligent programming, intelligent software products and agents. It supports first releases of key projects through communities, greater use of domestically developed open-source licenses and compliance guidance, and mechanisms for selecting and cultivating high-quality projects.
One particularly notable proposal is to explore open-source contributions as a reference for identifying promising software SMEs.
This echoes the entrepreneurship plan's use of public indicators such as project stars to identify high-growth potential. Document No. 209 goes further: open-source activity should help identify firms, while strong projects should also enter actual manufacturing, finance and other industry applications.
That could change how agent infrastructure projects develop.
A project once viewed primarily as a technical community contribution may become an entry point for policy support, industrial validation, service-provider partnerships and deployment. But visible code must become usable capability: clear installation instructions, stable interfaces, traceable versions, compliant licensing, reproducible tests and evidence of real use.
Stars increase visibility, but do not establish reliability. Publishing code alone does not establish industrial capability. The policy seeks projects that can participate in real software production and industry applications.
IX. Funding, Projects and Use Cases: Direction Is Clear, Applications Are Still to Come
In its implementation provisions, Document No. 209 proposes mechanisms such as challenge-based project selection, coordination of funding channels and first-version software product recognition policies, support for eligible projects, and dedicated fiscal funding for key technology research, infrastructure and practical applications.
This creates the prospect of projects, pilots, standards work, adaptation centers, benchmark applications and local support measures.
The plan's computing-service provisions already call for compute vouchers and other broadly accessible support policies to reduce software companies' computing costs. MIIT's official explanation goes further: local authorities are encouraged to use compute vouchers and related policies to cover a proportion of the costs of purchasing domestically developed programming tools and using programming services from domestically developed large models. Support is therefore not confined to major projects; the policy also points toward assistance with companies' purchases of intelligent programming tools and model services.
Policy direction must nevertheless be distinguished from an entitlement already granted.
Neither the plan nor this explanation sets a nationwide subsidy percentage, claim requirements or implementation timetable. They also do not publish unified project application dates, company eligibility rules, scoring criteria, funding pools or award amounts per project. Words such as support, encourage and explore do not mean every relevant company automatically receives a subsidy. Eligibility, covered expenses and payment timing remain subject to local policies and application notices.
Companies should prepare five kinds of material:
- Reproducible product capabilities and clear technical limits.
- Real customer use cases and evidence of outcomes.
- Complete development, testing, deployment and operating processes.
- Explanations of data, permissions, security and intellectual property.
- Demonstration cases that can be replicated, extended and inspected by third parties.
When applications open, the strongest teams will be those that can demonstrate solutions to the engineering problems identified by the plan.
X. The New Software Value Chain Taking Shape
Document No. 209 covers far more participants than foundation-model companies. Its provisions point toward a new value chain:
Figure 5. Eight specializations in the agent software value chain and their core capabilities. Source: Author's analysis of MIIT Document No. 209.
Not every company needs to build an all-encompassing agent platform. Specialist strengths in execution, skills, evaluation, security, integration or a particular industry can support independent businesses.
This is especially relevant to SMEs. They may struggle to compete with large firms in general-purpose foundation models, but can build advantages in data, processes, knowledge and delivery around a narrow, demanding use case. An agent that reliably handles procurement inquiries, equipment-fault analysis, research-document organization, quality tracking or export-customer management may have more commercial value than a feature-rich general assistant that cannot enter real operations.
XI. Competition Will Turn to What AI Actually Achieves
The provisions on intelligent upgrading in software companies identify code quality and development effectiveness as important measures of intelligent programming adoption. This directly affects how companies should approach AI.
Connecting a foundation model will increasingly be insufficient as evidence of progress. Companies will need to answer:
- How much shorter is the delivery cycle?
- Have defect rates fallen?
- Are security issues detected earlier?
- Have test coverage and maintenance efficiency improved?
- Can complex projects progress through completion?
- Do workflows remain stable after models or tools change?
- How are jobs redesigned, rather than simply eliminated?
An Often-Overlooked Policy Signal: Stabilize Jobs, Expand Opportunities and Support Transitions
MIIT's official explanation addresses employment directly through three priorities:
- Stabilize jobs: protect existing employment in software and prevent sudden, large-scale unemployment.
- Expand opportunities: use agent software and intelligent services to create employment opportunities, including new roles in code review and AI security.
- Support transitions: strengthen job training and help software workers move into higher-value roles.
Document No. 209 consequently addresses technology and products alongside a practical question: what happens to people as AI transforms the software industry? It does not simply encourage replacing programmers with AI. As production is reorganized, the policy brings job redesign, skills training, new roles and assessments of employment effects into the same framework.
For companies implementing the changes, a transformation plan should address more than development efficiency and tool costs. It should explain which roles will change, how people will be trained and redeployed, who will take responsibility for code review and AI security, and how employment risks will be identified and managed. A reduction in manual steps alone is not a complete measure of successful transformation.
Mature transformation requires a renewed division of work: machines perform executable tasks at scale, while people retain responsibility for goals, boundaries, professional judgment, exceptions and final accountability.
XII. How Different Software Firms Can Transform
Document No. 209 does not give every software company the same task of connecting a large language model. Firms have different customers, products, technologies and delivery models, so their starting points should differ. The right sequence is to identify what is worth preserving in the existing business, determine which work can be delegated to agents, and then decide which capabilities are missing.
1. Established software vendors: retain the business foundation and add task-performing capabilities
For companies with ERP, CRM, finance, collaboration or industry software, the most valuable assets often include business objects, permission systems, historical data and customer trust. A natural-language interface is no reason to discard those assets.
A more practical path starts with bounded tasks: detecting unusual orders, preparing customer follow-up recommendations, explaining business data, or drafting transactions for review. Agents should access existing systems through controlled interfaces, rather than bypassing permissions to modify databases directly.
The transformation is not simply replacing menus with a chat box. It is moving from users performing every step to users setting a goal and the system completing a task within authorized limits. Existing approval and accountability mechanisms should remain for consequential actions involving payments, contracts, inventory or commitments to customers.
2. Project providers and integrators: move toward reusable products and ongoing operations
These firms understand customer environments, business processes and system integration. Their advantage is knowing which problems matter, not necessarily training another foundation model.
They should look for recurring needs across existing projects and turn reusable knowledge, interfaces, skills and acceptance methods into product packages. They must distinguish standard delivery from customization, while including model updates, knowledge maintenance, incident handling, security checks and outcome reviews in ongoing service.
The business model also needs clear boundaries: what implementation fees, subscriptions or operating fees cover; which data the customer supplies; who handles exceptions; and how service is handed over when a contract ends. Outcome-based pricing may be possible where outcomes can be measured and responsibility attributed. Promising it before defining acceptance is premature.
3. Tool and platform companies: move from isolated generation to verifiable engineering
For coding tools, development platforms, cloud services and execution-framework providers, competition shifts from generating a piece of code to advancing a project reliably and producing maintainable results.
Within their product boundaries, firms need to build or integrate version control, testing, security checks, deployment, persistent state, tool permissions, cost control and recovery. No platform must build every component itself, but dependencies, integration responsibilities and failure ownership must be clear.
Evaluation should return to real projects: are delivery time, defect rework, maintenance costs and human intervention improving? A demonstration or model benchmark can establish a limited capability, but cannot replace project-level delivery evidence.
4. Specialist software SMEs: deepen expertise in a valuable, bounded process
Smaller firms need not treat a comprehensive general-purpose agent platform as the inevitable destination. More practical opportunities often lie in narrow but demanding work such as procurement inquiries, equipment-fault analysis, quality tracking or research-document processing.
They can use existing models and platforms to package domain knowledge, tool interfaces and procedures into specialist agents or Skills. What can be sold, however, is more than a prompt: it includes a defined scope, data requirements, permission boundaries, test examples, an upgrade method and a service commitment.
Productization depends on whether the capability can be reused across customers and whether deployment and maintenance costs remain manageable. If each customer requires substantial redevelopment, it must still be accounted for as project work. Using an agent does not automatically turn it into a software product.
Figure 6. Firms should choose transformation opportunities from their existing strengths and business boundaries, then address missing capabilities. Source: Author's enterprise transformation analysis informed by Document No. 209.
This is a business analysis informed by the policy, not an official classification or a prescribed transformation route. A company can occupy several positions. The point is to identify a boundary within which it can create value, rather than relabel every existing product with policy terminology.
XIII. Making Transformation Work: From One Use Case to Continuous Delivery
After choosing a direction, a company still needs to answer a practical question: what should it do first, and what evidence justifies further investment?
Transformation need not begin with replacing every system, buying models in bulk or establishing a large AI department. A more measured approach starts with a verifiable business task and proceeds through choosing a use case, piloting it, establishing a service and expanding reuse. The following is implementation advice, not a process or timetable prescribed by Document No. 209.
Step 1. Select the use case and establish the business baseline
Prioritize work with genuine, recurring demand, relatively stable inputs and inspectable results. Confirm the rights to use the data, permission to access the necessary systems, and the ability to hand control back to a person when something goes wrong.
For example, start with organizing procurement inquiries and flagging exceptions, then consider drafting transactions for approval. Do not begin with automatic payments whose authorization boundaries are undefined.
Before the pilot, record processing time, volume, errors, rework, labor costs and the acceptance method, and assign a business owner. Otherwise it will be difficult to tell whether any improvement came from AI, a process redesign or additional human effort.
Step 2. Pilot within controlled boundaries and record failures as well as successes
Agree on permitted data, tools, permission limits and human-intervention conditions before introducing the agent into the process. Begin with read-only access, recommendations or actions after human review, then expand the scope as evidence warrants.
Validation should include missing data, tool timeouts, expired permissions, model changes and duplicate requests. Can the system stop, notify, hand off to a person or recover safely? Operations with external effects need particular care: an absent success response is not proof that an operation did not execute.
Proceed only when quality, efficiency and controllability meet the previously agreed acceptance criteria. If they do not, narrow the use case, revise the approach or stop the pilot.
Step 3. Establish a sustainable service and reorganize roles and costs
A successful technical pilot does not establish commercial readiness. Companies must also assign responsibility for model and knowledge updates, incident handling, permission changes and version rollback, and define how customers raise disputes and accept results.
Roles need to change accordingly. Business staff own goals and acceptance; engineers own interfaces, execution and recovery; security staff review consequential permissions and data boundaries. One person may hold several roles, but important authorization and acceptance decisions cannot become ownerless because AI performs the work. Training, necessary independent review and role-transition costs also belong in the investment calculation.
Account for the full cost of delivery. Model calls and compute are only part of it: data preparation, integration, human review, monitoring, incidents, upgrades and customer support must also be paid for. Only comparison with measurable customer benefits can establish whether subscriptions, implementation fees or operating fees are sustainable.
Step 4. Expand across customers and use cases only when evidence supports it
Before scaling, separate shared capabilities from industry- or customer-specific configuration and identify permissions requiring individual authorization. Installation packages, skill versions, compatibility documentation, test examples, service documentation and rollback plans should become part of delivery.
Success with one customer does not establish success with different data, models or business systems. New customers and environments require revalidation of critical assumptions; the first successful case is not a universal conclusion.
Further investment should depend jointly on reuse, customer benefit, service costs and risk. Persistent dependence on extensive human intervention, insufficient benefits to cover costs, or unresolved consequential side effects are reasons not to force expansion merely to catch a policy window.
Software transformation therefore comes down to three questions: Does the customer receive a verifiable improvement? Can the company deliver it sustainably? Do human accountability and risk boundaries remain clear?
Figure 7. Establish a baseline, run a bounded pilot, and use evidence to justify ongoing service and broader reuse. Source: Author's enterprise transformation analysis informed by Document No. 209.
XIV. Five Common Misreadings
Misreading 1: The government will subsidize every AI software company
The plan discusses coordinated funding, first-version software policies and dedicated fiscal funds, but creates no universal subsidy entitlement. Specific support depends on later projects and local rules.
Misreading 2: Connecting a large model completes software transformation
The policy looks at development effectiveness, code quality, product upgrading, service value and real applications. Calling a model is an input, not an outcome.
Misreading 3: An agent is just a chat interface
The document also addresses execution frameworks, complex tasks, multi-agent collaboration, development and operating toolchains, system integration and behavior verification. Its scope goes well beyond chatbots.
Misreading 4: A Skills market is a place to sell prompts
Enterprise skills need versions, interfaces, dependencies, permissions, security, review and ongoing operations. Without these conditions, they are unlikely to enter critical business systems.
Misreading 5: The policy already supplies unified agent standards
The document initiates and advances standards development. Companies cannot present their own concepts as national standards or claim certification before such arrangements exist.
XV. The Opportunity: Software as a Continuously Working Organizational Capability
Traditional software helped people record information, execute commands and manage processes. Generative AI enabled software to understand natural language. Agents take it further: software can receive goals, use tools and complete successive tasks.
As those capabilities enter enterprises, purchasing decisions may change.
An enterprise may buy a digital capability that continually delivers results, rather than just another system account. It may add an intelligent working role to procurement, R&D, sales, customer service, compliance or operations, rather than simply installing a feature set.
This helps explain why Document No. 209 discusses software production, agent products, intelligent services and the organization of employment together. It addresses a reconfiguration of software, services and work.
Models provide intelligence, but do not automatically establish a job. Tools enable actions, but do not establish accountability. Workflows provide a route, but do not replace business judgment. A functioning digital employee system must organize models, tools, skills, identity, responsibilities, authorization, collaboration, verification and recovery into something that can operate over time.
Document No. 209 therefore opens more than a market for AI-written software.
It also opens a market in which software becomes agents, agents enter organizations, and organizations reconfigure their productive capacity.
Conclusion: Toward an Agent Software Industry
In 2025, the State Council's Opinion on Deepening the “AI Plus” Initiative established the national direction for integrating AI across the economy and society.
In 2026, policy has moved progressively into implementation.
Document No. 414 organizes application service providers and addresses who delivers. The entrepreneurship support plan cultivates AI SMEs and addresses who innovates. Document No. 209 transforms the software industry itself: how software is produced, how it runs continuously, how products and markets develop, and how behavior is verified and governed.
Across Document No. 414, the entrepreneurship support plan and Document No. 209, policy attention is extending beyond model capabilities to application delivery, entrepreneurs, software products, ongoing services and industrial infrastructure.
For software firms, this policy path calls attention to upgrading existing software and development methods, cultivating agent products and specialist Skills, and incorporating ongoing operations, behavior verification and workforce transitions into delivery capabilities. Whether these opportunities become viable businesses still has to be demonstrated through products, customers and operating results.
Document No. 209 thus advances the question:
Once agents truly become software, how does China intend to build an industry around them?
Main Sources
- Ministry of Industry and Information Technology: Notice Issuing the Implementation Plan for the “AI Plus Software” Special Action, Gong Xin Bu Xin Fa [2026] No. 209, published September 11, 2026.
- General Office of MIIT: Notice on the Special Action to Cultivate AI Application Service Providers, Gong Xin Ting Ke Han [2026] No. 414, published August 31, 2026.
- General Office of MIIT: Artificial Intelligence SME Entrepreneurship Support Plan (2026–2028), Gong Xin Ting Qi Ye [2026] No. 31, published September 4, 2026.
- State Council: Opinion on Deepening the “AI Plus” Initiative, Guo Fa [2025] No. 11.
- Digital Employee Workshop: MIIT Document No. 414 Explained: From Model Supply to Application Delivery.
- Digital Employee Workshop: MIIT's AI SME Entrepreneurship Support Plan Explained: An AI Startup Ecosystem Is Taking Shape.
- MIIT's Department of Information Technology Development: Seven Questions and an Infographic: Understanding the “AI Plus Software” Implementation Plan, published September 11, 2026; see questions 3 and 6 in particular.
Top comments (0)