ServiceNow's Project Arc Writes Its Own Workflow. The Runtime Just Became the Product.
At Knowledge 2026, with Jensen Huang on stage next to Bill McDermott, ServiceNow announced Project Arc — a long-running, self-evolving autonomous desktop agent that, in their own words, "thinks, writes code, executes, and adapts when things don't go as expected," completing multi-step work across enterprise tools without requiring pre-built workflows.
Sit with that last clause. The entire premise of enterprise automation for fifteen years was that a human designs the workflow and the machine runs it. Project Arc inverts it: you give it a goal, it figures out the steps, and it rewrites them when reality doesn't cooperate. And the thing that makes it shippable into a real company isn't the agent at all — it's where it runs. Every action executes inside NVIDIA OpenShell, an open-source sandboxed runtime with policy-based controls, while ServiceNow's AI Control Tower logs every file read, command executed, and API called.
The agent is the demo. The runtime is the product.
When the Agent Invents the Plan, Governance Moves to the Container
I lead a team that owns automation platforms, so let me be precise about what changed. RPA was a bot memorizing a human's clicks — brittle, because it never understood the task, it just replayed the keystrokes. The fix everyone's been selling is "agentic" automation: an agent that reasons about the goal instead of mimicking the motion. Fine. But reasoning about the goal means the agent decides what to do at runtime, and an autonomous thing that decides what to do on your desktop, against your enterprise systems, is a fundamentally scarier object than a dumb bot following a script you reviewed.
That's the problem OpenShell exists to solve, and it's why the announcement put the runtime in the spotlight instead of the model. When you can no longer pre-approve the workflow — because there isn't one, the agent invents it on the fly — the only place left to put your controls is around the execution. You can't review the plan in advance, so you govern the runtime: sandbox it, scope what it's allowed to touch, log everything it does, and keep a kill switch in reach. The locus of governance moved from the design-time artifact (the workflow you signed off on) to the run-time container (the sandbox the agent acts inside). That's a real architectural shift, and most automation buyers haven't internalized it yet.
This is also the enterprise's answer to the OpenClaw problem — the open-source computer-use agents that went viral, racked up six figures of GitHub stars, and promptly produced the year's first agent-security crisis with thousands of exposed instances. ServiceNow and NVIDIA are betting that what enterprises actually want isn't the most capable desktop agent. It's the one that comes wrapped in a governed runtime with an audit trail, so it can survive contact with a security review.
Three Things That Follow If You Own Automation
First, "no pre-built workflows" is a double-edged sell. The upside is enormous — the exception-heavy 50% of processes that RPA could never scale to are suddenly in play, because an agent can handle the case it's never seen. The downside is that you lose the artifact you used to audit. There is no flowchart to point the auditor at. Your evidence is now the runtime log, not the design doc. If your governance story depends on "here's the approved process diagram," that story just broke, and you need a new one built on execution telemetry.
Second, evaluate the runtime, not the agent. The interesting questions about Project Arc aren't "how smart is it" — they're "what's the OpenShell policy model, how granular is the scoping, what does AI Control Tower actually capture, and can I prove to a regulator what this thing was and wasn't allowed to do." The model will be obsolete in a year. The runtime governance is the part you're really buying, and it's the part that determines whether legal lets it past the pilot.
Third, watch the lock-in seam. OpenShell is open-source, which is a deliberate and smart move — but the Control Tower governance, the Action Fabric context, and the ServiceNow workflow estate it all plugs into are not. The runtime being open is what gets it in the door. The platform it reports to is what keeps you there.
Capability Is the Headline. Containment Is the Product.
Here's the pattern, and it's the one I keep coming back to with every agent launch: capability is the headline, but containment is the product. Everyone on stage wants to talk about the agent that thinks and writes code and adapts. The reason this one might actually ship into a Fortune 500 instead of dying in a security review is the unglamorous half — the sandbox, the policy engine, the immutable log of every command it ran.
We spent a decade learning that the hard part of automation was never making the bot act. It was making the bot act safely, observably, and revocably in an environment where a wrong move costs real money. RPA solved acting and punted on the rest, which is why it stayed brittle and supervised. Project Arc's bet is that the next era of automation is won by whoever owns the runtime the agent is forced to act inside — because when you can't review the plan anymore, the container is the control.
So when the next vendor shows you a desktop agent that "just figures it out," don't watch the agent. Watch where it runs, what it's allowed to touch, and whether you can prove after the fact exactly what it did. The smartest agent in a runtime you can't govern is a liability with great demo energy. A merely-good agent in a sandbox you control is something you can actually put your name on in front of an auditor. I know which one I'd rather own.
Sources: NVIDIA and ServiceNow Partner on New Autonomous AI Agents for Enterprises | NVIDIA Blog · ServiceNow extends agentic AI governance from desktops to data centers with NVIDIA | ServiceNow Newsroom · Project Arc: ServiceNow and Nvidia's Enterprise Desktop Agent | The Letter Two · ServiceNow and Nvidia Think They Have the Enterprise Answer to OpenClaw | The AI Economy