Agent-House: Multi-Agent Rooms for Practical AI Work

The useful idea was not “multi-agent chat.”

The useful idea was rooms.

Command. Research. Build. Review. Launch. Growth. Separate rooms for separate modes of work. Not because agents need cute departments, but because one overloaded conversation turns serious work into soup.

So we took the pattern and rebuilt it for our own Pi system.

agent-house is local operating structure. Command Center keeps the mission straight. Intelligence researches. Build Studio ships. Quality Gate checks the work. Launch Room publishes. Growth Lab watches what happens after the artifact leaves the bench.

The key piece is communication. The rooms coordinate through pi2picoms, so work can move between agents without becoming one giant transcript. A room can leave a handoff. Another room can inspect it, challenge it, build from it, or verify it. The system keeps evidence instead of vibes.

That changed the feel of the work.

Before agent-house, a complex task wanted to become one swollen session: research, build, test, deploy, summarize, remember. That is fine for small jobs. It breaks when the work needs depth.

Now the system has lanes.

Research can stay research. Building can stay building. Review can be hostile in the useful way. Launch can care about deployment and distribution without pretending to be the same job as investigation.

This matches the rest of the lab: local tools, inspectable files, plain handoffs, and systems shaped around actual work. Not a dashboard. Not a framework cosplay. Rooms, files, messages, receipts.

We borrowed the shape because the shape was right.

Then we rebuilt it for our own stack.

Author's note — June 4, 2026

We have built an additional room: product-design. The system now has 7 rooms total — command-center, intelligence, build-studio, quality-gate, launch-room, growth-lab, and product-design. Product Design handles UX architecture, AI role UX, trust and control patterns, design systems, and validation.

Lab update — June 16, 2026

Agent House now has a Demo Service: a Vercel-hosted frontend backed by Cloudflare R2 that turns intelligence room outputs into public web pages. The demo bridge includes an R2 upload queue, an HTML report generator that renders findings-first summaries with worker cards and artifact tables, and a Pi extension for submitting runs from inside a room session.

A demo_runner script runs intelligence rooms non-interactively — it starts the room via Coms, waits for the result contract, generates a report, and uploads it. Integration tests pass. The loop from "research this topic" to "here's a published demo page" is now a single command.

The command center also migrated fully into agent-house as its own room at /root/agent-house/command-center/, with a goal audit layer, interactive dashboard, and findings-first report writer. Rooms now ship results, not transcripts.

Lab update — June 18, 2026

Agent House now has a Model Router. Every room session classifies the task once with a zero-token keyword lookup — no LLM cost — then assigns the orchestrator and each worker the best model for their role. Research scouts run on DeepSeek, build workers on Codex, opportunity analysts on GLM, and the orchestrator on Codex. The routing decision is written to models.resolved.json in every run directory, and a route_workers tool plus /model-router command lets the orchestrator inspect the map and switch any worker's model mid-run. A fallback chain (Codex → DeepSeek → GLM → Kimi) keeps the room working through model failures.

The command center gained a Triage Room — a Kill Dashboard that makes the "what to keep, what to kill" conversation systematic. It scans opportunity cards, writes decisions to a SQLite board, renders a triage grid, generates weekly reports, and tombstones killed cards so the dreaming engine never re-proposes them. A triage analyst CLI supports record, render, and analytics subcommands, and a weekly cron report surfaces ship/kill/stale rates.

The agent CLI (bin/agent-house) grew interactive model selection (--interactive-models), a switch-worker subcommand for live model changes, and auto-recovery on worker spawn failure through the fallback chain.