As we started using our own harness internally, one thing becoming obvious: putting multiple coding agents in tabs is not multi-agent orchestration. In our harness, Pi, Claude Code, Codex and even VS Code are workers on the same engine. A trigger can wake Pi, give it the workspace, let it do its part, then have its output or an event trigger Claude Code or Codex to continue the work. The interesting part is not that you can run every coding agent. It is that the harness can orchestrate them. Multi-agent should mean agents can trigger, call and hand work to each other. Not a nicer tab multiplexer.

a chat with an agent in harness can't be debugged only by transcript, I like to review code diffs of every sessions agent comes with. so we made sessions remember their changes: reopen any old conversation and everything it touched is still there, turn by turn. also you can click a line in a diff and land on it in the editor. small thing, use it constantly.

This is my other favorite screen. One scoped key-value store holds everything the system knows. The model catalog with context windows, pricing, and capability flags. Provider configs, approval settings, harness turns, memory banks. 17 scopes, all live. I can open any key, read the exact JSON my router reads, edit it, and save while agents are running. Granular visibility into state, in the same place the state actually lives.

Our harness and console is the most extendable ADE on the market. The console listens for new workers and automatically injects UI. Add the shell worker and you get real terminals, four split panes in a tab, sixteen sessions if you want them. A file tree, search, an editor. And a live view of what the last agent turn changed, file by file with diffs, hot reloaded while the agent is working.

Added a worker that reviews repos for security issues, and barely had to write any code for it. The worker uses functionality from other workers extensively - making it very DRY and low-maintenance: • dedup runs through state • durable steps use the queue worker • checkouts use worktree • schedules bind through the cron worker The actual review runs through harness::send, same as any other agent session, so the model is just a parameter on the request and I can swap providers at any point with a one-line change. It's nice to watch the session progress through the scan live in the UI. After it's done with the scan, it can open a draft PR straight from the findings. What requires a bunch of infrastructure and configuration elsewhere, is just another (tiny) worker.

I heavily use diagraming tools for architecting which means a lot of screenshotting and pasting. To make things simpler, I asked my harness to build itself a canvas worker. Now the agent draws the diagram right in the chat and console injectable UI.

The path from "agent did something useful" to production is getting crazy fast, even with cheap models. Even with GLM 5.3, my harness can discover a database worker, boot it, discover its live capabilities, clone a repo, read through the files, create the tables it needs, analyze the codebase file by file, and write the analysis into the DB while streaming status updates back into the chat or wherever else you want them. From there, take the chat context + traces from that run and one-shot it into a repeatable worker with a cron trigger. Move the deterministic parts into code, add tests, and now the thing the agent just figured out how to do is basically a production service. That loop is getting very short.

We just added an injectable page for watching all isolated VM sandboxes. It gives a live view into every sandbox, and you can click into each one and browse a VM's files while an agent is working in it. This UI isn't in the console by default, by the way. The sandbox worker brings its own UI with it, and the UI only shows up once the worker is up and running.

This is the screen I spend the most time in. Every worker that connects registers its functions with the engine in my harness, so there's a live list of everything the agents can call. 206 at the moment. The Injectable UI is just rendering that list. You can open any of them, see the schema, and run it by hand with whatever payload. So when an agent makes a weird call I open the same function, paste the same payload, and see exactly what it saw. Takes most of the guessing out of debugging these things. Also, install a new worker and its functions just show up here.

Sessions messaging each other is just shared state plus a trigger on writes. We didn't build the feature. It fell out of the architecture.

If you’re not using OpenRouter yet, you really should be. Being able to switch between free and paid models is clutch.

The goal is to put as little in the llms as possible. In most agent harnesses fetch normally dumps the whole HTTP response into context. Good for llm platforms, bad for everyone else. In the harness I am building the agent pipes it through a small lodash-style worker instead: fetch, extract the body, pick what it needs, return the subset. The 45,120-char response stayed server-side. The model read the 8,000 chars it asked for.

