iii

Have you ever used an agent like this?

We just released observers and they do something fascinating: global, domain-agnostic reactivity across your entire application stack.

Out now in iii: agents that wait without polling. Instead of burning tokens checking whether an install finished, or a "monitor" CLI command returned correctly, the agent sets an observer and stops. When the observed action happens it's automatically woken back up.

While building iii we never had an agent delete a production database. We did spend a lot of time worried it might. Undo and git only cover local files, and we kept picturing a call running before we finished reading the error. Approval cycles didn't work, so we took a multi-tiered approach to agentic security and focused on the "reversibility" of each action. When an action was highly reversible it can always run, when it's recoverable we keep a record, and when it's irreversible we have multiple gates to prevent agent and human error. https://lnkd.in/gyxXXx65

One thing we kept seeing with multi-agent setups is that every team rebuilds the same scaffolding. Someone writes a researcher prompt, someone else writes a reviewer, someone else makes a useful service, and they need a shared place to track work, and none of it is versioned, so nobody knows what changed when it starts behaving differently. Kits on workers.iii.dev package that up. A kit bundles agent profiles, their skills and the services they depend on, pinned by version range, and installs with one command. The one in the film is kanban-team: four profiles that run a small product team on top of a kanban board. A researcher owns the brief, a product manager owns the plan, a tech lead breaks it into slices, and a reviewer checks the acceptance criteria. It’s out now.

While building iii we kept running into the same thing after a deploy. Something gets slow in production, and the coding agent that wrote the code can't see or remember any of it. So you open a tracing dashboard, find the request, copy the spans into the chat and explain what you're looking at. In iii every call is traced by default, with no tracing code to write. A request that goes from an agent in your browser to an HTTP handler in Rust to an orders service in Python to a database call is one OpenTelemetry trace. The part we're most excited about is that traces and logs are functions in iii, so the agent can query them like anything else. In the video we ask which step of the last POST /orders took the longest. The agent pulls the span tree itself and comes back with the database insert, 4.9ms of a 6.88ms request. That's the development loop we've been building toward. The agent that helped you write the code is still useful once it's running in production, because it can see what's actually happening there. It's out now.

Your coding agent writes the code. Then it stops at deployment. When production breaks, you paste the logs into a new chat with no history and explain everything again: the handler, the deploy setup, the context. Some agents do ship it for you, but inside their walled garden. Their runtime, their database, their auth, their hosting. So far, that's been the choice: friction at and after deployment, or move into someone else's platform. iii doesn't make you choose. Develop: build with an agent in the iii ADE. Every function it writes routes through the iii engine, and every call it makes is traced. Deploy: ship the same engine. Same functions, same triggers, nothing to rewrite. Production: the agent is still there, and it sees the same traces it saw in development. When checkout starts returning 500s, it reads the trace, finds the failing function, writes a fix and a test, then asks for your approval. You approve, it ships. Production feeds the next change. One loop, one system, on your own infrastructure.

We have added an incredibly powerful tool to iii: observers and they solve an all-too-common problem in software: Want a ping whenever an order over $500 comes in? Usually you'd edit the order provider, rebuild, test, and redeploy. What about when a request errors? Same flow, and same maintenance burden. Eventually you'd integrate other system(s) to handle events, error reporting, and plenty more. This is one of many growing pains every project goes through. We wanted to avoid it from the start. So now in iii 0.25 you can observe any function inputs, outputs, and errors. In any language. From any service. Want to know when anything happens? Define an observer in your business logic, and leave your other services alone. And we improved our execution overhead (1.9 μs -> 1.3 μs).

We were getting tired of massive inference bills. Most of it was agents rereading context, calling --help again and retrying payloads they guessed wrong, so we’ve been squeezing that out of iii. A feature on DeepSeek Flash now costs about ten cents, and on Claude is 24% cheaper. https://lnkd.in/gxUK9nEQ

Linear, Jira, Trello, GitHub Projects, Multica, every coding agent. Same kanban board, rebuilt every single time. We recorded one of our team members building a PR review app in the iii ADE, start to finish, in about an hour. The first prompt asked for org and repo selection, a PR list with filters, per-file review marks in SQLite, agent questions on selected lines, and local worktrees. 5 minutes later it was running, using the database and github services that were already there. Twenty minutes in it needed a kanban board. It found one, added it, and it was working immediately. No integration, no different languages, no figuring out HOW to integrate it. Over that hour the agent wrote 19 files, +3,044 lines, every single one focused on the task at hand: the PR review app. Nothing else needed to change. The kanban service was still pinned at 0.1.20. Sergio built the board, the whole team extended it, and every app that composes it gets ongoing improvements automatically. Need a database? iii trigger compose::add worker=database. A browser, a queue, a cron, an HTTP endpoint? Add them. 101 workers on our registry.