Trust

How LaunchAI Is Built

Get demo See the architecture

Five design constraints

Everything below follows from these.

  1. Local 01 Local by default. Perception, execution, rules, and evidence run on the workstation. No LaunchAI cloud in the execution path.
  2. Pixels 02 Pixels and OS input are the contract. No dependency on an API, a DOM, or a vendor SDK.
  3. Deterministic 03 Arithmetic is deterministic. Same input, same output, no model in the loop.
  4. Evidence 04 Evidence is an output. Every action emits enough to reconstruct what happened, without secrets.
  5. Models 05 Models are parts. Pluggable, versioned, supplied by you. Swapping one never forces a rebuild.

Four processes and a portal

Why the lines sit where they are: the kernel has one caller, input has one door, and Studio drives the production Runner, so a step validated in Studio ran through the exact code that will run it at 6 a.m.

WORKSTATION drivescallsinputwrites sync Studio Runner Vision Layer Kernel Evidence store Portal

Component: Studio

Job: Authoring, live validation, documentation

Why the lines sit where they are: the kernel has one caller, input has one door, and Studio drives the production Runner, so a step validated in Studio ran through the exact code that will run it at 6 a.m.

What a compiled workflow looks like

A workflow compiles to a versioned bundle: a step graph, generated functions, mapping templates, and a manifest of content digests. Change one byte and the digest changes, so an approved version can't drift and a queued run can't execute changed material.

  1. Callout 1

    Targets are semantic.

    "The Approve button in the Pay Request window" is the address. Coordinates are only hints, so a moved button doesn't break the step.

  2. Callout 2

    Every action declares what success looks like.

    The Runner won't move on until it sees it. "A voucher number appears in the header" beats "the screen changed."

  3. Callout 3

    Extracts declare a schema.

    An empty grid is a failure, not a quiet zero.

How a step runs

Every step passes through eight phases: load, observe, resolve, act, capture, annotate, verify, log. State is staged and only committed after verify passes, so a half-read grid never becomes the next step's input.

The agent never takes the first match. Zero candidates or two candidates both mean "unresolved," which routes to re-plan, human review, or stop. The first match is how an agent clicks Void instead of Approve.

Did the click land?

The hard case is a click that may or may not have committed in someone else's system. Every action gets an effect state.

EffectEvidenceNext move
AppliedExpected result seenCommit and continue
Not appliedScreen shows no changeDiscard and retry if allowed
UnknownAnything elseRetry only with a key the target app checks, otherwise ask a person

Without a business key the ERP enforces, like a vendor invoice number, the engine asks instead of guessing. A guess is how duplicate postings happen.

The deterministic kernel

The kernel is deliberately dull. Money is Decimal, never float. Inputs arrive typed, so it never guesses what "10/11" means. Generated functions use a restricted import set and run against sample values before they're accepted.

Say "anything expiring within thirty days goes to the reminder branch; anything lapsed comes to me," and Studio compiles a small, testable function you can unit test like any other code.

Evidence store

Every action writes a receipt, and every value carries lineage back to it. Metadata lives in SQLite, screenshots as plain files. Each run's records are append-only and hash-chained. A busy workstation writes gigabytes a year: a disk, not a data center.

Speed and cost

On a trained app, the slow parts are the ones the agent doesn't control: the app's own response time and human-pace input. Local layers (accessibility tree, OCR, a local detector) run before any model call, so model calls stay rare.

Throughput scales by machines, not threads: one screen runs one agent. Count model calls per run before you tune anything.

One step's time (illustrative)

100% of baseline

CaptureLocal groundingModel fallbackActVerifyLog
Levers — toggle to apply

Testing and release

  1. DraftEvery change lands in a draft.
  2. ValidateChanged steps run live and are approved by their owner.
  3. ApproveSomeone with Approve for production signs; the version becomes read-only.
  4. PublishRuns execute only approved versions.
  5. Observe, restore if neededAny earlier version restores in one action.

Re-test after a toolset upgrade, a model swap, a vendor release, a new monitor or resolution, a table schema change, or a new account running the workflow.

What forces a re-test

  • a toolset upgrade
  • a model swap
  • a vendor release
  • a new monitor or resolution
  • a table schema change
  • a new account running the workflow

Observability

Run, attempt, and step IDs, plan digest, model version, and device version are on every record, so "which runs used model X after Tuesday's table change" is a query. Watch errors by step, not by run.

Alert-worthy drift: screen mismatches rising on one app screen, more model fallbacks on a trained app, more low-confidence readings, retries rising on a writing step, unknown effects appearing where there were none.

Extension points

  • Code hooks

    Python on any step, audited and run in a restricted interpreter

  • Table contract

    Another system maintaining a mapping table, with revision checks

  • Bundles

    Your own review and promotion pipeline

  • API steps

    A clean API where one exists, still with evidence

  • Run starts

    Webhooks, watched folders, emails, table rows

  • Model endpoints

    OpenAI, Anthropic, Azure, Bedrock, or self-hosted, per step

Honest limits

  • Vision is slower per step than an API. The win is coverage.
  • Grounding is probabilistic at the edges, so the runtime refuses ambiguity and verifies every action.
  • Generated code is hardened, not formally sandboxed. Run the kernel in your own container if you need isolation.
  • Stopping isn't rolling back.
  • A vendor redesign means scoped retraining. Still work.

Questions

Why not drive browsers through the DOM?
Much of the target software has no DOM: desktop ERPs, terminal screens, scanned PDFs. One input path covers all of it and injects nothing into your browser.
What if the workstation loses power mid-step?
Staged state was never committed. The retry starts at that step, and its last action counts as unknown until settled.
How do we trial a new model safely?
Swap it in a draft, run the test cases, compare decision records, and promote only through approval. Production keeps its pinned model meanwhile.
Where do we start when a run fails?
At the step record: before and after screenshots, the target, the expected result, and the effect state.

Data flows and the vault are covered on Security.

More in Trust

No prompts. No babysitting. No Integrations.

Get a demo with our specialist team.

Get demo