Motia Became iii
The Rust Engine Trying to Make Your Entire Backend Agent-Addressable
A week ago this project was called Motia, an RC framework where APIs and agents shared a Step abstraction. Today it is called iii, ships a Rust runtime, and claims your queues, cron jobs, and state stores should be Workers in a live catalog that agents can call the same way developers do.
If you checked the Motia GitHub repo last week, you would have found a pre-release TypeScript framework that unified APIs, background jobs, and AI agents into a single “Steps” abstraction wired together by events. If you check it today, the repo is called iii-hq/iii, the framework is a Rust engine with SDKs for Node.js, Python, Rust, and Go, and the tagline says it collapses “every service in your stack into one live system surface.” The version jumped from 1.0.4-rc.1 to 0.19.2 in a single rebrand push. The npm package is no longer motia; it is iii-sdk. This is not a minor version bump. This is a project that decided to stop being a framework and start being a platform, and it did it in public over the course of about eight days.
The rebrand is not a new coat of paint on the same architecture. The pre-rebrand Motia had a clean concept: APIs, background jobs, and agents were all “Steps” in a single project, wired together by events, supporting TypeScript, JavaScript, Python, and Ruby. The polyglot story was already there, and it was already the feature that separated Motia from every other agent framework on the market. The rebrand replaced the Steps abstraction with a three-primitive model: Workers, Functions, and Triggers. A Worker is a process that registers with the iii engine. A Function is a unit of work with a stable identifier like orders::validate or content::classify. A Trigger is anything that causes a Function to run: an HTTP request, a cron schedule, a queue message, a state change, a stream event, a direct call. The engine, written in Rust, handles routing, serialization, delivery, and observability. Workers can be written in any language with an SDK, and they can create other Workers at runtime. The mental model shifted from “a framework that unifies your application code” to “a runtime that makes everything in your stack callable by everything else, including agents.”
This is an aggressive architectural bet. Most agent frameworks start from the question “how do we give an LLM access to tools?” and build outward from there. iii starts from the question “how do we make every service in a backend addressable through a uniform interface?” and treats agents as one of several consumers of that interface. The agent story in iii is that an agent is a Worker, same as your API server, your queue consumer, or your cron scheduler. When an agent needs a capability the system does not currently have, it can add a Worker, discover its Functions, call them, and trace what happened. The same iii worker add command a developer uses to install a queue Worker is the interface an agent uses to extend the system at runtime. The framework does not distinguish between developer composition and agent composition. Both operate on the same catalog.
The practical consequence is that an agent in iii can do things that would require custom orchestration code in LangGraph or CrewAI. If a task requires a capability not currently in the system, the agent does not need a pre-configured tool list that covers every possibility. It can extend the system by adding Workers from a catalog at runtime, the same way a developer would add a dependency. The catalog at workers.iii.dev lists pre-built Workers for queues, state, pub-sub, streams, cron, HTTP, observability, sandboxes, and a growing collection of domain-specific capabilities. An agent that discovers it needs a PostgreSQL connection does not need PostgreSQL in its tool set at initialization time. It adds the database Worker and calls query::execute. The runtime handles the rest.
The Rust engine is the piece that changes the durability story. The pre-rebrand Motia was TypeScript-first, which meant the execution model was Node.js event-loop semantics all the way down. The iii engine is Rust, with an architecture that looks more like a lightweight service mesh than an application framework. Workers register with the engine over a protocol. The engine routes triggers to Functions, handles serialization, and emits OpenTelemetry traces for every call. The engine ships built-in Workers for the infrastructure primitives every backend needs: queue, state, pub-sub, stream, cron, HTTP, observability, and a Worker manager that can add new Workers at runtime. These are not third-party integrations. They live in the engine repository and ship as part of the platform. The licensing split is engine under Elastic License 2.0 and SDKs, CLI, and console under Apache 2.0. The engine is source-available but not open source. The SDKs are open source. If you are evaluating this for production, the licensing boundary matters, and the Elastic License 2.0 on the engine is a real constraint for anyone with an open-source purity requirement.
The console is the other piece that survived the rebrand and got upgraded. iii ships a developer console, a React and Rust application that lets you inspect Workers, Functions, Triggers, queues, traces, logs, and real-time state. The console shows you the live system surface: every Worker that is running, every Function it exposes, every Trigger that is active, and every trace from every call. This is the kind of visibility that agent frameworks typically defer to external observability tools, and the fact that iii bundles it as a first-party experience is a deliberate design choice. The console is not a monitoring dashboard bolted onto a framework. It is the primary interface for understanding what the system is doing, and it works the same way for agents as it does for human operators. An agent’s calls appear in the same trace view as a developer’s API requests. The same filters work for both. The same alerts fire for both. The boundary between agent operations and application operations dissolves because the system was designed not to have that boundary.
The agent skills system is the newest piece and the one that reveals where iii is aiming. The project ships agent-readable reference material as installable skills covering every primitive: HTTP endpoints, queues, cron, state, streams, and custom triggers. Every Worker in the iii-hq Workers catalog ships its own skill. When an agent is added to an iii project, it can install the skills for the Workers it needs, giving it structured knowledge of every available Function and its parameters. This is the inverse of the typical agent framework approach, where the framework gives the agent a JSON schema of tools and hopes the LLM figures out the semantics. iii gives the agent reference material the same way a developer reads documentation. The skills are versioned alongside the Workers, so an agent that installed the database Worker skill three months ago is operating with the same documentation that matches the Worker version currently running.
The comparison that structures itself is with Dapr, which we covered on Wednesday. Dapr gives you building blocks for state, pub-sub, bindings, and actors that run as sidecars next to your application. iii gives you a runtime where Workers are first-class processes and Functions are first-class callable units, but the idea of a uniform abstraction layer over infrastructure primitives is similar. The difference is that Dapr was designed for applications written by developers and operated by platform teams. iii was designed for a world where agents are one of several consumers of those same primitives, and the developer console is the same tool the agent uses to understand the system. Dapr separates the infrastructure layer from the application layer. iii argues that in a world with agents, that separation is a liability because agents need to interact with the same primitives through the same interface as the application code. When your agent needs to enqueue a background job, it should call the same queue Function your API handler calls. When your agent needs to persist state, it should write to the same state store your session middleware reads from. The uniform interface is the point.
The polyglot story is the dimension where iii is genuinely ahead of every other agent framework in the ecosystem. The SDKs for Node.js, Python, Rust, and Go all expose the same primitives: register a Worker, declare Functions, hook Triggers. A Python data pipeline can emit an event consumed by a TypeScript API Worker, which can call a Rust inference Worker, all within the same project, all traced end to end, all using the same Function-call semantics. The polyglot promise is a claim most frameworks make as a roadmap item. iii ships it today, with packages on npm, PyPI, Crates.io, and Go modules, all in active development with matching version numbers. The practical implication is that you can choose the language that fits each Worker without changing the composition model. Your agent logic can be Python because that is where the LLM ecosystem lives. Your API layer can be TypeScript because that is where your frontend team lives. Your performance-critical data processing can be Rust because that is where the throughput matters. They all register with the same engine and call each other the same way.
The risk profile is real and it is worth naming honestly. The project renamed itself eight days ago. The version number reset from a 1.0 RC to 0.19. The npm package changed names. The engine is Elastic License 2.0, which means you can run it, you can modify it, and you cannot offer it as a hosted service. The commit velocity is high but the contributor graph is concentrated. The bus-factor risk on a project this young with this much ambition is not hypothetical. This is not a framework you adopt because it is the safe choice. It is a framework you adopt because the architecture bets it makes are the bets you want to make, and you are willing to accept the cost of being early to a platform that might not exist in its current form a year from now. The honest framing is that iii is the most interesting architectural bet in the agent framework space right now, and also the one with the most uncertain trajectory. Those two things are not contradictory. They travel together more often than the ecosystem wants to admit.
The rebrand also raises a question about whether the project knows what it wants to be. Motia was a framework for building agent-enhanced backends. iii is a platform for composing every service in your stack. Those are different products with different audiences and different go-to-market stories. The rebrand could be a genuine expansion of scope that makes the project more valuable, or it could be a dilution that makes it harder to explain to anyone who is not already deep in the agent infrastructure conversation. The name change from a recognizable word to a three-letter acronym does not help the discoverability problem, and the “Motia became iii” story is one that every new visitor to the repo will have to reconstruct from context clues. The documentation at iii.dev is clean and well-structured, but the gap between “I heard about this thing called Motia” and “I am looking at iii-hq/iii” is a real friction point that the project has not solved.
The decision to ship the agent skills as installable reference material rather than embedding them in the engine is the kind of design choice that looks like an implementation detail but is actually a philosophical position. iii does not hardcode agent knowledge into the runtime. It treats agent knowledge the same way it treats developer knowledge: as reference material that is versioned, distributable, and updatable independently of the engine that executes the work. When a Worker’s API changes, the Worker’s skill changes. The agent does not need a new framework release to understand the new API. It installs the updated skill. This separation of execution from knowledge is the pattern that makes sense for any system where the surface area of available capabilities changes faster than the execution environment, which is to say, any system where agents are doing real work.
The practical question is whether you should use iii today, and the answer depends on what you are trying to build. If you are building a single-agent system that calls a few APIs and needs a clean function-calling loop, you do not need iii. You need Smolagents or Atomic Agents or a hundred lines of your own Python. If you are building a backend where multiple agents, multiple services, and multiple infrastructure primitives need to interoperate through a uniform interface with full observability and runtime extensibility, iii is the most coherent answer to that problem in the ecosystem right now. The polyglot story alone makes it worth studying, even if the licensing and maturity concerns keep you from adopting it. The architecture of Workers, Functions, and Triggers as the universal abstraction over backend primitives is a bet that may or may not pay off, but it is the right bet to be making at this stage of the agent infrastructure conversation. The frameworks that succeed will be the ones that treat agents as a natural extension of the backend, not a special case bolted onto a Python process. iii, for all its rebrand turbulence and licensing complexity, is the clearest articulation of that idea I have seen.
The repo is github.com/iii-hq/iii. The version is 0.19.2, shipped June 9. The npm package is iii-sdk. The engine is Rust under Elastic License 2.0. The SDKs are Apache 2.0. The docs are at iii.dev. It had 18,000 stars before the rebrand, and it is picking up more as the news spreads. The architecture is worth understanding regardless of whether you adopt the framework. The bets it makes about polyglot composition, runtime extensibility, and agent-developer parity are the bets the rest of the ecosystem will be making over the next twelve months. iii just made them all at once, in public, on a Tuesday.
If this was useful, forward it to one engineer who needs less noise in their feed.