Docs / How your work runs

Botman Rooms.

How Botman runs your agents’ work on your own machine, safely. Each conversation, workflow run, and scheduled routine gets its own private, sealed space — a room — with everything it needs inside and a single, guarded way out.

one room per piece of work · files stay, secrets don’t · one door out
[00] The big picture/ The whole system, then the parts

The whole system, in one picture.

A message from you — or a tick of the schedule — reaches the control plane, becomes one job, and the runner on your machine opens the right room for it. Inside the room is everything the work needs; the only way out is its door. Everything below breaks this picture down, piece by piece.

botman — how work flows
WHERE WORK COMES FROM CONTROL PLANE · HOSTED BY BOTMAN YOUR MACHINE · THE RUNNER THE OUTSIDE WORLD Slack @mention in a thread Dashboard chat the Botman web app Discord @mention The schedule a routine’s time comes up message tick Your setup agents · workflows · routines projects · connected tools no code, no model or cloud keys Job queue one job = one task Allowed places what each piece of work may reach — set when you created it, not while it runs → becomes the door’s rules replies go back the way they came chat job workflow routine run chat can start a workflow or a routine CHAT ROOM one per conversation · wakes up for each message The agent answers you — or starts a workflow, or sets up a routine inside: the thread · team memory · your tools door: the tools you have connected WORKFLOW ROOM one per run · paused while it waits for your approval Steps run one after another in the same room — step 5 can read step 1’s files inside: the task · your code on a branch · results door: your repositories + that workflow’s tools ROUTINE ROOM one per run · lives a few minutes Runs the instruction and reports to its channel (or stays quiet) inside: the instruction · notes from last run door: only the sites named when it was created DOOR DOOR DOOR TOOLBOX shared · read-only · node · python · gh · claude available in every room only what the door allows credentials added here every request logged GitHub code · pull requests Slack · Discord replies, via Botman The AI model your provider Named websites e.g. preview.vercel.app listed when you created it
Left to right: a message or a scheduled tick arrives at the control plane, becomes one job, and the runner opens (or wakes up) the right kind of room on your machine. Inside the room is everything the work needs; the only way out is the blue door, whose rules were set when you created that piece of work.
  • room — a Docker container that lives as long as its piece of work
  • door — an Iron Proxy sidecar: allowed places only, real credentials added, every request logged
  • the runner — the one Botman program on your machine; it opens and closes rooms
  • toolbox — tools installed once, shared read-only by every room
  • control plane — your setup, the job queue, and the way replies get back
[01] Start here/ Six terms

Six terms from the picture, one line each.

[02] Three kinds of work/ Each gets its own room
Conversation a chat thread with an agent gets its own Chat room one per thread · wakes per message door: the tools you have connected DOOR Workflow run several agents, steps in order speccodetest gets its own Workflow room one per run · paused at approvals door: repos + the workflow’s tools DOOR Routine run a scheduled instruction EVERY MON · 08:00 → #product gets its own Routine room one per run · lives a few minutes door: only the sites you named DOOR
Each kind of work gets its own kind of room, and every room has its own door. The rest of this page is about that room and its door.
[03] Rooms and doors/ A Docker container, an Iron Proxy

Every piece of work gets its own room, with one door out.

A room is a Docker container — an isolated, sealed environment on your machine — plus a folder on disk, created for exactly one piece of work. The container starts with no special privileges, runs as an ordinary user, and has limits on CPU, memory and number of processes. It can see its own folder and the read-only toolbox, and nothing else on the machine: not the runner’s files, not any other room.

Every job for that piece of work runs inside the same container. So a conversation keeps its files and history from one message to the next, and step 4 of a workflow can open the files step 1 produced — nothing is copied around or re-explained.

Before rooms, every job started from a blank slate: a fresh container per chat message and per workflow step, files copied between steps, a conversation rebuilt each time from its last fifteen messages, and any tool the agent installed gone when it finished.

  • One Docker container per conversation, per workflow run, per routine run
  • Files, history and installed tools stay between jobs — secrets are never kept in a room
  • The container has one way out: its door
your machine — where rooms live on disk
botman/ rooms/ chat-slack-C0AB7…/ one conversation room.json this room’s settings home/ its history and anything it installed work/ where the agent works requests/ asks for new tools (see “Adding tools”) workflow-run-142/ one workflow run work/01-product-spec/ step 1’s files, on its own branch work/04-code/ step 4 can read step 1’s files routine-run-88/ one routine run · deleted when it reports toolbox/ tools shared by every room (read-only) workspace/ copies of your code repositories
INSIDE THE ROOM Agent holds a stand-in token only GITHUB_TOKEN = placeholder request 1 → github.com request 2 → pastebin.com IRON PROXY OUTSIDE github.com · allowed real token added here ✕ pastebin.com refused not on this job’s list every request → audit trail
door log — workflow run #142 · step 4 (code)
door up · allowed for this job: github.com, api.anthropic.com, registry.npmjs.org
github.com · clone · real token added at the door
api.anthropic.com · model call
registry.npmjs.org · npm install
pastebin.com · not on this job’s list
169.254.169.254 · cloud metadata address · always refused
github.com · push branch · open pull request
door down · job finished · 6 allowed, 2 blocked → audit trail

