Installs into .claude/skills of the current project.
Are you the author of Understanding Iii?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/iii-hq-understanding-iii-a02984a8)
<!-- generated by iii-skill-render. DO NOT EDIT (changes here are overwritten on the next render). Edit docs/0-12-0/understanding-iii/workers.mdx. -->
# Workers
{/* TODO: Consider combining with Functions and Triggers into one doc. */}
## What a Worker is
Workers are what actually do things in an iii system. Every category of capability is built as a
Worker: queues, scheduling, sandboxing, observability, agents, business logic, devices, and even
code executing in a browser.
Specifically, a Worker is a process that connects to the Engine over WebSocket and announces a set
of Functions it can run and Triggers to register. Once connected, those Functions are invocable from
anywhere in the system and those Triggers will respond to their events without per-pair integration
code between the caller and the Worker.
The Worker concept is intentionally narrow. A Worker is not a microservice, a job runner, or a
sidecar. It is a participant in the Engine's live registry that contributes Functions and Triggers.
Whether the Worker is a long-lived process serving thousands of invocations per second or a
short-lived process that connects, registers, runs once, and shuts down, the Engine treats it the
same.
## Worker isolation
Workers are intended and designed to be independent processes. One Worker crashing does not affect
others. The Engine connects to each Worker over a separate WebSocket and routes invocations only to
Workers that are currently connected. A crash, restart, or network partition affecting one Worker
does not propagate to the others. The crashed Worker's Functions and Triggers drop out of the
routing table on disconnect, and every other Worker keeps serving.
