Every new capability in a iii system is added by creating a Worker. A queue, a scheduler, an HTTP edge, a browser tab, an agent, a CRM integration, or a sandbox. Each is a Worker that connects to the Engine and registers Triggers and Functions. The Engine itself never needs to change.
Scanned 9/3/2026
Install to Claude Code
npx -y skills add iii-hq/iii --skill creating-workers --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Creating Workers?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/iii-hq-creating-workers-8959e885)More formats (shields.io, HTML) on the badges page.
<!-- generated by iii-skill-render. DO NOT EDIT (changes here are overwritten on the next render). Edit docs/next/creating-workers/index.mdx. -->
# Overview
Every new capability in a iii system is added by creating a Worker. A queue, a scheduler, an HTTP
edge, a browser tab, an agent, a CRM integration, or a sandbox. Each is a Worker that connects to
the Engine and registers Triggers and Functions. The Engine itself never needs to change.
## Workers are the services
A Worker is the unit of capability in iii. It is the service. When you need new behaviour, you write
a new Worker (or install an existing one from the registry); you do not patch the Engine, add a
plugin to it, or fork it. The Engine is a fixed coordinator, it routes invocations between Workers
and maintains the live registry of what each Worker provides. Everything that makes a iii system do
something useful runs in a Worker.
This is why "add a Worker" is the answer to almost every "how do I add X to iii?" question. If a
capability is missing, the gap is filled by a Worker, not by a change to iii itself.
<Note>
For the mental model behind Workers, Triggers, Functions, and the Engine, see [Understanding iii /
Overview](../understanding-iii). To build Workers continue with this section.
</Note>
## Build on existing Workers
Most Workers you create will use one or more existing Workers for their basic functionality, an HTTP
endpoint, a key-value store, a queue, scheduling, observability, a sandbox, rather than building
those from scratch. Reach for what already exists before writing your own.
The ones you reach for most often are documented here under **Common Workers**:
- [HTTP](./http), expose Functions as HTTP endpoints.
- [Queues](./queues), async job processing with retries and a dead-letter queue.
- [Observability](./observability), traces, metrics, and logs across Workers.
- [Sandboxes](./sandboxes), run untrusted or short-lived code in an isolated microVM.
- [Access Control](./worker-manager), accept untrusted connections through RBAC-gated listeners.
The full catalog of Workers is published at [workers.iii.dev](https://workers.iii.dev). If you need
common
functionality for your Worker, look in these two places first.
## What's in this section
<CardGroup cols={3}>
<Card title="Workers" href="./workers" icon="server">
Connect a Worker to the Engine and deploy it.
</Card>
<Card title="Triggers" href="./triggers" icon="bolt">
Declare what causes those Functions to run.
</Card>
<Card title="Functions" href="./functions" icon="code">
Register the Functions a Worker contributes.
</Card>
</CardGroup>
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!