You've been building with Motia and part of our community, and we're grateful for that. If you've been following our updates over the past month, you've probably heard us talking about what's coming next. Today, we are making it official.
When we first began building Motia a year ago, we set out to answer a question: why is backend engineering still this fragmented? APIs live in one framework. State in another. Queues, cron, streaming, AI agents, and every integration each have their own runtimes, configs, and ways of failing. Developers spend as much time integrating these components with each other as they do building the thing they actually care about. The math is brutal: six tools before you write a line of business logic, fifteen integration edges between them, and no single trace when something breaks.
Motia was our first answer and dealt with this difficulty at the framework level. But the deeper we went, the more we realized a framework can't solve this. Every framework is still just another tool you have to integrate with five others. The real answer had to live one layer down in the primitives themselves.
So we built something that could.
It's called iii, the Interoperable Invocation Interface. Three primitives: Functions, Triggers, Workers. That's the entire model.
WTF are Workers, Triggers, and Functions?
If you've been using Motia, you already know these concepts. In fact, Motia compiles down to them; you've just been using these concepts under different names.
Functions are anything that does work. They also run anywhere: locally, cloud, serverless, even HTTP endpoints. From iii's perspective, they're all the same thing. If you've written a Step handler in Motia, you've written a Function.
Triggers are anything that can cause a Function to run. HTTP requests, cron, queues, and state changes are examples of Triggers. The event subscriptions and API routes you've been defining in Motia? Those are Triggers.
Workers are the processes that dynamically register and deregister their Functions and Triggers with iii. When you run Motia today, you're already running a Worker.
In other words, the patterns you've been building within Motia map directly to Workers, Triggers, and Functions. Motia's model was always heading in this direction. iii has made it explicit, universal, and language-agnostic; your Motia Steps can now call Python ML pipelines and Rust services as if they were local functions, with one shared trace across all of them.
Add a worker
The current paradigm in software engineering, the answer to any problem is to add a framework, service, tool, or platform. iii challenges this assumption so that any functionality or capability becomes a design pattern using the same primitives.
The answer to every backend question becomes the same: add a worker. Any worker. The ones we ship, the ones you build, the ones nobody has thought of yet. Need an API? Add a worker. Need MicroVMs? Add a worker. Need cron? Add a worker. Need an agent, a Python ML pipeline, a go-to-market workflow, a browser client? Add a worker. Need something that doesn't exist yet? You already know the answer. The moment it connects, it's already discoverable, callable, and traceable across the whole system. No new framework. No new tool. No new category.
That's what makes it unprecedented: a distributed backend that functions as a single, coherent application.
The result:
- One trace, end to end. A TypeScript API calls a Python function that enqueues work, triggering a state change, all in one trace, not five logs you correlate by timestamp.
- Durable orchestration. Execution can be inherently long-running and fault-tolerant.
- Interoperable execution. Languages and runtimes interoperate easily.
- Polyglot for free. Python, TypeScript, and Rust (or any language that has an iii SDK) call each other natively. The engine handles serialization, routing, and delivery.
- Live extensibility. Add capabilities to a running system without redeploying. When a new worker connects, every other worker sees its functions instantly.
- Agents as first-class citizens. An agent is a worker. Its tools are functions. Its memory is state (another worker). No separate harness, no second system. The agent and the backend aren’t two worlds that the rest of the industry is still trying to integrate together.
A model so simple that both humans and AI agents can reason about it without running out of context.
What this means for Motia
Motia is now deprecated. But you're not starting over. You're upgrading.
If you've been building with Motia, the good news is you're already most of the way to iii.
If you already have your backend workflows in production, you don't need to start from scratch. The concepts you're using today: Steps, routes, subscriptions map cleanly onto iii's Functions, Triggers, and Workers, and we've published a step‑by‑step migration guide to walk existing Motia projects onto iii with minimal friction.
iii’s Rust based engine enables the performance and capabilities to go far beyond the original version: truly achieving Motia's vision of making every part of the backend easily composable.
To explore iii itself, start here: https://iii.dev/docs/
To migrate your existing Motia project, the full migration guide is here: https://iii.dev/docs/changelog
If you have questions or need a hand with the transition, reply to this post, and the team is available on Discord.
Unix made everything a file. React made everything a component. iii makes everything a worker. Come join us on the journey of turning functionality and capabilities into design patterns.
We're just getting started. Thanks for being part of this community from the early days.
