Agentic OS vs RPA.

The session

Agentic OS vs RPA.

The difference between Agentic OS and RPA is the difference between a system that decides and a system that clicks. RPA executes a script. Agentic OS reasons about the script, writes it, runs it, and rewrites it when the world changes. That single distinction is the entire reason one category has been a $50B enterprise software market for two decades and the other is reshaping how every operator thinks about automation in 2026.

RPA came out of the screen-scraping era. A human watched a person do a task, recorded the clicks, and turned the recording into a script. The script ran. The script broke when the UI changed. The script had no idea what it was doing. It had no model of the work — it had a recording. That is RPA. It is brittle, and the brittleness is in the architecture, not the implementation.

Agentic OS is built around a different premise. The agent has a goal, a toolset, and a memory. Given the goal, the agent plans the steps, calls the tools, observes the result, and replans if the result does not match. The system can be told the goal in natural language and can be left to figure out the steps. The toolset is defined explicitly (no screen-scraping), the memory is auditable, and the agent can be told to escalate to a human at any point.

In production, this difference shows up as three concrete things. First, maintenance cost: an RPA bot that breaks because the vendor changed a login screen is a two-week fix. An agent that fails because an API returned a 502 is a five-minute fix. Second, scope: an RPA bot does one task. An agent does a category of tasks and can be re-tasked with a one-line prompt. Third, audit: RPA logs clicks. An agent logs the goal, the plan, the tool calls, the responses, and the decision to escalate. The audit trail is the difference between "we think it worked" and "we can prove it worked."

The migration path from RPA to agents is not what most vendors tell you. Most RPA vendors are now selling "agentic RPA" — a wrapper around the same screen-scraping bot with an LLM in front. That does not work. The agent needs structured tools (APIs, MCP servers, internal SDKs), not pixels. The migration is to identify the underlying intent of the RPA flow, then build (or buy) the tools the agent would need, then point the agent at the tools. The RPA goes away. The screen-scraping goes away. The audit trail gets better.

If you are running RPA today, the right question is not "how do I add AI to my RPA." It is "which of my RPA flows are actually doing structured work that could be done by an API call, and which are doing unstructured work that genuinely needs a human or a vision model?" The first category is a candidate for replacement by an agent. The second category is a candidate for replacement by a vision agent. Either way, the RPA bot is the wrong shape for the work.

The economic case is harder to ignore. A typical enterprise RPA bot costs $8K-15K to build, $3K-5K/year to maintain, and breaks 3-5 times per year. An agent on the Netwit runtime costs a fraction of that, has a structured audit trail, and can be re-tasked without re-recording. The 5-year TCO is roughly 70% lower for the agent on a like-for-like flow. The cases where RPA is the right answer are now narrow: legacy systems with no API, regulated environments with strict deterministic-execution rules, and screen-based work where the human-in-the-loop is the point.

This session walks through the architectural difference, the unit economics, the migration playbook, and a live demo of an agent replacing an RPA flow in real time. Q&A from the audience. Recording sent to all registrants.