The door is an Iron Proxy.

A room cannot reach the internet directly. Its only way out is its door: an Iron Proxy sidecar — a second, small container that sits between the room and the outside world on a private network of its own. Iron Proxy is an open-source (Apache-2.0) egress proxy built for exactly this job: it refuses all outbound traffic by default, inspects HTTPS traffic using a certificate the room is set up to trust, swaps in real credentials at the boundary, and writes a structured log of every request. Botman pins an exact version of it.

So for every request an agent makes — fetching code from GitHub, calling the AI model, opening a web page — the door does three things:

  1. It only lets through requests to places that piece of work is allowed to reach. Which places those are was decided when you created the agent, the workflow, or the routine — not while it runs. Anything else is refused.
  2. It adds the real credentials on the way out. Inside the room, the agent only holds stand-in tokens. Iron Proxy swaps in the real GitHub token or API key as the request leaves — so an agent can never see, print, or leak a real secret.
  3. It writes down every request — where it went, and whether it was allowed or blocked — into your audit trail.

The door is started when a job starts, with exactly that job’s allowed places and credentials, and removed when the job ends. The room’s private network has no other route: no direct internet, no raw connections, no way around DNS, no cloud metadata address. A room with no job running can’t reach anything at all.

[04] The three kinds of room/ Chat · Workflow · Routine
RoomWhat it is forWhat its door lets throughHow long it lives
Chat One conversation or thread. Each new message wakes up the same room, so the agent still has the files it opened and the things it worked out last time. the tools you have connected — GitHub, Slack, Linear, and so on, through Botman Goes quiet when the conversation does, wakes on the next message, and is removed after 7 days without a message.
Workflow One run of a workflow, all its steps. Steps run one after another in the same room, so a later step can read an earlier step’s files directly — nothing is copied between them. your code repositories + the tools of the agents in that workflow — known the moment the run starts Until the run finishes or is cancelled, then removed 2 days later. While it waits for your approval, the room is paused, not deleted.
Routine One run of a scheduled routine — usually a few minutes. A small note carries over between runs (for example, what was already posted). only the websites you named when you created the routine + the channel it reports to Until it finishes and reports (or stays quiet when there is nothing to say). Then it is removed right away.
Chat room msg msg msg 7 DAYS WITHOUT A MESSAGE ✕ removed Workflow room step 1 step 2 PAUSED · WAITING FOR YOU step 3 step 4 RUN DONE · 2 DAYS ✕ removed Routine room runs · minutes REPORTS ✕ removed at once a job running — door up paused — door down
How long each room lives. Solid blocks are jobs running (door up); dashed stretches are the room paused (door down).
[05] A room’s life/ Opened · used · paused · woken · removed

What happens to a room, start to finish.

A room lasts as long as its piece of work. Jobs come and go inside it; the door goes up for each job and comes down after. Here is the whole life of a room, in order.

Opened first job Job running · door up files, history and installs stay job ends Paused · door down container stopped · no CPU, no memory next job wakes it · door up again past its time Removed 7 days quiet · 2 days after a run at once for routines
A room’s states. The loop in the middle — job ends, next job wakes it — repeats for as long as the piece of work is alive.
  1. Opened. The first job for a piece of work creates its room: the folder on disk and the Docker container. The container starts with no special privileges, runs as an ordinary user, and has limits on how much CPU, memory, and how many processes it can use.
  2. A job runs. Each job is a command run inside that container. Files, installed tools, and history stay in the room afterwards. The job’s temporary settings — including the stand-in credentials — are gone when it ends.
  3. Door up. When a job starts, its Iron Proxy sidecar is started with that job’s list of allowed places and its credentials. Every outbound request — fetching code, pushing a branch, calling the model — goes through it: allowed or refused, credentials added, and written to the audit trail.
  4. Door down. When the job ends, the door is removed. A room with no job running cannot reach anything.
  5. Paused. When a room has no job running, its Docker container is stopped. Nothing is lost — it just uses no CPU or memory. A workflow waiting for you to approve a step is a paused room.
  6. Woken up. The next job starts the container again. A chat room continues the same agent session, so the agent still remembers what it opened and did. If that session can no longer be found, the agent starts fresh with the thread’s history as its brief.
  7. Removed. A tidy-up runs regularly and removes rooms past their time: chat rooms after 7 days without a message, workflow rooms 2 days after the run ends, routine rooms as soon as they report. It removes the door, the container, and the folders. A room with a job running is never touched. When the runner itself starts, it first closes every door and pauses every room, because no job can be running yet.
