Frequently asked questions

The questions a reviewer asks first.

Answered the way they would be answered in a meeting.

How is this different from an unrestricted computer-use agent?

The difference is where authority sits. In an unrestricted agent the model decides and then acts, and success is whatever the model reports. IVAI OS is designed so that a model can only propose an action: a separate policy layer decides whether it is permitted, a separate layer carries it out, and the business result is confirmed from the application's own records by something that did not perform the action.

The practical consequence is that a mistaken or manipulated model produces a declined proposal rather than an unexplained change to a system of record.

How is this different from RPA?

Screens are intended to be read semantically rather than by fixed coordinates, so that ordinary interface changes do not silently break a workflow. Governance, verification and the reviewable record are part of the core rather than reporting added on top.

The other difference is the failure behaviour. Where a rule-based script continues and produces a wrong result, IVAI OS is designed to stop and say why.

Does a model get access to our systems?

A model is not given credentials or direct execution authority. Depending on the agreed deployment, it may receive only the limited screenshot or structured interface context needed to interpret the current state. A separate policy-controlled component decides whether an action is permitted and carries it out, while credentials remain outside the model boundary.

What happens when the model is wrong?

A wrong proposal is expected and planned for. It has to satisfy the policy, the permissions of the acting identity, the scope of the workflow and its limits before anything happens — and if it does not, it is declined and recorded rather than retried quietly.

If something incorrect were to be carried out, independent verification is designed to catch it when the result is read back and does not match what was intended.

How do you handle content designed to manipulate the automation?

Content encountered in an interface is treated as untrusted data rather than instruction. The design goal is specific: such content should be able to make the system stop, and should not be able to make it act. It cannot grant permission, widen scope, extend an approval or raise a limit, because none of those are reachable from model output.

What makes a workflow a good candidate?

It repeats at meaningful volume, its rules can be written down, its results can be confirmed objectively, its exceptions have a named owner, and a bad outcome is containable. It also has to be divisible into short steps that can each be checked.

Processes that depend on judgement which cannot be explained, or where correctness cannot be established independently, are declined rather than attempted.

Which models do you use?

The architecture is deliberately not tied to one model. Candidates are evaluated against the same fixed scenarios and selected on measured results for the workflow in question, with preference for models that can run on infrastructure the customer controls.

A model version is treated as part of an approved configuration rather than something that changes quietly underneath a running workflow.

Where does our data go?

Where a deployment runs and where its data is held are settled contractually for each engagement, in line with the customer's own regulatory position. The design supports keeping data inside the customer's environment.

Records are intended to be isolated per organisation, with separate keys, separate permissions and independent retention, and to hold only what establishes the inputs, the decision, the authority and the confirmed result.

What happens when our systems change?

Reasonable changes to layout, labelling and structure are what the semantic approach is designed to absorb. Changes large enough that the workflow can no longer be identified confidently are designed to stop the run rather than produce a guess.

Any change to how a workflow behaves is reviewed before it takes effect, rather than applied automatically.

How does an engagement start?

With a scoping conversation about one workflow: what happens today, who is accountable, how correctness would be judged, and what access could be authorised. If it does not meet the criteria, we say so early.

From there the intended sequence is an observation period without execution, then execution under approval within agreed limits, then a review of whether the results justify continuing.

Something missing

If a question you need answered is not here, write to admin@ivaios.com.