Lightcone vs. RPA

If you run UiPath or Automation Anywhere today, the natural question is: “Is Lightcone another RPA tool, or something that plugs into the one I have?” It’s neither. Lightcone is a different approach to the same problem (automating work in GUIs), built on a computer-use model instead of recorded steps and selectors. This page explains the difference concretely, and where RPA is still the better fit.

The maintenance problem

RPA bots target the UI through selectors: element IDs, accessibility trees, anchor rules, image templates. That works until the application changes. A vendor pushes an update, a button moves, a field gets renamed, and the bot stops mid-flow. The team that owns the bot goes back in, finds the broken selector, re-records or re-anchors it, redeploys, and waits for the next breakage. For most RPA teams, this maintenance loop is the dominant cost of the program, more than building the bots in the first place.

This is structural, not a flaw in any one RPA product. A selector encodes an assumption about the application’s internals, and applications don’t promise to keep those stable.

Northstar, Lightcone’s computer-use model, doesn’t use selectors. It looks at the screen the way a person does: pixels in, actions out. When the button moves, it finds the button. When a field is renamed from “Client” to “Customer”, it reads the label and fills it in anyway. There is no selector repository to maintain, because there are no selectors.

Describe the task, don’t record the steps

An RPA bot is a recording: a fixed sequence of steps, each bound to a specific element. Lightcone takes an instruction:

Before (selector script, pseudocode):

click("#nav-contacts")
click("#btn-new-contact")
setText("#input-first-name", "Jane")
setText("#input-last-name", "Smith")
setText("#input-email", "jane.smith@acme.com")
click("#btn-save")
waitForElement("#toast-success")

Every line is a dependency on the application’s current DOM. Any one of them can break the whole flow.

After (Lightcone):

from tzafon import Lightcone

client = Lightcone()

for event in client.agent.tasks.start_stream(
    instruction=(
        "Go to https://crm.example.com and navigate to Contacts > New Contact. "
        "Fill in: First Name 'Jane', Last Name 'Smith', Email 'jane.smith@acme.com'. "
        "Click Save and verify the contact was created."
    ),
    kind="browser",
    max_steps=20,
):
    print(event)

import Lightcone from "@tzafon/lightcone";

const client = new Lightcone();

const stream = await client.agent.tasks.startStream({
  instruction:
    "Go to https://crm.example.com and navigate to Contacts > New Contact. " +
    "Fill in: First Name 'Jane', Last Name 'Smith', Email 'jane.smith@acme.com'. " +
    "Click Save and verify the contact was created.",
  kind: "browser",
  max_steps: 20,
});

for await (const event of stream) {
  console.log(event);
}

The instruction describes the outcome, not the click path. If the CRM redesigns its contact form next quarter, the instruction still holds, and Northstar reads the new layout and adapts. That’s the difference between maintaining a script and maintaining a sentence.

Citrix and virtual desktops

A large share of enterprise work happens through Citrix, VDI, or remote desktop sessions. Inside those, the automation tool sees only a bitmap, with no DOM, no accessibility tree, nothing to attach a selector to. RPA vendors handle this with image matching and OCR, which is the most fragile mode they have: a font change, a resolution change, or a theme change breaks the template.

For Northstar, a Citrix session is the same as any other screen. Pixels are its native input. It reads the remote application visually and operates it the same way it operates a local one. If your hardest automations are the ones running inside a virtual desktop, this is likely the single biggest practical difference.

Side by side

	RPA (UiPath, Automation Anywhere)	Lightcone
How it targets the UI	Selectors, anchors, image templates bound to specific elements	Vision model reads the screen and locates elements each run
What breaks it	Any UI change that invalidates a selector	Fundamental workflow changes; model variance can still cause occasional misreads (catch them with verification)
Maintenance model	Ongoing: find broken selectors, re-record, redeploy	Update the instruction when the task changes; invest in verification and evals rather than selector upkeep
Virtual desktops / Citrix	Image matching and OCR, a fragile fallback	Native; pixels are the primary input
Setup time	Days to weeks per workflow in a visual builder	Minutes: write the instruction, run it
Licensing model	Per-bot / per-seat annual licenses plus orchestrator infrastructure	Usage-based API pricing; pay for what runs

When RPA is still the right tool

Be honest about the trade-off. RPA executes a fixed script deterministically: the same clicks, in the same order, every time, with per-step latencies in the milliseconds. A model-driven agent looks at the screen and decides each step, which costs seconds per action and introduces model judgment into the loop. That judgment is a real cost you take on in exchange for resilience: run-to-run variance, higher per-step latency, and the need to verify outcomes, track quality with evals, and handle authentication yourself for gated apps. Screen-reading trades selector maintenance for output validation. It moves the engineering, it does not remove it.

If you have a high-volume flow that is genuinely fixed, where the UI never changes, the steps never branch, and you need thousands of sub-second executions a day, a well-built RPA bot (or better, an API integration) will beat an agent on unit cost and latency. Lightcone earns its keep where RPA struggles: workflows that change, applications you don’t control, virtual desktops, conditional logic, and the long tail of processes that were never worth the RPA build cost in the first place.

The two can also coexist: many teams keep RPA on their stable high-volume flows and use Lightcone for the brittle ones they’re tired of repairing.

A good migration heuristic: sort your bot inventory by maintenance hours per month. The top of that list, the bots that break most often, are the ones where a screen-reading model pays for itself fastest.

Next steps

• Quickstart: run your first task in under 5 minutes
• Tasks: configuration, streaming, and writing effective instructions
• Legacy software automation: operate SAP, Salesforce Classic, and internal tools through the GUI
• Migrating to Lightcone: coming from script-based automation