iii 0.22.1 reduces services to three runtime primitives
iii 0.22.1 asks a platform team to model its system as workers, functions, and triggers. A worker is a running process that registers capabilities. A function is a named unit such as orders::validate. A trigger connects that function to an HTTP endpoint, queue message, cron schedule, state change, stream event, or direct call. Once a worker joins the engine's catalogue, other workers can discover and call it without each pair building a custom integration.
The model crosses language boundaries. Official SDKs cover Node.js, Python, Rust, and Go, while the engine is written in Rust. Built-in workers handle queues, state, pub-sub, streams, cron, HTTP, observability, execution, bridges, and configuration. Agents see the same functions developers call, and Agent Skills describe the engine primitives or worker-specific behavior. That shared capability catalogue is iii's sharpest idea: an added worker becomes visible to applications and agents through one contract.
What happened when we ran it
Our sandbox installed 820 packages in 29 seconds at commit bacffa0, consuming 800 MB on disk. The checkout was much larger than a small runtime: 3,139 files, about 372,238 lines of source, and 158.2 MB. It is a pnpm monorepo with workspaces and 27 CI workflow files. Our scan found no top-level tests directory and no Dockerfile, although a published container is linked from the README.
The build failed after 15 seconds. Turbo reported 0 successful tasks out of 6, named docs#build as the failing command, and printed lifecycle failures for the console frontend, helpers, browser SDK, observability UI, website, and docs. The log tail does not contain the earlier error that made the docs task exit 1. We therefore cannot tell whether the fault was source, configuration, or an environmental requirement omitted from the tail.
The test command failed after 17 seconds and showed the same shape: 0 of 6 build tasks succeeded, docs#build exited 1, and pnpm ended with ELIFECYCLE. The supplied output does not show test cases starting, passing, or failing. A contributor following our clean Node 22 path would need the complete earlier log and the project's documented development environment before diagnosing it. The honest finding is that install succeeded while both follow-up commands stopped at the workspace build stage.
Four SDKs expose one catalogue and one console
iii 0.22.1 provides 4 SDK languages, and its console inspects registered workers, functions, triggers, queues, traces, logs, and live state. Platform teams can publish workers, while application teams register business functions and declarative triggers. Adding a queue or sandbox through iii worker add places it inside the same discovery and trace model. This can eliminate repeated adapters when many applications need the same capability.
Standardization creates a new dependency. A direct library call or broker client has a small local failure domain. Moving HTTP, queues, scheduling, state, streams, and agent tools behind iii makes the engine's routing and registration behavior part of every service path. The payoff grows with the number of teams and duplicated integrations. A small application with two services is unlikely to recover the migration and operational cost.
The worker registry also changes supply-chain review. Agents can add a capability and discover its functions at runtime, but a new worker is still executable infrastructure. Teams should pin workers, inspect their skill instructions, restrict credentials, and decide who may add them. A trace shows what was called after the fact; it does not make an unsafe worker acceptable. The same approval process used for a service or container should apply to catalogue additions.
Elastic License 2.0 applies to the engine
The 0.22.1 repository uses mixed terms. The engine runtime is under Elastic License 2.0, while SDKs, CLI, console, documentation, and website are under Apache-2.0. GitHub consequently reports no single repository license. Organizations with an open-source-only procurement policy cannot infer approval from the Apache badge on the SDK. They need to review the engine license and their planned distribution or hosted-service model with counsel.
Operational issues deserve equal weight. Issue #2072, opened on 2026-08-21, reports an observability subscriber-lag warning that feeds itself and can fill disk. Issue #1958 says a channel-level RabbitMQ error can silently stop every consumer sharing the channel, with no recovery. Issue #1927 describes an invocation that can remain unacknowledged without a dispatch timeout. These reports concern queues and observability, which are central reasons to adopt the runtime.
Maintenance response is visible too. Current issues about duplicate worker registration and RabbitMQ retry behavior received comments on 2026-08-25. Release 0.22.1 fixed persisted queue configuration at boot, PATH-based binary resolution, observability trace startup, sandbox guest processes, and RabbitMQ dead-letter inspection channels. That release content shows maintainers working directly on failure handling, while the remaining reports show that the reliability surface is still moving.
18,627 stars accompany same-day fixes and issue traffic
iii had 18,627 stars, 66 open issues and pull requests combined, and a last push on 2026-08-25. Version 0.22.1 was released on 2026-08-07, and active issue replies continued through 2026-08-25. Those dates indicate a live project with substantial attention. They do not erase the difference between a popular developer platform and infrastructure that has years of uneventful production behavior.
The documentation is direct about the three primitives, quick start, SDKs, worker catalogue, Agent Skills, console, monorepo structure, and split licensing. The build log gap is the immediate contributor concern; open reliability issues are the deployment concern. iii merits a bounded proof of concept for a platform team drowning in point-to-point integrations. Measure failure recovery and catalogue governance first, and prefer Dapr, Temporal, or NATS when one of their narrower operating models matches the actual problem.