The AI agent & Deploy Gate

JasperNode is an AI-first environment. A built-in agent can read the whole tag tree, write logic, create and configure connectors, run network scans, and help you troubleshoot — all through chat. What makes this safe to use on real machinery is that anything which changes the running process is held at a gate: it must be tested, and (in the right modes) signed off by a human, before it takes effect.

Talking to the agent

The AI Agent panel lives on the right edge of the IDE. Toggle it from the left rail or press ⌘K / Ctrl+K to focus it.

• Describe what you want in plain language: “add a 5-second high-temp alarm on factory/line1”, “set up MQTT to broker 10.0.0.5 and map the clock topics”, “why did bench_s71200 disconnect?”
• Reference tags and folders with @ mentions — they deep-link into the tree.
• The agent works against the same tag surface you do; it has no private back door into the engine.

Read-only vs. process-affecting

The agent’s actions come in two flavours:

• Read-only investigation — browsing tags, reading scripts, summarising status, running a network scan. These run freely; nothing about the process changes.
• Process-affecting changes — writing a script, enabling a connector, deleting a tag. These are gated. The agent proposes the change, the runtime tests it, and — depending on mode — waits for your approval.

You always see each tool call the agent wants to make. Process-affecting ones surface as an approval card with the proposed change and its test result.

Operating modes

A node runs in one of three modes, set by a human (an editor) and stored as a tag. The mode does not restrict what a human may edit — it controls how much the AI is allowed to do on its own, and how thoroughly a change must be tested:

Mode	What it’s for	AI test scope before deploy	Human sign-off
development	building, free experimentation	the modified script (at least two test inputs)	not required
commissioning	bringing a machine up on real I/O	the change plus one level of downstream effects	required
production	running plant	the change plus its full downstream chain	required

Only a human changes the mode, and stepping back toward development requires explicit confirmation. Reaching production marks the project’s job complete (see Licensing).

The Deploy Gate

Process-affecting AI changes move through a small state machine:

pending ─▶ tested ─▶ awaiting-approval ─▶ approved ─▶ deployed

• tested — the runtime runs the proposed change in an isolated fork of the engine against test values; the fork can never leak into the live process. In commissioning/production it also re-simulates downstream (and, in production, upstream) tags so you can see the consequences.
• awaiting-approval — in commissioning and production, the agent stops and shows you a Deploy Gate card: the proposed change as a diff, the test report, and Approve / Reject. Approve is disabled if the test failed; rejecting takes a reason.
• approved → deployed — on approval the change flips live atomically — the script and its inputs change together, between cycles, as one unit — and the transition is recorded.

Direct human edits are not forced through this gate in development; the gate exists to constrain AI agency and to produce an audit trail. In commissioning and production the same sign-off applies to human and AI changes alike.

Some actions are gated regardless of mode because of what they do to the field. Enabling a connector that drives an out tag is one: on enable the connector cold-starts and writes the commanded value straight to a physical output, so the agent stops and spells out exactly which tag would start being driven, and waits for your explicit Yes.

Guardrails on AI changes

Beyond the gate, every AI action passes through a set of hard rules the agent cannot talk its way around. The initial set includes:

• Read a script before modifying it.
• Refuse to delete a tag that has active subscribers.
• Refuse to disable a writer connector in production without sign-off.
• Refuse to deploy a script that loops without yielding (no await fn.sleep(...) / fn.timerOn).

These rules are checked on every relevant action, are auditable, and grow as the team encounters new cases.

Identity, roles and the audit trail

• Sign-in is via the JasperX cloud — there are no local accounts. The first editor to register a node owns it and invites others.
• The current role is Editor (full edit plus the AI agent). A read-only Viewer role and presence indicators for multiple concurrent editors are planned for later releases. Today, multiple editors may work at once with last-writer-wins on a tag.
• Every gate transition and human approval is written to an activity log kept alongside the tag database. Together with mode-gating, atomic deploy and safety/non-safety segregation, this audit trail is what makes JasperNode auditably safer at the supervisory layer — though, to be clear, the runtime is not yet safety-certified (see JasperNode vs. a PLC → where a PLC is ahead).

In practice

A typical loop while building: ask the agent to draft logic or a connector → review the proposed change and its test result → approve it → watch it run on live values → iterate. You stay in control of every change that touches the process, while the agent does the legwork of reading the tree, writing the code, and wiring up the dependencies.