AI features

NodePilot integrates an OpenAI-compatible language model. Cloud services and local endpoints such as Ollama, LM Studio, vLLM, LocalAI or llama.cpp are supported.

The AI features are disabled by default. The corresponding buttons (script editor, workflow designer, AI chat) only appear once an LLM profile has been configured and enabled in the admin settings. Generated content is never published or executed automatically.

Where they are used

Script editor

Where: open a runScript activity, maximize the script editor and start the AI feature through the AI button (magic-wand icon). The button is only available to the Admin and Operator roles.

Suitable for:

• A new PowerShell script from a short task description
• Extending an existing script
• Fixing errors or simplifying
• Adapting to the available workflow variables

An existing script is sent only after it is confirmed in the dialog for the AI target shown there; if the AI profile changes before sending, the dialog asks again. Available variables are taken into account as context, without their values. The result can be inserted at the cursor or accepted as a complete replacement.

Accepting it only changes the content in the editor. Before saving and running, a review of the commands, paths, permissions and variables used is required.

Workflow designer

Two features are available in the workflow area.

Generating a new workflow

Where: the workflow overview, the New AI Workflow button.

From a description, NodePilot creates a complete workflow draft with triggers, activities and connections. Before it is created, a preview, the generated definition and the number of nodes and edges are shown. Only your confirmation creates the workflow.

Suitable for:

• A first executable draft
• Typical linear or branching processes
• A starting point for further editing in the designer

Machines, credentials, target paths and business conditions have to be reviewed and completed afterwards.

Generation and the assistant know every activity type — including the llmQuery activity, loops and branches. They also know the custom nodes enabled on this installation and suggest them, instead of rebuilding their function out of individual script steps.

Editing the open workflow

Where: the workflow designer, the AI assistant button.

The assistant knows the currently open workflow. Possible tasks are:

• Explaining the structure and flow
• Describing possible failure points
• Explaining the errors and warnings of the validation panel — they are sent along with every question
• Analysing the execution history and failed steps
• Suggesting error handling or additional steps
• Including selected nodes deliberately through @ or the current canvas selection
• Tidying up the layout

Changes appear as a proposal first. Individual nodes and edges can be selected, accepted or discarded. An accepted change can be undone immediately.

If the canvas changes after a proposal was created, the stale proposal is no longer applied. That protects edits made in the meantime.

The workflow-scoped chat supports several named threads, regeneration, Markdown export and a view of the previous AI activity.

The chat and the properties panel share the right-hand area of the designer: the open assistant overlays the properties. As soon as a node or a connection is clicked on the canvas, the chat steps back and the matching properties reappear. A multiple selection leaves the chat in place — it is the chat's selection context.

The global AI chat

Where: the chat button in the bottom-right corner or the AI Chat page in the navigation.

The NodePilot Assistant opens the same conversations in a compact window over the current page. Minimizing and navigating preserve ongoing answers and message drafts. A completed answer adds an indicator to the closed chat button. Open full chat carries the conversation into the full chat page. The workflow designer has no chat button — the workflow assistant covers that page; the workflow list still has it. The global chat and the workflow assistant keep their own conversations.

On phones, the window fills the visible screen and keeps the input accessible when the keyboard opens. Escape minimizes the chat. History and conversations survive a reload in the same browser tab; ongoing requests and drafts last only until reload. Signing out cancels requests and clears chat data.

Both views can be dragged wider or narrower — useful for answers with wide code blocks or tables. On the full chat page, the column has a handle on each outer edge; the small window in the bottom-right corner has one handle on its left edge, since it stays anchored to the right. Double-clicking a handle restores that view's default width. The two widths are remembered separately, per browser, and survive a restart; when the window is narrower than the chosen width, only as much is displayed as the space allows, without losing the setting. Narrow windows and phones have no handles.

The global AI chat is not tied to an open workflow. It serves as a read-only assistant for questions such as:

