01
Reach
The work lives in desktop ERPs, terminal emulators, Bluebeam, Excel workbooks with macros, and PDFs on a shared drive. A cloud browser reaches none of those. A desktop reaches all of them, because a person already uses them there.
Desktop runtime
Local = on your machine.
Maximum security. Minimal cost.
LaunchAI agents run on your own machine: in the Chrome or Edge profile you already use, inside sessions you already opened, from your office network and IP address, with operating-system input at a person's pace.
- No headless browser
- No injected script
- No browser extension
To a portal, the agent's work arrives as your normal session, because it is your normal session.
Definition
What the desktop runtime is, and the problem it solves
The LaunchAI desktop runtime is the Runner on an enrolled Mac, Windows, or Linux machine. It executes approved workflows in that machine's own applications, browser profile, signed-in sessions, and network, using operating-system mouse and keyboard input at a person's pace.
Running an agent somewhere else creates three problems. The runtime is built to avoid all three.
02
Trust
Portals restrict sign-ins by network, remember devices, and challenge unfamiliar browsers. A session opened from your office on your browser already passed those checks.
03
Custody
Screens, documents, and evidence stay on a machine inside your network.
The one decision
Same seat, same session
Cloud agents run somewhere else: a rented server, a fresh browser, a borrowed address. LaunchAI's runtime makes the opposite choice on every point.
The agent works on an enrolled workstation, a dedicated agent PC, or a spare desktop, inside the applications someone opened this morning, already signed in, multi-factor included. For most workflows it never handles a password; the vault for the exceptions is described on the security page.
On the machine
How a run executes, step by step
The console side is covered in Run console. This is what happens on the desk.
-
Dispatch
The run console sends the run to its assigned machine once the readiness check passes.
-
Load the fence
The Runner loads the approved version and its fence: the applications, folders, and databases the workflow declared. It refuses anything else.
-
Bring the window forward
The ERP client, the browser tab in the existing profile, the spreadsheet.
-
Five moves per action
Capture, interpret, decide, act with real operating-system input, verify.
-
Right path per decision
Exact rules on the machine; judgment calls through your model account.
-
Write evidence locally
Screenshots and records go to the machine's own disk as the run goes.
-
Sync status
Run status, review outcomes, and fleet state sync to the Portal so the console and reviewers see progress.
-
Pause for review
The reviewer decides from the Portal or a phone; the run resumes on the chosen branch.
-
Next run or idle
The machine takes the next queued run or waits for the next schedule.
From the other side
What a portal sees
Defenses built to catch datacenter bots look for the opposite of every row below. They have nothing unusual to flag.
That is not a promise that a captcha or a multi-factor prompt will never appear. Portals change their rules, and some challenge every sign-in. When one appears, a person answers it and the agent carries on from the same screen.
| What the portal checks | What a LaunchAI agent presents |
|---|---|
| Source IP address | Your office's public address |
| Browser | Your installed Chrome or Edge, with its normal profile |
| Session | The cookies and sign-in you created, multi-factor already satisfied |
| Input | Operating-system mouse and keyboard events, at a person's pace |
| Automation control | None attached to the browser |
Setup
Setting it up
Five steps, most of them done once.
-
Choose the machine
A dedicated agent PC on the plant network shares the plant's public address with the buyer's workstation and leaves the buyer's seat free.
-
Sign in once
Open the portal in the Chrome profile the agent will use. Sign in and complete the multi-factor prompt.
-
Build in the Studio
Show and tell the workflow; the Studio validates each step.
-
Schedule it
For example 5:30 a.m. on weekdays, or run it on demand.
-
Add alerts
Get notified if something is missing, offline, or not runnable.
Identity
Sessions and browser profiles
The agent works in a standard Chrome or Edge profile. Chrome keeps each profile's bookmarks, history, passwords, and settings separate, which makes a profile the right unit for an agent's identity.
One profile per identity
On a dedicated agent PC, sign the profile in to exactly the portals its workflows use. Keep personal browsing out of it.
Keep the profile
Chrome erases a profile's bookmarks, history, passwords, and settings when it is removed. Removing an agent's profile signs it out of everything at once.
Session lifetimes
Portals end idle sessions on their own schedule. Start runs soon after someone refreshes the session; the run console's session check catches an expired one.
Multi-factor prompts
A person answers them. One-time codes are requested from a person at run time and never stored.
Whose account
Every system logs the agent's work under the session's account. Some teams give an agent PC its own named users; that costs a seat per application and must fit each portal's terms.
Unavoidable credentials
A portal that times out hourly, or a system opened cold overnight, can use the credential vault, described on LaunchAI security.
Placement
Where agents run: workstation, dedicated agent PC, or spare desktop
The agent drives the real mouse and keyboard, so it needs the screen to itself while it works. That shapes where agents run.
The owner's own workstation
during the hours they are away
- Best for
- Pilots, low volume, workflows that need the owner's own sessions
- Tradeoff
- Unavailable during the day; the machine must stay on and signed in overnight
A dedicated agent PC
on the office network, signed in to the same applications
- Best for
- Scheduled production, daytime runs, several workflows on one schedule
- Tradeoff
- Hardware, an application seat for each system, and a physically secure spot for a signed-in desktop
A spare desktop
left running overnight, results waiting at 7 a.m.
- Best for
- Extra capacity at month-end or quarter-end
- Tradeoff
- Same care for updates, sleep, and screen lock; it may be someone's daytime machine
Fleet
Enrolled machines: visible and revocable
- Only enrolled machines run agents. Each one is visible in the Portal, with the agents assigned to it.
- Revoke a machine and its agents stop.
- Inside each application, the agent holds exactly the rights of its session. It cannot approve what the signed-in user cannot approve.
Enrollment is deliberate. Tenants separate companies, divisions, or clients, and each machine serves the tenant it was enrolled into. Revocation is the emergency brake: a lost laptop, a replaced PC, or a machine that should no longer run agents is one action from inert. Sensitive actions can require step-up authentication. Offboarding the person who used a machine is covered on LaunchAI security.
Network
Network and IP considerations
The portal sees your public egress address, so where a machine sits on the network decides what it is allowed to reach.
The public address is shared
Behind the office router, every machine leaves through the same public egress address. The portal sees that, not the internal one.
Each site has its own
A portal that allows headquarters refuses an agent PC at a branch. Put the machine where the allowlist expects it.
Addresses change
A new provider or a failover to a backup line changes the public address, for the agent and for everyone in the building.
VPNs and proxies move it
A full-tunnel VPN exits at its gateway; a cloud proxy presents its own address. A split-tunnel laptop exits from wherever it sits.
Outbound traffic stays small
Beyond a person's work, the runtime syncs status with the Portal and makes model calls. Ask us for the destinations your firewall needs.
Test in a demo
Remote Desktop and Citrix considerations
Two arrangements come up, and both belong in a demo on your own systems before production.
The practical rule: check on agent PCs through the run console's live view instead of opening a Remote Desktop session to them. If IT must connect for maintenance, plan how the machine returns to a signed-in, visible desktop before the next run.
The Runner on a local machine operates a Remote Desktop or Citrix window
How the agent perceives such a window is covered on Vision Layer Interface. The runtime considerations are practical:
- Keep the remote window visible and maximized at a fixed size.
- Expect the remote host's idle timeout to bring up a sign-in prompt mid-run.
- Connecting from a high-DPI device to a low-DPI one changes the scale factor, so keep local display settings fixed.
The Runner runs inside a remote Windows session
For example, an agent PC that IT administers over Remote Desktop. Three behaviors matter:
- Minimizing the client switches the session into a mode that draws no windows, so GUI automation fails. Testing tools document a client-side registry value,
RemoteDesktop_SuppressWhenMinimized= 2, that keeps it drawing. - Closing or disconnecting the client locks the remote computer at the sign-in screen, and GUI automation fails against it.
- Update restarts: only active Remote Desktop sessions count as signed-in users. A disconnected session does not hold off a restart.
Displays
Multi-monitor and display considerations
The agent reads the screen, so a stable screen means fewer surprises. Six habits keep it that way.
Fix resolution and scale
Moving between monitors with different scale factors, docking, high/low-DPI Remote Desktop, or changing scale mid-run all rescale apps; ones that don't cope go blurry.
Desktop over laptop at night
Docking and undocking change the displays under a running application.
One display, maximized
Keep target applications on one display. Confirm your own multi-monitor layout in a demo.
Keep the theme stable
Light/dark switches change colors and contrast. Verify catches mismatches, but consistency avoids needless exceptions.
Monitor off is not locked
Check power settings anyway: many policies lock the session when the display sleeps.
Give windows room
A narrow window hides columns. The viewport ledger reads long tables without skipping rows, faster when more rows fit.
When things go wrong
Failure handling on the machine
Every failure stops at a flagged step with a screenshot, and waits for a person. Nothing is guessed past.
The detailed semantics of committed and uncommitted steps, including why stopping is not rolling back, are on Atomic AI agent workflows.
| Event | What happens | What a person does |
|---|---|---|
| Machine off, asleep, or signed out at run time | Readiness fails before any work; an alert names the machine | Wake or sign in the machine; start the run on demand |
| Power loss or restart mid-run | The interrupted step's outputs were never committed; the run resumes at that step | Confirm in the target system whether the last action committed before retrying |
| Session expired mid-run | The agent lands on a sign-in page; verify fails and the step flags | Sign in and hand the run back |
| Multi-factor prompt | The run waits for a person | Supply the code; it is never stored |
| Someone uses the mouse or keyboard | Input collides with the agent's; verify is likely to fail and flag the step | Leave the machine alone; give the agent its own seat |
| Portal refuses the address | The agent sees the refusal page, as a person would | Call the portal owner; check for a changed public address |
| Target app run as administrator | Windows blocks the input; verify fails | Run the application at the same level as the runtime |
| Portal or application redesign | The expected change never appears; the step flags with a screenshot | Re-show the step in the Studio, or retrain the application map |
Governance
Governance and security on the runtime
Running inside live sessions on a real desk means the desk itself is part of the security model. Four rules cover it.
Fenced
Each workflow runs only against the applications, folders, and databases it declared. On a shared workstation, the fence keeps one team's agent out of another team's systems.
Evidence on local disk
Screenshots inherit the machine's endpoint protection, disk encryption, and backups. Turn on full-disk encryption and back agent PCs up like other financial records.
Physical access
A signed-in desktop that does not lock is open to anyone at the keyboard. Put agent PCs where passers-by cannot reach them.
Portal terms
The agent acts as the signed-in person; each portal's terms still apply.
For security reviews
Where the data goes
One precision for security reviews. The agent executes on your machine, but a model-path step sends the screen region it is reading to the model account you configure. Exact-rule steps send nothing to any model.
The full data-flow table, flow by flow, is on the security page.
Metrics
What to measure on the runtime
Six numbers tell you whether the machines are healthy and whether the fleet is the right size.
| Measure | What it shows | Action when it rises |
|---|---|---|
| Readiness failures per machine per month, by cause | Machine care: power, updates, sign-in | Fix update, sleep, and lock settings on that machine |
| Run-window use per machine | Share of the window spent running | Above about three quarters, add a machine |
| Queue wait | Runs waiting for a busy machine | Move workflows or add a machine |
| Session interruptions per workflow | Expired sessions and sign-in prompts mid-run | Refresh sessions closer to the run, or use the vault |
| Multi-factor prompts per week | Person-minutes the portals demand | Ask portal owners about device trust or network rules |
| Address refusals | Portals rejecting the machine's address | Check failover lines and allowlists |
Honest
Tradeoffs, stated plainly
Machines are hardware
Someone patches them, powers them, and replaces them; a dedicated agent PC is one more asset on IT's list.
Capacity lives on desks
Hosted browser agents and cloud VM pools add capacity on demand and may cost less for bursty public-web jobs. LaunchAI runs that work on enrolled machines, plus the desktop apps, office address, and open sessions those tools lack.
Human pace
OS input at a person's pace is slower per step than an API call. The runtime trades speed for reach, and for looking like the person the portal already trusts.
Ecosystem
How the desktop runtime connects to the rest of LaunchAI
- Run consoleSchedules runs onto machines, checks readiness, and sizes the fleet.
- Vision Layer InterfaceHow the agent sees and acts inside the machine's windows.
- Human reviewHanding a run to a person for a code or a sign-in, and taking it back.
- Audit trailWhat the machine writes to its disk and how it exports.
- LaunchAI securityThe vault, permissions, tenants, and data flows.
FAQ
Questions
Is LaunchAI a browser extension?
No. It is a desktop application, and it operates every window on the machine, not only the browser: ERP clients, Excel, PDF viewers, terminal emulators, and anything else a person can click.
Can I keep using the computer while an agent runs on it?
Not on the same screen at the same moment, because the agent is using the real mouse and keyboard. Give it a second machine, or schedule its runs for hours when the seat is empty.
Will an agent on a laptop work away from the office?
It works from whatever network the laptop is on. A portal that allowlists office IPs will refuse it off-site, exactly as it would refuse you. Run those workflows on a machine that stays in the office.
How do we move an agent to a new PC?
Enroll the new machine, install and sign in to the applications, set up the browser profile, and assign the workflows. Run each once on demand while someone watches. Then revoke the old machine, after exporting or archiving the evidence on its disk.
Can one agent PC serve several teams?
Yes. Assign several teams' workflows to it and give each a different window. Each workflow stays fenced to its own declared applications. Size the machine with the capacity arithmetic on the run console page.
No prompts. No babysitting. No dumb questions.