Rooms: giving each agent a job and a place to stand

The problem with "just ask it anything"

A single all-purpose assistant sounds appealing until you live with one for a while and notice what goes wrong: it has no stake in any particular thing, so nothing quite belongs to it. You ask it about your website and it helps, but it has no skin in the game. Ask it again next week and you are starting over. The context is gone, the decisions it made are gone, and you are the one holding the thread.

This is the part that wore me down. I did not want a tool I had to manage. I wanted something that owned its corner.

What a room actually is

A room is a scoped Claude Code session with a permanent job. It lives in a directory, it has a CLAUDE.md that tells it what it owns, and it runs with access only to the things relevant to that job. The website room owns the website. It knows the repo, the design decisions, the content conventions, the deployment story. When I come back to it three weeks later it has not forgotten, because its context and its storage have not gone anywhere.

The key word is owns. Not "can help with" but owns. The distinction matters because ownership creates responsibility in a way that general availability does not. A room that is accountable for one thing will catch things a general assistant would let slide, because those things are specifically its problem.

The room model is how I turned AI from a conversation into a colleague.

Two rooms that show what this looks like in practice

This room (the website room): The most immediate example because it is literally writing this post. It tracks what is live and what is draft, it remembers the design decisions from three design passes ago, it knows not to touch the Hearth. When River hands it a task, it does not need a briefing. It already knows.

Hearth-dev: A room that owns the infrastructure that makes the household run. It maintains the Hearth's code, tracks what each MCP server does, knows which ones are fragile. This room has opinions. It will flag a pattern that looks like it will cause problems in three months. That is only possible because it has been paying attention to one thing continuously, not context-switching between everything.

Rooms can look very different from each other, and that is the point. A room is not a template. It is a scoping decision.

What the room holds that makes it real

When you describe "a room" to someone, they picture a chat window.

A room holds:

• Its own Claude Code session, continuously running (or restartable with full context via --continue)
• Its own CLAUDE.md: the permanent brief that grounds it in its job, its norms, its relationships to other rooms
• Its own storage: files, notes, drafts, decisions, things it has been asked to remember
• A clear set of permissions: what it can touch, what is off-limits

It does not hold everything. That is the design. The narrowness is what makes it useful.

The failure I learned from

One shape that happened: a room with too broad a brief. When a room tries to own two things that are slightly adjacent, you get a room that is half-committed to each and fully accountable to neither. Work falls into the gap. You end up being the glue again, which is exactly what you were trying to avoid.

The fix is usually obvious in retrospect: split it. Two rooms, each with a clear job, each with context that only ever grows in one direction.

What the rooms model is not

This is not micro-management of AI. It is not about writing exhaustive rules for everything an agent can do. A room with a CLAUDE.md that runs to forty pages of rules is a room I wrote, not a room that thinks.

The brief is a starting point, not a prison. The room builds on it. What makes the model work is the combination of scope (it owns one thing), continuity (it stays around), and the freedom to do what needs doing within that scope.

Next week

Because rooms keeping context between sessions is half of what makes them useful, and the other half is knowing what to remember and what to let go.