Simular

Most automation depends on somebody having built an API. Where one exists, connecting two systems is ordinary engineering; where one does not, the work stays manual forever.

That covers an enormous amount of real work. Internal systems, legacy applications, vendor portals with no integration, government websites, anything behind a login that was designed for a person and nobody else.

Computer-use agents attack that directly by operating the interface instead. Simular's Sai clicks, types and reads the screen the way a person does — which is the most general form of automation and also the most fragile.

Simular And Sai, In Brief

• Sai operates a computer, clicking, typing and using interface elements the way a person does rather than through APIs.
• It runs on a private cloud desktop — isolated, secure and always on, per the site — not on your own machine.
• It can also use APIs, terminals and write code, so it is not limited to the graphical route when a better one exists.
• Agent S, S2 and S3 are the named research line behind the product.
• Operated by Simular Inc., with the site available in seven languages and workflow templates published.

What Can An Agent On A Virtual Desktop Reach?

Sai works on a private cloud-based virtual desktop, mimicking human interaction by clicking, typing and using interface elements, while also able to use APIs, terminals and write code.

The reach question is the interesting one, and the answer is genuinely broad: anything with a graphical interface. There is no integration to build, no API to request, and no vendor cooperation required — if a person can do it on a screen, the agent has a route.

That is a categorically different proposition from workflow automation. A conventional automation platform can only connect what has been connected; an agent operating a desktop can, in principle, use the vendor portal that has no API, the internal tool built in 2011, and the spreadsheet somebody emails monthly.

The ability to fall back to APIs, terminals and code is the detail that makes it practical rather than doctrinaire. Clicking through an interface is the slowest and least reliable way to do anything, and an agent that uses it only when nothing better exists is behaving sensibly.

The corresponding weakness is brittleness. Interfaces change, elements move, a modal appears, a page loads slowly, and the agent is left interpreting a screen that no longer matches what it expected. API-based automation fails loudly; GUI automation fails by doing something almost right.

The narrower alternative is browser-level automation. Bardeen gives up the desktop and gains reliability, which is a sensible trade when everything you need lives in tabs.

API automation can only connect what someone chose to connect. An agent operating a desktop can, in principle, use the internal tool nobody has touched since 2011.

Agent S3 And The Benchmark Question

Simular names Agent S, Agent S2 and Agent S3 as its agents, which is the naming convention of a research line rather than a product family.

That is worth noticing because computer-use agents are an active research area with published benchmarks, and a company iterating in public through numbered versions is usually one measuring itself against them.

Benchmarks in this field measure task completion on defined computer-use problems, and the scores have improved rapidly and remain well short of reliable. An agent completing most tasks is not the same as one you can leave alone.

The gap between benchmark and production is also wider here than in most AI applications. Benchmark tasks are self-contained; real ones involve your specific software, your data, your interruptions, and consequences when something goes wrong.

The practical implication is to evaluate on your own tasks rather than on any published figure. A number that says an agent completes a large share of standard tasks tells you nothing about whether it can complete yours, and yours is the only question.

Cloud Desktops Change The Security Conversation

Sai runs on a private, cloud-based virtual desktop that the site describes as isolated, secure and always on. That decision is worth thinking through carefully, because it cuts both ways.

The argument for it is containment. An agent that clicks things unsupervised on your actual machine has access to everything you do — your files, your sessions, your saved passwords — and a mistake there is a mistake in your real environment. An isolated desktop bounds the damage.

Always-on is the second argument, and it is why the cloud rather than a local sandbox. Work that runs while you sleep cannot depend on your laptop being open, and an agent that only operates when you are present is a strange kind of assistant.

The argument against is that credentials have to go somewhere. An agent logging into your systems needs the ability to log in, which means those credentials exist on infrastructure you do not control, in a session that persists.

That is not a reason to avoid it — it is a reason to scope it. Give an agent its own accounts rather than yours, with the narrowest permissions that let it do the task, and treat anything it can reach as something a mistake could affect. Delegated access with limited scope is the standard answer, and it applies here more sharply than usual.

This is also where the enterprise agent platforms diverge. Ema leads with certifications and governance precisely because the credential question is the objection procurement raises first.

• Give the agent its own accounts, never your personal credentials.
• Scope permissions to the narrowest set that completes the task.
• Start with tasks where a wrong result is visible and reversible.
• Check output rather than status — a GUI agent fails by doing something almost right.
• Re-verify after any interface change in the systems it uses.

Giving An Agent A Task You Can Check

The right first task for a computer-use agent is one where you can tell immediately whether it worked, and where being wrong costs nothing.

That rules out most of the tasks people want to start with, which is the point.

If the systems involved do have APIs, a scheduled workflow tool such as Kuse will be faster and considerably harder to break.

1. Pick a read-only task first — gathering information from a portal, not changing anything in it.
2. Create a dedicated account for the agent with the minimum permissions required.
3. Run the task three times and compare the results, since consistency matters more than any single success.
4. Only then try a task that writes, and choose one where a wrong entry is obvious and easy to reverse.
5. Check the actual output each time rather than whether the run reported success.
6. Re-test after any interface change in the systems involved, because that is when GUI automation silently breaks.

Where Computer-Use Agents Genuinely Belong

It is worth being specific about the tasks where this class of tool earns its keep, because the general framing oversells it.

The strongest case is repetitive work in a system with no API. Pulling a weekly report from a vendor portal, entering the same data into an internal tool, checking a status across several systems — mechanical, defined, and impossible to automate any other way.

The second is bridging systems nobody will integrate. Two applications that must exchange data, neither with an API, where the current solution is a person copying between them. That is an agent-shaped problem and there is no other answer to it.

The weakest case is anything requiring judgement about what should happen. An agent can execute a decision reliably enough; deciding is a different job, and a task where the right action depends on context the agent cannot see will fail in ways that look like success.

The task to avoid entirely is anything irreversible and unmonitored. An agent submitting forms, sending messages or moving money without a review step is a category of risk that is not worth the time saved, however good the demonstration looked.