iii: The end of backend fragmentation

A WebSocket-based engine that replaces API gateways, message queues, cron daemons and AI agent scaffolding with one unified runtime.

Modern backend development has a hidden tax. Every new capability you add requires its own tool, its own setup, and its own operational overhead. An HTTP route means a gateway, a message queue means a broker, and a scheduled task means a background daemon. After a while, your backend is not a unified system—it is a collection of separate components held together by messy glue code.

Think of a traditional website backend like a restaurant where the cooks, waiters, and cleaners all speak different languages and need separate translators (glue code) to talk to one another. iii (pronounced "three eye") acts as a single manager who coordinates all of them using a direct, live phone connection (WebSocket).

**One runtime, every primitive**

The idea is simple but radical. Instead of running a separate HTTP gateway, a separate queue consumer, a separate cron daemon and separate AI scaffolding, you run one engine. iii handles all of it through a unified WebSocket protocol. Workers connect to the engine, declare what triggers they respond to and define the functions that do the work.

That is the entire mental model: Worker, Trigger, Function. A Worker is the process hosting your code. A Trigger is what causes a function to run (an HTTP request, a scheduled time, a queue message, a stream event). A Function is the unit of work, identified by a stable name.

**Mix languages without translation**

Workers connect over WebSockets, which means they can be written in any language with a WebSocket library. You can run a TypeScript API worker alongside a Python data pipeline and a Rust processing service. They all speak the same protocol. iii routes traffic to the right worker without any translation layer between them.

Need to handle more traffic? Spin up another worker instance. iii detects the new connection and routes to it immediately. No load balancer configuration, no service discovery setup.

**Observability as a first-class feature**

Most backend observability requires bolting on a logging service, a tracing tool and a queue inspector. Three separate tools with three separate configurations. iii ships with structured logging, end-to-end link tracking and iii-console: a visual debugger that shows worker states, execution traces and queue depths in real time. Zero extra setup.

**AI agents as Workers**

Traditional AI agent frameworks keep agents isolated. They run in a sandbox with limited ability to interact with the rest of your stack. In iii, an agent is just another Worker. It connects over the same WebSocket protocol and responds to the same kinds of Triggers. With the right permissions, an agent can dynamically create other Workers, invoke functions across your stack, or interact with any Trigger type natively. The framework does not get in the way.

**The setup difference**

Building a comparable system with traditional tools requires configuring an API gateway, setting up queue serialization, writing cron daemon configuration, and wiring state management. That is typically 400+ lines of configuration before you write a single line of business logic.

iii replaces all of it. Define a Worker, declare your Triggers, deploy. The same capabilities in roughly 100 lines of clear code.

**Get started**

Install the engine with one command:

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

Launch it with `iii` and start adding workers using the language SDK of your choice.

The repository is at github.com/iii-hq/iii.

The thesis is that backend complexity is mostly accidental. It is the result of assembling systems that were never designed to work together. iii proposes that a single engine, designed for the whole job from the start, is cleaner than the sum of its parts.