a chat room — what it can and cannot see
read & writeIts own folderits history, its working files, its tool requests
read & writeYour code repositoriesworkflow rooms and code jobs only, on their own branch
read onlyThe toolboxNode, Python, the GitHub CLI, Claude Code — shared by every room
read onlyThe certificates that let it trust the doorso tools like git, curl, Node, and Python go through it
neverThe runner’s own files, any other room, any real secretreal credentials live at the door, never in the room
the container no admin rights · runs as an ordinary user · limits on CPU, memory, and processes
the network a private network of its own — the door is the only address it can reach
[06] What every room is given/ Inside the room

Everything the work needs, nothing it doesn’t.

[07] Adding tools and using a browser/ Still inside the room
workflow run #142 · step 5 (tests) — the agent’s terminal
botman-tools install node
→ request written to requests/ · the runner is installing it
node 22 is in the toolbox · available to every room
botman-tools npm playwright
→ installing in a throwaway container that can only see the toolbox
playwright is in the toolbox
apt-get install ffmpeg
not available inside a room — use botman-tools instead
browser: opening app-preview.vercel.app through the door

Installs and browsing stay inside the room.

The toolbox is read-only inside a room, so one session can’t change what other rooms run — and a package’s install script never runs on your machine itself. When an agent needs a tool, it asks with a small command, botman-tools install node (or botman-tools npm <package>, botman-tools pip <package>). That writes a request into the room’s requests/ folder — the one and only channel from a room to the runner, and it carries nothing but names.

The runner sees the request and installs the tool while the agent waits: well-known tools through pinned installers, npm and pip packages inside a temporary container that can see the toolbox and nothing else. The result lands in the toolbox, ready for every room, and it is still there long after the session that asked for it has ended.

A browser works the same way. When a testing agent uses one (Playwright, driving a Chromium inside the room), it runs inside the room and every page it loads goes through the door. Which websites it may open comes from your project’s test address and the run’s own deployment previews — set by Botman, never chosen by the agent on the spot.

  • No system-level installs inside a room — the toolbox is the only way to add a tool
  • A tool installed once is there for every room, and outlives the session that asked
  • The browser is limited to your project’s sites and its previews
INSTALLING A TOOL Room botman-tools install node writes a small request file request Runner reads the request, installs the tool npm/pip: in a throwaway container installs Toolbox node · python · gh playwright · claude read-only Every room tool ready to use outlives the session USING A BROWSER Room Playwright drives a Chromium inside the room DOOR Your project’s sites only the test address · the run’s previews ✕ any other site refused
Top: a tool request leaves the room as a file, the runner installs it into the shared toolbox, and every room sees it read-only. Bottom: the browser lives inside the room and can only reach your project’s sites, through the door.
[08] Follow one message/ Start to finish

From a Slack message to a finished pull request.

Every step below happens inside a room, and every request to the outside world goes through a door. Replies come back to the thread you started in.

  1. You mention Botman in a Slack thread: “ship the invoice export.”
  2. The control plane records the message and queues a chat job for that thread’s room. The runner opens the room — or wakes it up — with the thread, your team memory, and your connected tools inside.
  3. The agent decides this is real work and starts the Feature development workflow, then replies in the thread with the run number.
  4. The control plane fixes what this run may do and queues its first step. The runner opens a workflow room with your code on a fresh branch and a door that allows GitHub plus the tools of the agents in this workflow.
  5. The steps run one after another in that room — spec, architecture, design, code, deploy, tests — each reading the earlier steps’ files. When a step needs your approval, the room is paused until you approve in the dashboard or in Slack.
  6. Every outbound request — fetching code, pushing, opening the pull request, calling the model — goes through the door: allowed, given its credentials, and logged. The finished pull request is posted back to the thread.
You (Slack) Control plane Chat room Workflow room Door GitHub 1 · “ship the invoice export” 2 · chat job · wake the room 3 · start “Feature development” reply: run #142 started 4 · step 1 job · workflow room opens · your code on a fresh branch 5 · clone · push real token added · logged 6 · step needs approval · room paused until you approve in Slack
The same six steps as a sequence. Time runs top to bottom; the blue bar is the workflow room’s door.
[09] Worth knowing/ Three rules
Two limits todayRunners installed before rooms became the standard keep running the old way until they are reinstalled. And jobs that need the native AWS or Google Cloud command-line tools are refused inside a room for now — those tools need real cloud credentials in the room, which the door is designed to prevent; a safe path for them is in progress.