• Setting up a trigger or a deployment
• Explaining existing workflows
• Finding failed or scheduled executions
• Information about machines and operations
• Questions about the source code, if that source is enabled

The chat cannot propose or apply workflow changes. Answers depend on the available knowledge sources. All of them except the system configuration are enabled administratively:

The database source runs read-only queries exclusively. Write operations are blocked. Protected columns and detected secrets are not passed to the model.

The starter suggestions on the empty chat page depend on the available knowledge sources. If the database source is available, operational analyses are suggested — the most recent failed runs, stuck executions or unreachable machines, for example. Otherwise, questions about the documentation and the schedule appear, which can be answered without that source.

Choosing between them

The llmQuery activity

llmQuery is not an authoring aid but an activity inside a workflow. During execution the activity sends a prompt to the configured model and passes the answer text on to subsequent steps.

Configurable, among other things:

• The prompt and an optional system prompt
• The model and the endpoint
• The maximum answer length and the temperature
• Text or JSON output
• The timeout

By default the activity uses the active LLM profile. Different settings can be set on the node. Llm:Enabled=false disables this activity too, as does a missing active profile.

Further fields and outputs are in the llmQuery reference.

Permissions and security

• Script and workflow generation require the Admin or Operator role.
• Read-only questions in the workflow-scoped and global chat are possible for authenticated roles.
• Workflow proposals may only be applied with edit permission and an active edit lock.
• Source-code knowledge in the global chat is limited to Admin and Operator; database knowledge with raw SQL is available to global admins only. Folder permissions do not elevate an operator into that capability. Workflow definitions and static workflow analyses remain reserved for Admin and Operator with folder RBAC; a viewer receives only the scheduled execution times from the operational source.
• Folder RBAC limits access to workflow data.
• Secrets are redacted before model requests. Literal values in decision cases and condition groups are redacted too, so the assistant cannot change a case list or condition group that contains one: the proposal keeps the original and a note names the node or edge to adjust by hand.
• The workflow assistant reads scripts, SQL queries and program arguments in clear, so the configured AI provider sees them. A value with a recognised secret pattern (for example PASSWORD = '…' or ConvertTo-SecureString '…') is sent fully masked. Recognition is a heuristic and does not catch every embedded password. An administrator can switch this off per LLM profile under Settings → Integrations → LLM ("Share scripts, SQL and arguments with the AI chat"). If the profile, its endpoint, its model or this setting changes, the chat no longer sends the earlier conversation. The global chat applies the same rule and notes under the answer that the earlier conversation was not sent.
• Generated scripts and workflow changes always require a domain review.
• AI actions and applied proposals are recorded in the audit log.

Configuring the LLM

NodePilot stores any number of LLM profiles. A profile describes exactly one connection — endpoint, model, key and limits. Exactly one profile is active and is used by all AI features; switching between profiles is a save operation in the settings and does not require re-entering the connection details.

{
  "Llm": {
    "Enabled": false,
    "ActiveProfileId": "openai",
    "Profiles": {
      "openai": {
        "Name": "OpenAI Cloud",
        "BaseUrl": "https://api.openai.com/v1",
        "ApiKey": null,
        "Model": "gpt-5.5",
        "MaxTokens": 128000,
        "TimeoutSeconds": 90,
        "EnableToolCalling": false,
        "ToolCallMaxDepth": 6
      }
    }
  }
}

Per profile:

Outbound proxy

In corporate networks, outbound traffic is often only permitted through a proxy. The settings for that are under Llm:Proxy and apply to all AI calls — both chats, script and workflow generation, the llmQuery activity, the AI agents and team drafting, and the connection test in the settings. It is deliberately one block for the whole installation rather than one per profile: the mixed case — a cloud model through the proxy, a local model directly — is expressed through the bypass list.

A proxy is the answer to "outbound traffic may only leave this network through the proxy" — not to "the endpoint is unreachable". If the endpoint is in a different network segment and the firewall has not been opened, a proxy changes nothing. So check first which stage fails: the section When the endpoint is unreachable answers that in seconds.

