// docs

Automation Engine

A parallel, WinRM-based execution engine that runs scripts and AI prompts alike — scaling with your hardware and recovering from failures on its own.

WinRM execution

Jobs run over Windows Remote Management. The engine opens a remote PowerShell session to each target, authenticated with a credential from the store, runs your script, and streams the output back. Nothing is installed on the target — WinRM is the only requirement.

What a job can be

The engine treats every unit of work the same way — queued, assigned to a worker, logged under a job ID:

TypeWhat runs
ScriptA single PowerShell or Python script against a host or group.
RunbookA numbered sequence of steps with shared state and managed reboots.
InstallerA software package or bundle from the deployment catalog.
PromptA goal handed to S.E.N.T.R.I, executed headlessly through your enabled skills.

Prompts run unattended

A scheduled or API-triggeredprompt has no one at the console, so approval-required skills are skipped — the agent's scope and enabled skills are the boundary.

Parallel workers

ServerEngine sizes its worker pool to your hardware: workers = CPU cores × 2.5. Each worker owns its own separate automation lifecycle, so an 8-core machine runs about 20 jobs in parallel. Patching 200 servers takes about as long as patching one.

Note

By default one job runs per host at a time; a second job for a busy host waits until the first finishes. The pool cap is set by your license tier.

Transport & encryption

WinRM uses port 5985 for HTTP and 5986 for HTTPS. Enable WinRM over SSL so jobs use the encrypted listener. Passwords are passed to the session securely (never on the command line) and can be masked in captured output.

SettingEffect
WinRM over SSLConnect on 5986 (HTTPS) instead of 5985 (HTTP).
Allow self-signedAccept a self-signed certificate on the target (skip CA check).
Allow by IPConnect by IP address (skips CN check).
Mask sensitive dataScrub passwords from captured job output.

Job states

Every job reports its progress as it runs:

StatusMeaning
QueuedWaiting for a free worker or for the host to become free.
ConnectingOpening the WinRM session to the target.
RunningExecuting the script (step n of total for runbooks).
RebootManaged reboot in progress — waiting for the host to return.
CompletedThe job finished successfully.
FailedThe script errored, the host was unreachable, or execution was rejected.

Retries & error detection

If a connection drops, ServerEngine automatically retries — reconnecting on a fixed interval for up to fifteen attempts before giving up and freeing the worker. Completion and failure are detected from the script's own output and exit status, and failed jobs are captured with a dedicated failure log so you can diagnose them.

Every job carries a unique job ID for traceability across the console, the Logs, and the API.

Resilient by design

Between the worker pool, automatic reconnects, and managed reboots with seamless resume, long multi-host workflows run unattended and recover from transient failures without you watching.