ServiceNow wants AI to find, build and ship workflow fixes in one loop. Decide where people still sign off

Most enterprise automation starts after a person has already decided what to fix. Someone notices that invoice disputes take too long, writes a business case, gets a project funded, and a team builds the change months later. Whether the change worked is often checked once, if at all. ServiceNow’s announcement on October 6 pushes AI into the steps before and after the build: finding what to change, and measuring whether the change paid off.

What ServiceNow announced

ServiceNow launched AI Workflow Factory, which it says is generally available today, globally. It connects products that already existed separately into one loop:

• Process Mining identifies the business processes that need to change, tied to the KPIs of a business unit.
• Build Agent and Autonomous Engineer build the workflow improvement and handle quality control.
• App Engine runs the refined workflow at scale.
• AI Control Tower governs the workflows, decisions and agent actions across the loop.
• Action Fabric extends the same governed loop to third-party AI agents and tools.

Autonomous Engineer is the new piece. ServiceNow describes it as “unattended coding” that plans, builds and tests implementation work while developers keep control of critical decisions. It is Early Access, available on request, not generally available. Anything you read about the full loop running hands-free depends on a component most customers cannot switch on today.

The release was issued from Mumbai, with quotes from ServiceNow’s Amit Zavery and from Accenture and Infosys executives. It promises scaling “in days, not months.” No customer results are published, and the release carries the usual forward-looking caveats. Treat the speed claims as ServiceNow’s, not as evidence.

What actually changes: the project becomes a loop

1. Process data shows a KPI gap
2. Owner picks what to change
3. Agent builds and tests the change
4. Change approved for production
5. Workflow runs on App Engine
6. KPI measured against the baseline

• Find: Process data shows a KPI gap · Owner picks what to change
• Build: Agent builds and tests the change · Change approved for production
• Run and measure: Workflow runs on App Engine · KPI measured against the baseline

Platform or agent workHuman decision

The interesting part is not that an agent can write a workflow. Coding agents already do that in many tools. The interesting part is the closure: process telemetry selects the work, and outcome measurement checks it. Most automation programs never close that loop; they report delivery, not results. If ServiceNow’s loop really ties each change to a KPI baseline, it makes the improvement checkable, which is the condition for trusting anything an agent builds.

It also moves a familiar question to a new place. When an agent proposes and builds the next change by itself, the governance question stops being “is this agent safe?” and becomes “who is allowed to change a production business process, and on what evidence?”

Where people still need to sign off

Choosing the change. Process mining ranks opportunities by the KPIs you give it, and KPIs encode priorities. Faster dispute resolution may mean fewer checks. A named business owner should pick which opportunity becomes a change, and that choice should be recorded. Process mining is also only as good as its event logs: missing steps outside ServiceNow will make the wrong process look slow.

Promoting to production. An agent-built change is still a change. It belongs in the same path as human work: separate development, test and production instances, source control, automated tests, and an approver who is not the author. Segregation of duties does not care whether the author was a person or Autonomous Engineer. For U.S. public companies, workflows that touch financial reporting fall under SOX IT general controls, and an auditor will ask who approved the change and what testing supported it.

Judging the outcome. “The KPI moved” is not proof that the change moved it. Seasonality, volume and other changes interfere. Decide before deployment what improvement counts, over what period, and what triggers a rollback. Then give that decision to a person, not to the loop that built the change.

These gates map onto the ladder in our framework for earning agent autonomy: an agent can propose changes freely long before it is allowed to promote them.

Third-party agents in the same loop

Action Fabric is ServiceNow’s bid to govern agents it did not build. That is the right instinct; most enterprises already run agents on several platforms, as we noted in our analysis of control planes above vendors. But a governance layer is only as good as what it can see. The announcement does not say which identity, permission, cost and action records AI Control Tower receives from an outside agent. Ask for that in a demo, with one of your own non-ServiceNow agents, before you assume a single audit trail.

What to do now

1. Map your change path for agent-built work before enabling Autonomous Engineer: instances, tests, approvers and evidence.
2. Keep author and approver separate, and record which changes an agent authored.
3. Name an owner per KPI the loop optimizes, with the authority to say no.
4. Set outcome criteria before deployment, including a rollback trigger.
5. Audit process mining coverage: which steps of the process happen outside the platform and are invisible to it.
6. Test Action Fabric with one external agent and check what Control Tower actually records.

The bottom line

AI Workflow Factory reframes automation as a loop that finds, builds, ships and measures. The loop is valuable precisely because it can be checked. Keep three decisions human for now (what to change, what reaches production, and whether it worked), and let the evidence from each turn of the loop decide when the agent earns more.