Live view
The screen the agent is working on, as it works.
Run console
Schedule, inspect, and trigger agents.
Where agents live after being built.
The run console starts runs on a schedule, on demand, or from a trigger. It checks readiness before every run, shows live status and the agent's screen, and lets the process owner pause, abort, retry from the failed step, or change one rule, branch, or action without rebuilding the agent. It also shows every enrolled machine in the fleet and counts the hours each workflow returns.
The problem it solves
Agents rarely fail in the demo. They fail in month three.
Definition. The LaunchAI run console is the operations layer for published agents: it decides when each run starts, confirms the run can succeed before it touches a system, shows what every agent is doing, alerts a person when something needs one, and applies changes one part at a time.
The failures are dull. The agent PC restarted for updates and nobody signed back in. The input file never arrived. A utility portal moved its sign-in button. A threshold changed in policy and nobody changed it in the agent. Each is small. Unwatched, each becomes a missed payment run, a late report, or a morning spent redoing work by hand.
The run console exists so that none of those failures is silent. Its views are shared through the Portal, so a controller, an operations lead, and an IT administrator see the same state.
Five questions it answers at any hour
- 01 What is scheduled, and on which machine?
- 02 Will the next run be able to start?
- 03 What is running now, and what is waiting on a person?
- 04 What went wrong, where, and with what evidence?
- 05 What has this agent returned in hours, by workflow and month?
Lifecycle
How a run moves through the console
Every run follows the same path from start signal to finished record.
-
A start signal arrives
A schedule fires, a person presses Run, or a trigger detects new work.
-
Inputs are checked
Against their declared types.
-
The readiness check runs
-
Queued for its machine
A machine works one screen at a time, so runs assigned to the same machine wait their turn.
-
Running
The status turns to Running, and the live view shows the agent's screen.
-
Waiting on review
At a human review step the run pauses and the reviewer is notified until a person decides.
-
Finished
Clean, or with exceptions, every flagged item tied to its step and screenshot.
-
Alerts fire
On the conditions you set.
-
Joins the history
Every step opens into its audit trail evidence, and its hours count toward the workflow's total.
Three doors, one run
Starting a run: schedules, on demand, and triggers
On a schedule
Weekdays at six, hourly, the first of the month, each in the time zone you set.
On demand
When a rush job lands at 3 p.m.
On a trigger
A file arriving in a watched folder, an email arriving, or a row added to a table. Triggers are part of the product design; confirm which ones your deployment has during a demo.
Inputs are typed and validated before anything starts. A date range must be two dates in the right order. A bad input never becomes a bad run.
Schedules
Time zones, and the two nights a year that break them
Each schedule carries its own time zone, so a 6 a.m. run for a Phoenix property and a 6 a.m. run for a Chicago plant each fire at 6 a.m. local. Arizona (outside the Navajo Nation) and Hawaii do not observe daylight saving time; the rest of the country does, and that creates two edge cases a year.
Sun · Nov 1, 2026
Clocks fall back at 2 a.m.
Local times from 1:00 to 1:59 a.m. happen twice.
Sun · Mar 14, 2027
Clocks spring forward at 2 a.m.
Local times from 2:00 to 2:59 a.m. never happen.
Federal law sets both changes. A bill to make daylight saving time permanent passed the House on July 14, 2026 and, as of late September 2026, sat in a Senate committee; until it becomes law, the clocks still change.
If a run must sit there, confirm during a demo how the scheduler resolves a repeated or missing hour.
Calendars need the same care. "The first of the month" can fall on a Saturday or a bank holiday. When a run depends on a business day, add a decision step at the top of the workflow that checks the date against a holiday table in Rules and Tables. The rule is exact, the table is owned by the business, and nobody has to remember Labor Day.
Triggers
The work arrives, the agent starts
A trigger that fires twice for the same work should not produce two postings. Treat business keys, such as a vendor invoice number the ERP rejects as a duplicate, as the backstop.
| Trigger | Typical source | Design note |
|---|---|---|
| File in a watched folder | An ERP report scheduled to export nightly; a scanner's output folder | Have the sender write the file somewhere else and move it in when complete, so a half-written file is never picked up |
| Email arriving | A vendor invoice to the AP inbox; a portal's notification | Keep one mailbox or folder per workflow, so a trigger never starts the wrong agent |
| Row added to a table | A clerk logs a rush request; another agent writes a result | The row's typed columns become the run's inputs, validated like any other input |
| Webhook | n8n, Make, or any system that can send an HTTP request | Covered in the coexistence section below |
Before every run
The readiness check
Some runs fail for boring reasons before they do any work. The readiness check catches those before the run starts.
Take a run scheduled for 6 a.m. on an agent PC that restarted for updates at 2 a.m. and never signed back in. It fails the check at 6:00 and never touches the ERP. A failed check fires the alerts you configured, so the problem reaches a person while there is still time to fix it.
Readiness is not a promise that the run will succeed. It removes the failures that were avoidable before the first click.
| Check | What fails it | Result |
|---|---|---|
| Workflow approved | A draft, or a version still pending approval | The run does not start |
| Machine enrolled and reachable | The agent PC is off, asleep, disconnected, or revoked | The run does not start |
| Inputs present and typed | A missing file, a blank date, text where a number belongs | The run does not start |
Blind spots
What readiness does not see, and how to cover it
The check looks at the workflow, the machine, and the inputs. It cannot know whether a portal is down or whether an ERP session timed out overnight. Those surface inside the run, at the step where the screen did not match, with a screenshot of what the agent found.
One design habit closes most of the gap: make the first step of each workflow a session check that confirms the application is open and signed in, and routes to a person if it is not.
Watching agents work
The status model
Every run carries one of five states.
A run that fails its readiness check never enters the queue. A run a person pauses or aborts keeps its record, and the record shows exactly where it stopped.
A run that finishes with exceptions has completed everything it could verify. Each exception names its step and carries the screenshot the agent saw, so whoever picks it up starts from evidence.
- Queued
Accepted and waiting for its machine
Asks of a personNothing, unless it waits past its window
- Running
Working now
Asks of a personNothing; the live view is there if you want it
- Waiting on review
Paused at a human review step
Asks of a personThe assigned reviewer decides; long waits escalate
- Finished clean
Every step completed and verified
Asks of a personNothing
- Finished with exceptions
Done, with items flagged for a person
Asks of a personWork the exceptions from their screenshots
Beyond status
Run history
As far back as you keep it, with the same drill-down as the audit trail.
Per workflow
Runs, success rate, exceptions, pending reviews, and hours returned.
Alerts
By Portal, email, or chat, on the criteria you set: any exception on a payment workflow, or three failed runs in a row on a report.
Alerting
Alerts a person can act on
"Every page should be actionable."
Google Site Reliability Engineering
An alert that nobody can act on trains people to ignore the next one. Design each alert around a person and a first move.
Keep the routing narrow. Reviewers already get notified by the review queue; do not page them twice. A person who receives an alert should own the first move.
| Condition (example) | Channel | Who | First move |
|---|---|---|---|
| Readiness failed: machine unreachable | Chat | IT, or whoever looks after agent PCs | Wake or sign in the machine; start the run on demand |
| Readiness failed: input missing | Workflow owner | Find the missing file; start the run on demand | |
| Any exception on a payment workflow | Chat and email | AP lead | Open the exception and its screenshot |
| Three failed runs in a row on a report | Process owner | Check the failing step for a changed screen | |
| Review waiting past its limit | The review queue's own escalation | Reviewer's backup | Take the review |
| Run still queued past its window | Chat | Operations lead | Move the workflow to a free machine |
Runbooks
The first ten minutes after an alert
Each alert class has a short, standard response. Write yours down; these are a starting set.
When a runbook does not cover it, open the Support panel inside the product. A person answers, and you can reference the exact run and step, share your screen, or record it with one click.
- 1
Machine not ready
Confirm in the fleet view whether the machine is off, asleep, signed out, or revoked. Fix the cause, then start the run on demand. If it was an update restart, fix that machine's update policy so it does not recur.
- 2
A step failed on a changed screen
Open the exception's screenshot. If the application changed, the process owner re-shows that one step in the Studio, the new version is approved, and the run retries from the failed step.
- 3
Bad input data
Correct the data at its source, such as the table row or the file, then retry from the failed step.
- 4
Portal down
Pause the run and resume when the portal returns. If the outage runs past a deadline, tell whoever depends on the output.
- 5
A posting may have been committed
Check the ERP for the document before retrying. Retry only when the record shows the posting did not happen, or the target system rejects duplicates by a business key.
- 6
Session expired or one-time code
A person signs in or supplies the code, then hands the run back. Codes are never stored.
- 7
Wrong values posted
Abort the run, correct the posted documents in the ERP through your normal approval, then trace the cause through the value's lineage in the audit trail before the next run.
Controls
Controlling a run
Pause during a portal's maintenance window. Resume after.
Abort a run that has gone sideways. The agent stops clean and records where it was. Aborting is not undoing: anything already posted in the ERP stays posted, and the record shows exactly what (see Atomic workflows).
Retry from the failed step once the data is fixed.
Archive or delete what is no longer needed.
Treat deletion as a records decision, not housekeeping. Before deleting runs, check the workflow's retention setting and any hold on its evidence.
Surgical change
Changing an agent without rebuilding it
Because an agent is small steps, readable rules, and tables, a change is surgical.
Each change takes effect on the next run, is versioned, and can be reversed. If Tuesday's rule change misfires on Wednesday, restoring Monday's version is one action, and the history shows who changed what.
The person who owns the process usually makes the change, by re-showing the step that moved. When a state portal redesigns a form, a recorded RPA selector breaks and a ticket goes to IT. Here, the process owner opens the Studio, shows the new screen once, and the step is re-validated. The rest of the chain is untouched.
Change management
From request to next run
-
Something prompts a change
An exception pattern, a policy memo, a vendor release, a new client.
-
The owner makes the edit
In the Studio for steps and branches, in Rules and Tables for thresholds and mappings. The Copilot can propose the edit and show the difference before it is applied.
-
Validated live
The changed step is validated on the real application. Validation touches live systems; it is not a sandbox.
-
Approved
Draft → pending approval → approved by someone with approve-for-production permission. An approved version is read-only.
-
The next run uses it
The readiness check refuses any version that is not approved, so a half-finished edit cannot run on schedule.
-
Misfire? Restore
Restore the previous version.
The fleet
Machines, assignments, and parallel runs
Every enrolled machine appears in the console with the agents assigned to it, and agents on different machines run in parallel. How machines are enrolled, and why the agent works from a person's seat, is covered in Desktop runtime.
The fleet view answers the capacity questions: which machines are enrolled, which workflows each runs and when, which are idle and which are queued. Because the agent drives the real mouse and keyboard, one machine works one run at a time, and parallel capacity is the number of machines.
Capacity planning
Fleet sizing is arithmetic
Time the first supervised runs, then plan.
-
Measure
For each workflow: minutes per item and fixed minutes per run (opening applications, signing in, loading a report).
-
Hours needed
Sum over workflows of (items × minutes per item + fixed minutes) ÷ 60.
-
Hours available
The run window in hours × the number of machines.
-
Keep headroom
Use no more than about three quarters. Retries, exceptions, and runs paused at review eat the rest.
-
Size for the peak
Month-end, quarter-end, and renewal season are when the queue backs up.
needed = Σ (items × min/item + fixed min) ÷ 60 ≤ ¾ × window h × machines
Speed is a tradeoff, not a ceiling. The Vision Layer Interface is slower per step than an API call because it looks, acts, and verifies every time; it wins on reach. When a nightly volume outgrows a machine, add a machine, split the work by folder, vendor range, or property, and let the runs proceed in parallel.
Worked example · every number is an illustration
One night on a three-machine fleet
A property management company runs four workflows on three enrolled machines. This example is about running them.
| Machine | Available | Assigned workflows |
|---|---|---|
| A: the AP clerk's workstation | 6:00 p.m. to 7:00 a.m. on weekdays | Vendor invoice intake and posting |
| B: a dedicated agent PC | Around the clock | Bank activity download and reconciliation prep; daytime rush requests |
| C: a spare desktop at the regional office | 7:00 p.m. to 7:00 a.m. | Utility bill download and posting from nine utility portals |
Wednesday, October 28, 2026
-
Invoices start on A
Passes readiness; 180 invoices from the watched folder. At about 2.5 minutes each, 7.5 hours of work.
-
Utilities start on C
Eight portals finish. Portal seven moved its sign-in button; the verify move fails, the step flags with a screenshot. Finished with exceptions at 11:52.
-
Invoices finish with exceptions
173 posted, 7 flagged: 4 suspected duplicates, 2 with no matching purchase order, 1 unreadable scan.
-
Machine B restarts for updates
It comes back to the Windows sign-in screen.
-
Bank run fails readiness
Machine B is unreachable. The run does not start. The alert reaches IT's chat and the controller's email.
-
Recovered
IT signs in to Machine B. At 6:45 the controller starts the bank run on demand. It finishes clean at 7:35.
-
Exceptions worked
The AP clerk works the seven invoice exceptions from their screenshots, starting with the duplicates.
-
One step re-shown
The utilities coordinator re-shows portal seven's sign-in step. 9:25 approved; 9:30 the run retries from the failed step and the bills post.
-
One setting fixed
IT changes Machine B's update settings so restarts can no longer land in the run window.
Peak load
The capacity check for month-end
At month-end the invoice folder holds 300 items, not 180. At 2.5 minutes each that is 12.5 hours: starting at 6:15 p.m., the run would end at 6:45 a.m., fifteen minutes before the clerk needs the machine back, with no room for a single retry.
The fix is a second watched folder assigned to Machine B, which is idle outside its 5:00 a.m. bank run. Each machine takes 150 invoices, about 6.25 hours, and both finish before 1:00 a.m.
Cost
High-volume work, and what it costs per transaction
LaunchAI runs high-volume work across enrolled machines, sized with the arithmetic above, and a step with a clean API can call that API instead of the screen.
Per-transaction cost is a separate question. For some very high-volume unattended jobs that move records between two systems with clean APIs, such as hundreds of thousands of identical transactions a night, a VM-based RPA estate or an integration platform may cost less per transaction, especially where the licenses, the virtual machines, and the developers already exist; enterprise RPA was built for that job and does it well.
LaunchAI can still run that work. What it adds is reach into the screens, portals, PDFs, and spreadsheets in the same job, and ownership by the person who does the process. Price the job both ways before choosing, and verify competitor pricing on each vendor's own pricing page.
Value
Hours returned: tracking the value
The console tracks hours returned per workflow, team, and month, so the number reaches the budget meeting as a figure instead of an anecdote. Counting them honestly means netting out exception handling, review time, and maintenance.
Set the baseline before the agent goes live. Time the manual process on real items for two weeks, including the interruptions. A baseline set after launch, from memory, inflates every number that follows.
Metrics
What to measure on the run console
Eight measures, each with the trend that should make you look closer.
| Measure | Definition | What a bad trend means |
|---|---|---|
| Success rate | Runs finished clean ÷ runs started | A step, input, or machine is unstable |
| Exceptions per 100 items | Flagged items ÷ items processed | The rules or the source documents changed |
| Readiness failures | Runs that never started, by cause | Machine care or input delivery needs fixing |
| Queue wait | Time from queued to running | The fleet is short of machines at that hour |
| Review wait | Time runs spend waiting on review | Reviewers are overloaded or assignment is wrong |
| Time to recover | From alert to the run finishing | Runbooks or alert routing need work |
| Changes per month | Versions published per workflow | An unstable application or policy |
| Hours returned | Per workflow, team, and month, net of review and exceptions | Value is eroding; look at exceptions first |
Governance & security
Governance and security in operations
The Run permission (start, pause, retry, stop) is separate from Approve for production. The person who operates agents day to day need not be the person who changes what they do, and the backend enforces the split.
Revoking a machine stops its agents. Use it for a lost or compromised machine; to hold work, pause the run instead.
Retries and stops are part of the run record, so an auditor sees a rescued run as rescued, not as clean.
Alerts go to named people, so an unanswered alert has an owner who can be asked why.
Coexistence
Working alongside n8n, Make, and cloud assistants
LaunchAI does not ask you to rip anything out.
A webhook starts a run. n8n's HTTP Request node or Make's HTTP "Make a request" module can call LaunchAI the moment an email lands or a form is submitted.
Shared tables and watched folders hand work between systems. A cloud assistant drops a file in a folder; the agent picks it up; results come back as table rows another tool can read.
Where you already run an integration platform for API-to-API plumbing, keep it; it does that subset well and may cost less for it. Give LaunchAI the screens, portals, and paper the plumbing cannot reach, and let the agent call an API directly where one exists for a step.
Honest limits
Tradeoffs, stated plainly
A person still owns the 5 a.m. alert.
Routing is automatic; answering is not. Name who covers early alerts before the first scheduled run.
A missed run waits for a person.
When a machine fails readiness, nothing runs in its place; give workflows with hard cutoffs, such as a bank file due by a set hour, a catch-up window before the cutoff.
Change is quick, not free.
Each redesign costs a re-shown step and an approval. An application that changes monthly costs more upkeep than one that changes yearly; count that in the value.
The whole system
How the run console connects to the rest of LaunchAI
- Studio is where the process owner re-shows a changed step.
- Atomic workflows define the steps a run resumes from and the versions a run executes.
- Human review supplies the Waiting on review state and its escalations.
- Audit trail is the evidence behind every history row.
- Desktop runtime covers the machines the fleet is made of.
- LaunchAI support is one click away from any run or step.
FAQ
Questions
What operations teams ask before the first scheduled run.
How much maintenance does an agent need after launch?
Expect small, specific changes rather than rebuilds: a rule when policy moves, a re-shown step when a vendor ships a redesign, a mapping row when a new client arrives. Plan for them after each major vendor release. LaunchAI's support engineers also help retrain an application after a redesign.
Can our ERP start a run without new integration work?
Usually, yes. Most ERPs can schedule their own report to export to a folder or to email. The file's arrival can be the trigger, so the ERP starts the agent with a feature it already has.
How do we keep a first-of-month run from firing on a bank holiday?
Put the calendar in a table and the decision in a rule. The first step checks today's date against the holiday table and either proceeds or ends the run with a note. When next year's holidays are published, one person updates the table.
Who should receive alerts?
Machine problems go to whoever looks after agent PCs. Input and exception problems go to the workflow's owner. Reviews already notify reviewers through the queue. Keep each alert to one owner with one first move.
How long is run history kept?
As long as you keep it. Retention is set per workflow, and the design choices (detail level, period, holds) are laid out on the audit trail page.
What should we do before an ERP upgrade?
Hold the schedules for workflows on that ERP. After the upgrade, run each one on demand while someone watches. Steps whose screens changed will flag with screenshots; re-show them in the Studio or retrain the application map, approve the new versions, then restore the schedules.
No prompts. No babysitting. No dumb questions.