Add Workers at Runtime and Let Agents Discover Them Live

You've probably felt it. You start a backend project and before you write a single line of business logic, you're already wiring up queues, cron jobs, HTTP handlers, state, observability, and sandboxes. Each one brings its own integration story. iii is an attempt to collapse all of that into one live system surface.

What It Does

iii is a system for composing, extending, and observing every service in your stack in real time. Instead of writing point-to-point integrations between every piece of your backend, you run a shared runtime where each component registers itself as a worker.

The entire mental model comes down to three primitives: Worker, Function, and Trigger. Workers are processes that register with the iii engine and then register triggers and functions. A TypeScript API service is a worker. A Python data pipeline is a worker. A Rust microservice is a worker. Any functionality can become a worker with a few lines of code.

The interesting part is what happens when you compose workers. Each worker joins a live catalog, and every other worker gets notified and can call it immediately. That means you can add workers at runtime, and the rest of the system discovers them without a restart or a redeploy. Browse available workers at workers.iii.dev.

Why It's Cool

• Runtime composition is the real story here. The README's core example is three commands: start the system, add a queue worker, add an agent worker. Each worker joins the live catalog and every other worker is notified. No config files to thread through, no service discovery layer to stand up separately. The catalog is the discovery layer.

• The agent angle is genuinely different. This isn't just "agents can call your APIs." When a task needs a capability the system doesn't have, an agent can add a worker, discover its functions, call them, and trace what happened. The agent uses the same interface a developer does. That's a meaningful distinction—it means the agent isn't limited to a fixed tool list you defined upfront.

• One mental model, multiple languages. The README lists SDKs for TypeScript, Python, and Rust (the badges point to npm, PyPI, and crates.io respectively). Since workers are just processes that register with the engine, you're not locked into one language for your whole stack. Your data pipeline can be Python and your API can be TypeScript, and they still talk through the same primitives.

• It targets the pre-business-logic tax. The opening pitch is honest about the problem: every backend project starts with a pile of infrastructure wiring before you get to the actual product. iii's bet is that a shared runtime with a live catalog replaces most of that wiring. Whether that bet pays off depends on your stack, but it's a coherent answer to a real annoyance.

How to Try It

Getting started is a few commands. First, bring up the system in a namespace:

iii compose --namespace dev --up

Then add workers to the running system:

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

Each worker joins the live catalog, and the rest of the system is notified. From there you can browse what's available and start composing.

The project ships SDKs across several ecosystems, so you can write workers in the language that fits the job:

• TypeScript via npm (iii-sdk)
• Python via PyPI (iii-sdk)
• Rust via crates.io (iii-sdk)

There's also a Docker image (iiidev/iii) if you'd rather run it that way. The README points to a Console for observation, agent skills, and a Discord community for questions.

Full source and docs live at github.com/motiadev/motia.

Final Thoughts

iii is aimed at developers who are tired of gluing services together by hand and want a runtime that treats composition as a first-class concern. The agent story is the part worth watching—letting agents extend the system at runtime rather than working from a fixed toolset is a design choice that could matter as agent-driven backends become more common. If you're building a stack where services need to find each other without a lot of ceremony, it's worth a look. The README is the best place to start, and the worker catalog gives you a sense of what's already out there.

Follow @githubprojects for more developer tools and open source projects.