HTTP loopback targets (localhost, 127.0.0.0/8, ::1) are always connected directly regardless of Mode and BypassList, so that the prompt and API key never leave the host unencrypted.

Note: if the traffic goes through a proxy, the proxy resolves the target address. The additional check NodePilot otherwise performs immediately before the connection is established then only applies to the proxy itself; the base URL is still checked when saving and at startup.

Proxy changes take effect without a service restart. The only exception is System: changes to the Windows proxy settings themselves are only picked up after the service is restarted.

When the endpoint is unreachable

Reaching the endpoint and waiting for an answer are two separate things with separate limits. TimeoutSeconds applies only to the model's answer; establishing the connection fails independently of it after a few seconds. A generous time limit for a slow model therefore does not mean waiting minutes for an unreachable endpoint.

The error message names the stage at which it failed:

One certificate note that often costs time: NodePilot validates against the machine's certificate store, not the signed-in user's. An internal certificate that the browser on a workstation accepts has to be in the computer's trusted root certification authorities on the NodePilot server.

The request format (derived from the base URL)

OpenAI operates two request formats side by side: the classic chat completions and the newer Responses API. Some models are reachable only through the Responses API. NodePilot supports both and recognizes from the base URL's path which one is meant — a separate switch for it is deliberately unnecessary:

The detection ignores case and trailing slashes. Local runtimes such as Ollama, LM Studio, vLLM, LocalAI or llama.cpp understand chat completions only.

With the Responses API, NodePilot sends store: false to disable the corresponding application-state persistence. This does not guarantee zero retention at the provider. OpenAI's abuse-monitoring logs are separate and can contain prompts and responses for both Responses and Chat Completions. Review the provider's data controls, including your organization's approved retention settings and feature exceptions, before sending scripts or operational data. NodePilot cannot grant provider-side Zero Data Retention through this flag.

Reasoning models accept no sampling parameters and reject a request that carries temperature. Since that value is optional, NodePilot drops it in such a case and repeats the request automatically — the activity then runs with the model's default sampling instead of failing. Only activities that set temperature explicitly are affected; a profile has no such value.

Profiles are best created under Settings → System → Integrations → LLM. Profiles created there can be managed completely. A profile that is additionally defined in a base configuration file or in environment variables can be edited in the interface but not deleted — it would reappear the next time the configuration is reloaded. Such profiles are marked accordingly in the interface.

The API key should be set through the environment variable Llm__Profiles__<id>__ApiKey or a secret provider. A plaintext value in the configuration file produces a security warning.

Tool calling is a property of the model and is therefore configured per profile. It requires a model with reliable function-calling support and is necessary for the global AI chat to query the enabled knowledge sources.

The LLM connection can be tested per profile in the administrative settings. Changes to the Llm section take effect without a service restart. If AI is enabled but no profile is selected, all AI endpoints answer with 503 LLM_NO_ACTIVE_PROFILE; the service still starts normally.

Configuring the global AI chat

The global AI chat has its own switch and its own knowledge sources:

{
  "AiKnowledge": {
    "Enabled": false,
    "DocsEnabled": true,
    "OperationalEnabled": true,
    "SourceCodeEnabled": false,
    "DbEnabled": false
  }
}

For a working global AI chat, the following settings have to be active:

Llm:Enabled = true
Llm:ActiveProfileId = <the ID of an existing profile>
Llm:Profiles:<id>:EnableToolCalling = true
AiKnowledge:Enabled = true

The individual sources can be enabled independently under Settings → AI knowledge. Documentation as well as workflows and operations are intended as sources by default. Source code and database are disabled by default for security reasons.

Optionally, your own root directories for documentation and source code can be set, as well as limits for file size and the number of hits. Without your own paths, NodePilot uses the knowledge directories shipped with the installation.