Andrej @karpathy gave Opus 5 the first paragraph of Lord of the Rings, a 1M token budget, and let it go for two hours. It came back with 5,500 lines of procedural JS that rendered the story. Cost around $10. We pointed the iii harness at the page and basically said: do this, but One Piece. DeepSeek V4 Flash made a 1,292-line HTML file in six minutes. Nine scenes, procedurally drawn ocean and storm, browser narration, audio, scrubber, all of it. Apparently the same token budget would cost around a dime on DeepSeek, which is kind of absurd. The harness starts by looking up what functions exist, inspect the contracts, fetched Karpathy’s page through the scrapling worker, figured out where it could write, created the file through the shell worker, and then ran node --check on its own work. None of that was built into the harness. It just discovered the workers and used them. DeepSeek was added the same way: $ iii worker add provider-deepseek That worker registers itself with the model router and pulls the current model list from DeepSeek. Nothing in the harness changed or really even knew which provider it was talking to. Still playing with this, but this is much closer to how I think harnesses should work. workers.iii.dev/workers/prov…

The frustrating thing about most AI harnesses is that they’re really hard to change. It owns the agent loop, context, plugins, model calls, everything. So the second you want it to work differently, you’re patching it or forking the repo. That never made much sense to me. In iii, the harness is just another worker. Sessions, context, model routing, queues, state, streaming, traces, shell access are all just workers. They’re all separate pieces using the same functions and triggers as everything else. You can hook into a turn, add context, change arguments, rewrite results, require approval, swap models, or replace parts completely, just using the primitives (Worker, Function, Trigger). No fork. No special plugin world. The harness is part of the system. It isn’t the system. $ iii worker add console harness

The idea of OpenWiki is cool: paste a GitHub URL, and a few minutes later you have a categorized, cross-linked wiki for that repo, including an overview, its architecture, an API reference, and links back to the exact commit and line range each datapoint came from. We built an OpenWiki-inspired iii worker to take this functionality, add production-grade observability and reliability, and massively reduce complexity and remove integration code. In our version, cloning the repo and listing files is done by iii's shell worker. Model calls run through the iii harness and the llm-router worker, so no vendor is named anywhere in the worker itself; point it at a better model and the wiki improves without a diff. Pages and the table of contents live in the state worker, which is why the console can see them without OpenWiki exposing an API for it. The browser UI served by the http worker. The worker spends its own code on the wiki functionality and rents the rest off the engine. The fan-out is where it gets interesting. OpenWiki starts one lead agent with repo-reading functions and permission to spawn, and the lead plans the pages and calls harness::spawn itself, one writer per page, in parallel. The delegation is the model's decision, not a loop we wrote. Three pages or thirty is a change in its judgment. Writers save through openwiki::write-page instead of reporting back up, so pages stream into the store as they land. That change to how the whole thing flows was one function. Refresh is a trigger. The engine fires it nightly, OpenWiki diffs against the commit the wiki was built from, and only pages whose sources moved get rewritten. No scheduler, no queue. Try it for yourself: workers.iii.dev/workers/open…

From how loop engineering is being talked about online, it may seem that there is just one way to do it right. But in reality, loop engineering is just a pattern.

Most agent memory is a black box. Something gets saved, something gets retrieved,you can't tell what it stored, why that surfaced, or point one chat at a specific set of memories. The iii memory worker is different. harness::hook::pre-generate injects the bank's rules plus the memories that match this turn harness::turn-completed runs one background extraction pass over the last few messages Everything is a file. rules/*.md and memories.jsonl, append-only, fsynced per write, one folder per bank. Open them in your editor. Every record carries the session it came from. Ranking is a formula you can understand: BM25, plus 0.6 per entity hit, plus 0.3 × ln(1 + corroboration), plus 0.75 if pinned, all decayed by a recency half-life with a floor so old-but-relevant records stay reachable. Embeddings fuse in when router::embed from llm-router worker has a provider, and every recall names the mode that actually ran: bm25-entity or bm25-entity-semantic. You can see a turn before it happens. Type a question into the console preview and it shows the rules and the exact memories that would be appended, in order, with scores. Same code path the live hook runs. Ones that didn't match but got in anyway are labeled ambient. Banks handle the rest. blog holds 32 memories, main holds 261. A session picks its bank, so the writing chat never drags in your infra context. Nothing is destroyed: deletes don't remove memories from the system, updates bump a revision. Consolidation is a separate worker that you can install, only if you need it: superseded-only, pinned records untouchable, and "always publishes" never merges with "never publishes".