iii

iii is a runtime engine for composing backend services, queues, cron jobs, agents, and sandboxes into a single observable system. It targets developers and platform teams who are tired of writing a new integration every time they add a queue, an observability tool, or an agent harness. Instead of wiring each piece together by hand, iii gives every service a shared live catalog where it can be discovered, called, and traced.

The core idea is three primitives: workers (processes that register with the iii engine), triggers (anything that causes a function to run, like HTTP, cron, a queue message, or a state change), and functions (units of work with a stable identifier, such as orders::validate). Any service in TypeScript, Python, Rust, or Go can become a worker with a few lines of code, and workers can be added at runtime, including by agents that need a new capability mid-task.

Key features

• Zero-integration composition: workers join a live catalog on registration, and every other worker can call them immediately without custom integration code.
• Declarative triggers: define "this function runs when this happens" and let iii handle routing, serialization, and delivery for HTTP, cron, queues, state changes, streams, and custom events.
• Runtime extensibility: add workers to a running system with iii trigger -n dev compose::add worker=<name>, which matters for agents that discover they need a new tool mid-task.
• Multi-language SDKs: official SDKs for Node.js, Python, Rust, and Go, so services written in different languages share the same catalog.
• Built-in observability: every call is traceable through the console, covering workers, functions, triggers, queues, traces, logs, and real-time state.
• Agent-first design: agents use the same function catalog and calling interface a developer would, and agent skills can be installed into third-party harnesses via npx skills add.
• Worker marketplace: a public catalog at workers.iii.dev lists installable workers (queue, database, HTTP, cron, pubsub, bridge, and more) that drop into a project via worker-compose.yaml.

Ideal use cases

iii fits teams building backend systems made of many moving parts, where queues, cron, HTTP endpoints, and agents all need to call each other and get traced consistently. It's a good match if you're building agentic workflows where an agent might need to add a capability (a new worker) on the fly and immediately use it, since the same compose and call interface serves both humans and agents. It also helps platform teams who publish shared workers (database, queue, observability) that application teams consume without a procurement or integration cycle.

It is less of a fit if you need a single lightweight library for a simple monolith with no cross-service calls, no agents, and no need for a shared trace. If your stack is already small and stable with one language and no plans for queues, cron, or agent integration, introducing a runtime engine adds operational surface you may not need. Teams uncomfortable with the Elastic License 2.0 on the engine component should also check license terms before adopting it for commercial redistribution.

Installation

Install the iii CLI and engine:

curl -fsSL https://install.iii.dev/iii/main/install.sh | sh

Start a namespace and add workers:

iii compose --namespace dev --up
iii trigger -n dev compose::add worker=queue
iii trigger -n dev compose::add worker=agent
iii trigger -n dev compose::add worker=<anything>

Install an SDK for your language:

# Node.js
pnpm add iii-sdk

# Python
pip install iii-sdk

# Go
go get github.com/iii-hq/iii/sdk/packages/go/iii

For Rust, add iii-sdk to your Cargo.toml. Browse available community and engine-owned workers at workers.iii.dev, or declare project workers directly in a worker-compose.yaml file. For agent harnesses other than iii's own, install the agent skills covering HTTP, queues, cron, state, and streams with npx skills add iii-hq/iii/skills. The developer console for inspecting workers, functions, traces, and real-time state lives in the console/ directory of the repo.