I gave AI agents a 1995 chat room, and Kiro helped me build it

I am a frontend developer from Indonesia, and I did not expect that a chat protocol from the 90s would become the best permission system I have used for AI agents. This post was written as part of the Kiroween 2026 hackathon. My teammate Fandy Rahmat Saputra and I built two projects for it, and this is the story of the first one and how Kiro shaped the way we worked.

What Séance is

Séance is an IRC server and a web client styled like a 1995 desktop OS. Every AI agent is a user in a channel. You run the team with /invite, /mode, /kick and /topic. Behind each agent is a kiro-cli acp process, and each channel is a git worktree.

The idea is that IRC already answers the two questions most agent UIs hide: who is allowed to act, and what is happening now. A new agent joins with no mode and can only listen. +v lets it speak. +o lets it edit files, commit and run shell, only inside its worktree. /kick is an exorcism: the session is cancelled and the worktree resets to the last commit. /whois coder shows the model, tools, status and credits used. It entered the Resurrection category because the protocol was dead and now it is the control plane.

You can try the live demo or watch the 3 minute video.

How Kiro fit into the work

Séance uses Kiro in two ways. It is built with Kiro, and it runs on Kiro, because every agent in the channel is a Kiro CLI session driven over ACP.

Specs and tasks

Every feature started as a spec in .kiro/specs/<feature>/: requirements in EARS form, a design, and a task list. We ended with 14 specs and 764 ticked tasks. Writing requirements before code is slower at the start; it pays back when the code meets something real.

The design documents contained correctness properties, for example parse(serialize(m)) == m for IRC messages. Those turned into fast-check property tests. The parser, the permission handler and the exorcism flow all worked the first time they met a real client, and I credit that to the properties existing before the code did.

Another habit I picked up: review findings did not become loose bug tickets. They became follow-up tasks inside the same spec, with the reason written down. In the web client spec, tasks 10.20 to 10.23 cover a silent WHOIS and the per-channel credit counter, each with a note on why it was added.

Steering

The steering files in .kiro/steering/ are the part I use most as a frontend person. Four are always on: product, tech, structure and security. Four apply to certain paths: irc-protocol.md, runner-acp.md, web-ui.md and testing.md. The protocol file kept numerics exact to RFC 2812. The web UI file kept the retro desktop and ghost design system consistent across screens. The security file kept agents inside the repository. I stopped repeating the same instructions in every prompt.

Hooks

We set up four hooks: guard-shell, test-on-save, verify-after-task and kiro-usage-log. The log hook appended to our build log at the end of each turn that changed the repo, so the write-up for this hackathon came partly from the tool itself.

guard-shell earned its place on 2026-11-08 with this message: Blocked by .kiro/hooks/guard-shell: path "/tmp" resolves outside the repository root. An agent had tried to write outside the repo. That was a small moment, but it is exactly the kind of mistake that slips through in a long session.

ACP as the runner

The first thing we did was a spike: can Kiro agents be driven headlessly over kiro-cli acp? They can, with several sessions per process. That spike removed the biggest risk of the project before we wrote the server. After that, the runner treats Kiro's session/request_permission as the enforcement point. A write or shell request from an agent without +o is rejected, and so is any path outside the worktree.

What failed

The honest lesson: we assumed the tests were the whole world. They were not.

Three bugs only appeared on the real server. The /home/agent tmpfs inside the sandbox was owned by root. Node 26 shipped without corepack. The node binary needed libatomic.so.1. Our tests used a fake Podman and tests that only read the Dockerfile, so none of them could see these problems.

What worked was going back to the spec. Each bug was written down as a new requirement first (task 21.x in the sandbox spec), then fixed in code with a test that pins it. The bootstrap script now rebuilds the image whenever the sandbox context changes. Spec-first helped most where correctness mattered, and it did not protect us from facts about the real machine. Only running it there did.

Séance Crew

The second project is Séance Crew, a Kiro Crew app that makes Crew the foreman of Séance channels. One Node backend keeps a single WebSocket to the Séance server and exposes eight MCP tools: list_channels, read, say, summon, grant_op, exorcise, whois and credits. It also serves a dashboard page with channel cards, commits, credits and a "Needs op" inbox for agents that were denied an action.

There is a seance-steward agent that auto-approves only the four read-only tools. Granting op or exorcising asks you first, and the dashboard shows a confirmation dialog with Cancel focused. All channel text is treated as untrusted data. We built it with five specs, five steering files and two hooks.

Closing

If I had to say one thing about Kiro from this month: it changed what I do before I type code. I write down what must be true, and then I let the tools check it. For a frontend developer used to tweaking CSS until it looks right, that was a real change.

Séance is open source under MIT. Try the demo, read the Séance repo, or look at Séance Crew. Feedback is welcome.