How many phases does an Agent deployment usually have?

Public practice uses five: requirement analysis and scenario selection; data access and definition registration; build and go-live; trial-to-routine transition; and operations and iteration. The first two decide whether the project is feasible, the last three whether it survives; the bulk of the schedule is rarely in development.

What should the first two phases deliver?

Phase one delivers a scenario list, a confirmed data-access route and the schedule and acceptance terms. Phase two delivers the definition register, verification records for the data path, and the first version of metrics and alert definitions. All four are inspectable documents and the basis for acceptance later.

How long should the trial period run?

Public practice is four to six weeks: run in parallel for a period, comparing system figures against manual counts day by day, investigating definitions first and data access second where gaps exceed the agreed range. Move to routine only once the gap stabilises. Projects that skip this comparison carry the problems into year two, where responsibility is harder to pin down.

What counts as go-live?

Three conditions together: the data path runs steadily with alerts on failure; the definition register is confirmed by the company; and the trial-period gap has narrowed to the agreed range. Only then discuss expansion. Declaring go-live with any of the three unmet guarantees rework.

Manufacturing

An agent deployment plan: the full process from requirement to go-live

Updated 2026-10-17All figures from public sources

Whether an agent deployment succeeds is largely settled in the first two phases: requirement analysis with scenario selection, and data access with definition registration. Get those right and build and go-live become routine; skip them and the trial period turns into repeated rework. This article breaks the process into the five phases common in public projects, with what each one does, what it produces and what the client must provide.

The five phases of an agent deployment

Phase	What happens	Outputs	Client input	Reference duration
1. Requirements and scenario selection	Inventory systems and data, list candidate scenarios, rank by countable value	Scenario list, confirmed data-access route, schedule and acceptance terms	Named counterpart, system inventory	1–2 weeks
2. Data access and definitions	Open the data path, verify fields, register each metric with its definition and owner	Definition register, access verification records, first metric and alert definitions	IT or vendor approval for read-only access	2–4 weeks
3. Build and go-live	Implement metrics, alerts and presentation to the agreed definitions; integrate and deploy	Running environment, metric and alert configuration, usage notes	Confirm definition changes, name the acceptance owner	2–3 weeks
4. Trial to routine	Run in parallel with manual counting, close the gap, handle exceptions	Variance log, issue list, routine-operation confirmation	Business staff comparing daily	4–6 weeks
5. Operations and iteration	Register definition changes, extend metrics, fault response and version updates	Change log, monthly operation records	Named operations contact	Ongoing

Overall, public projects run from survey to routine operation in roughly two months. The variable is not development but how quickly data access is approved and definitions are settled.

The confirmation step at the end of each phase

What keeps a process moving is a confirmation at the end of each phase. Without it, rework is nearly certain. Put it in the plan:

End of phase 1: the company confirms the scenario list and data-access route, and states what is out of scope.
End of phase 2: the company confirms the definition register and names an owner per metric.
End of phase 3: the company names the acceptance owner and confirms the data range and method used for acceptance.
End of phase 4: the gap narrows to the agreed range and routine operation is confirmed in writing.

Three roles an agent deployment plan must name

A plan must name three roles: who signs off definitions, who grants data access, and who owns day-to-day operation. The common arrangement: business definitions are signed off by the business owner, data access is approved by IT or the system administrator, and a named contact owns routine operation, while the vendor handles build, configuration and technical support. Name all three and every phase confirmation has someone to go to. If a plan says only that the vendor takes care of everything, ask who is on duty during operation, how fast faults are answered, and whether response times are in the contract.

Three places projects stall

Permissions for data access. Usually vendor reluctance, or concern about the production database. The common fix is to state three things in the plan: read-only access, no write-back to business databases, no control of production equipment.
Nobody can settle definitions. The vendor can only point out inconsistencies; unifying them is the company's call. Naming one decision-capable counterpart is the single most valuable preparation.
No owner for operations. Models update, interfaces change, hardware fails. Name the responsible party in the plan. Projects that end at delivery typically stop in year two.

Development is often not the largest part

In many scenarios the largest effort is not development. Getting one business metric right involves the data path, field meaning, definition alignment and presentation; the code is one link in that chain. When assessing a plan, ask more about how the data is retrieved and who defines the number, and less about which model is used.

If a plan cannot name the tables and fields its data comes from, send it back for that section first. On data-access options, see our enterprise AI agent deployment page; if you want to confirm which scenario should go first, send us your site conditions and system inventory for a free assessment (custom delivery and contact).

Three boundaries worth stating in the plan

Boundary	What to state
System	No modification or replacement of existing systems; read-only access, no write-back to business databases, no control of production equipment
Operations on site	No new forms or scanning steps for frontline staff; the only inputs are a named counterpart and the necessary permissions
Data	Where data goes, who may access it, the network path, audit trails, ownership and exit arrangements

In one line: take the first two phases slowly and the confirmations seriously, and build and go-live will move faster. The hard part of an agent deployment is data access and definitions, not code.

Compiled from common public implementation practice: the Action Plan on "AI + Manufacturing" issued in December 2025 by the Ministry of Industry and Information Technology and seven other departments, on maturity assessment and industry application maps. Phasing, confirmation steps and data-access routes summarise public practice and state no specific contract terms. Durations are typical public ranges; actual projects follow their contracts.

FAQ

How many phases does an Agent deployment usually have?: Public practice uses five: requirement analysis and scenario selection; data access and definition registration; build and go-live; trial-to-routine transition; and operations and iteration. The first two decide whether the project is feasible, the last three whether it survives; the bulk of the schedule is rarely in development.
What should the first two phases deliver?: Phase one delivers a scenario list, a confirmed data-access route and the schedule and acceptance terms. Phase two delivers the definition register, verification records for the data path, and the first version of metrics and alert definitions. All four are inspectable documents and the basis for acceptance later.
How long should the trial period run?: Public practice is four to six weeks: run in parallel for a period, comparing system figures against manual counts day by day, investigating definitions first and data access second where gaps exceed the agreed range. Move to routine only once the gap stabilises. Projects that skip this comparison carry the problems into year two, where responsibility is harder to pin down.
What counts as go-live?: Three conditions together: the data path runs steadily with alerts on failure; the definition register is confirmed by the company; and the trial-period gap has narrowed to the agreed range. Only then discuss expansion. Declaring go-live with any of the three unmet guarantees rework.