Not a Better Model, a Better Way to Run Agents: Show HN's MIKE Pairs a Kanban Board with gVisor Sandboxes

Building another shell around a coding agent is no longer news. What is news is a good reason to install one more. MIKE (MIKE: Integrated Kanban Environment), posted to Show HN on October 18, answers with two things that are harder to copy than a chat box: how agent work is managed, and how hard the sandbox is that agent code runs in. Version 0.1.0 was released on October 15, it is Apache 2.0-licensed and self-hosted, it organizes agent work on a kanban board, and it confines agents with gVisor sandboxes.

First, get the timeline right, so this is not told as an overnight success story: the MIKE repository was created back in June 2026. The v0.1.0 release on October 15 and the Show HN post on October 18 are the moment it was widely noticed, not the moment it was born. A project that spent four months before cutting its first numbered release is a different credibility proposition from a weekend demo — and that is a question worth asking of any Show HN project: is it new, or newly visible?

The board is not a skin; it is a judgment about agent work

MIKE's core interface is a kanban board: you write tasks as cards, assign cards to agents, and review what agents deliver on the board. According to the October 18 open-source tools roundup, each agent runs inside a gVisor sandbox with a git worktree as its workspace and a read-only repository mount for context; extensions are isolated through iframe sandboxing and wazero. What matters here is not the word "kanban" but the work model it implies: agent tasks are discrete, bounded, and individually reviewable, rather than one endless conversation.

That runs against the default shape of most agent tools. The problem with chat-based agents is not that they cannot write code; it is that work state scatters across chat history — which task is at what stage, which change awaits whose review, which agent is waiting on you — all left to human memory. A board externalizes that state into cards you can scan at a glance, turning "I have many agents running" from a feeling into a picture. For anyone running several agent lanes at once, that is more useful than another chat window: it solves management, not writing.

The board also has a cost. It fits work with clear boundaries — fix a bug, build a feature, run a refactor — and fits exploratory work poorly, where the goal itself keeps shifting before the card is even finished. MIKE's bet is that as agents move from "write me a snippet" to "advance a pile of tasks," task management stops being an accessory and becomes the main interface. That bet may not hold for everyone, but at least it is a bet, not another chat box.

The gVisor sandbox is the real selling point

Judged only on "kanban plus agent," MIKE is easy to file under "yet another harness" — the author himself acknowledged in the Show HN post that he was joining the everyone-builds-a-harness bandwagon. What lifts it slightly out of that wave is the depth of its sandboxing. According to the repository README, MIKE uses gVisor for strong sandbox isolation; extensions go through iframe sandboxing and wazero; the front end is a Progressive Web App optimized for spotty networks, aiming at low-bandwidth and offline use; and on the model side it works with llama.cpp local models and any inference provider supporting the OpenAI Chat Completions API.

Why does sandbox depth deserve its own section? Because agent privilege is moving from theoretical risk to everyday cost: an agent that can run shell commands, read files, and call APIs holds most of your account's power by default. Many harnesses claim isolation by putting the agent in an ordinary container, but container-escape news never stops; gVisor's approach inserts another kernel, written in Go, between the application and the host kernel, so the application's system calls pass through that layer instead of reaching the host kernel directly. It is not a new invention, but shipping it as a self-hosted harness's default posture rather than an advanced option is a different attitude: it treats the agent as an untrusted executor by default, not as a well-behaved assistant.

The README also lists several "invisible" engineering details worth noting. With many parallel tasks, builds and tests eat memory, so MIKE monitors usage and automatically pauses and resumes tasks; it exposes a REST API with enforced encryption, bearer tokens, rate limits, and authorized hosts; against inference-provider failures — failed tool calls, loops, crashes, rate limits — it stresses that progress is recoverable rather than lost; and for enterprise deployment, administrators can lock configuration, preventing extension installation and inference-provider changes. None of these is glamorous alone; together they describe a product character: not a toy for trying an agent once, but a tool for keeping many agents running over time.

Three caveats: the privileged container, the 0.x API, and the real cost of self-hosting

First, the most interesting irony. MIKE's quick-start runs it in a container, and to support nested containers that quick-start command needs privileged mode. The README itself notes that privilege is only needed in this containerized quick-start path, in order to support nested containers. This is not hypocrisy — nested containers genuinely need it — but it means there is a gap between "isolation out of the box" and "the most secure deployment by default." Serious deployments should take the manual path and configure gVisor and Podman for their own environment, rather than treating the quick-start command as a production setup.

Second, version honesty. The README states plainly that no stable API or extension interface is guaranteed until version 1.0. Read that as a virtue: it warns you up front that anything built on its API and extensions may need rework later. It is also an adoption signal — if you plan to wire MIKE into team workflows with lots of automation scripts, budget for interface change now; if it is personal experimentation, it is not a problem at all.

Third, self-hosting is never free. One of MIKE's selling points is that data and keys stay on your own machine: agents and provider keys need not pass through a third-party hosted service, and login uses passkey pairing (the README notes that, as of October 10, 2026, Firefox on Linux has limited passkey support). The other side is that sandboxing, updates, backups, and troubleshooting are all yours. Compared with turnkey hosted agent services, MIKE saves you the worry of handing code and keys to someone else and costs you your own operations time. Everyone's arithmetic comes out differently; the point is to do the arithmetic, not to stop at "self-hosted equals secure."

How it relates to October's durability conversation

MIKE is worth placing on one of October's threads. This site previously covered Vercel's open-source durable-harness (cycle97): adapters that bolt persistence onto existing harnesses so a crashed session resumes from a durable log. MIKE's "Durable Progress" is a different layer: within a single harness, progress survives provider-side failures such as failed calls, loops, crashes, and rate limits. Both use the word "durable," but one is cross-harness resume from a log and the other is in-harness failure recovery — not the same product, and neither replaces the other. What is interesting is that October's agent-tooling conversation is shifting from "how strong is the model" to "how reliable is the system": what happens on a crash, on a rate limit, when parallel tasks exhaust memory. MIKE and durable-harness arrive at the same question from different directions, and that convergence is itself a signal: agent tooling competition is moving from demo quality to engineering substance.

A judgment for vibe developers

MIKE is worth an afternoon's trial if any of three conditions holds: you already run several agent lanes and managing tasks through chat history is getting painful; you want agents to run locally or on your own server, with code and keys kept away from third parties; or you take the premise "agents are untrusted by default" seriously and are willing to pay some deployment cost for sandbox depth. The sensible trial path is: get the container quick-start running, confirm the board workflow suits you, and only then decide on a manual deployment with gVisor and Podman configured properly.

Conversely, if you only occasionally ask an agent for a snippet or a single-file change, or your work is exploratory with goals shifting daily, MIKE's board and sandbox are likely over-engineering — a lightweight agent plus a good AGENTS.md file will serve you better. The most common waste in tool selection is not picking the wrong tool; it is paying early for scale you do not yet need.

Finally, a word on this Show HN harness wave. The author openly admitted to joining the bandwagon, and that honesty makes MIKE more credible, not less: it does not pretend to have invented agents, nor that kanban is a brand-new idea. Its bets are specific — tasks should be managed as cards, agents should live by default in a deep sandbox. Whether those bets pay off depends on how agent work evolves over the next year: whether it stays conversation-led or truly becomes a pile of parallel tasks to manage. Version 0.1.0 at least turns that question into something you can try with your hands instead of an opinion piece. That is enough to earn one Show HN appearance — and one article here.