AI Agent

What an AI agent room is

An AI agent room is a room whose occupant is an agent rather than a set of documents or cards. It holds the agent's conversations, the material it has been given, the tools it may use, and every run it has done.

Connect a repository and it becomes a build room: describe a change, or hand it a story off a Kanban board, and it edits files, commits on a branch and opens a pull request. It never merges.

The workflow itself is covered in The build agent; this page is about the room.

Add an AI agent room

1. In the space's sidebar, click + and pick AI Agent.
2. Name it. If you will have more than one, name it for what it builds — "Website", "API", "Mobile" — and put them in different sidebar sections. Two agents in a space are routinely named for the same thing, and the name alone gives the next person no way to tell them apart.
3. Set visibility as with any room.

A room needs the organization's AI configuration settled before its agent can do anything: either a provider key of its own in self hosted mode, or the switch set to managed. See AI configuration.

The rail

Everything the agent works with is in the room's left rail:

Panel	What it holds
Chats	Conversations with the agent, each its own session
Knowledge	Reference material: what is true about your system
Skills	Reusable instructions: how to act
Workflows	Recurring and triggered automations
Actions	Custom tools you define
Integrations	External services the agent may use
MCP	Tool servers you connect
Assets	Files the agent produced that are not code
GitHub / GitLab	Repository connections
Settings	The room's configuration

Knowledge and skills are covered in Workflows, actions & skills; tools in Agent integrations and MCP servers.

Settings worth knowing

• Repository and base branch — which repository this room builds in, and which branch its working branches are cut from.
• Autonomy — the four-rung ladder from plan-only to unattended.
• Step limit — how many steps a run may take before it stops and reports. The default is 80; the range is 4 to 200.
• Token budget per run — an upper bound on the tokens one run may use, up to 10,000,000. Input, output and cached input, counted the way the token allowance counts them. A run that reaches it stops at a turn boundary and keeps its work. 0 means no cap. This is the setting that bounds a scheduled workflow nobody is watching.
• Verification runs — 0 to 3 checking passes over each result. A dissent sends the run to approval rather than failing it.
• Backend — the single in-process agent, team mode, where a coordinator splits the work into a small graph of tasks that run in parallel, or a Codex subscription run on a personal agent's connected ChatGPT plan.
• Connected agent — whether this room inherits its instructions, permissions and limits from a reusable agent instead of holding its own. See Reusable & personal agents.
• Shared sessions — whether any member reads and joins the room's latest conversation, or everyone keeps their own.
• Board, start column and done column — which Kanban board this agent takes stories from and where it moves them.

Connect it to a board

A Kanban board can name one agent room. Open the board's settings, choose Agent, and pick from the agent rooms in that space — the picker groups them by sidebar section so two similarly named agents are distinguishable.

Once connected, @agent in a card's discussion reaches that room's agent, one shared conversation per card. The agent replies in the same thread, so the discussion is the transcript and nobody has to open the agent room to follow what happened.

A board can only be pointed at an agent room in its own space. Reopening the dialog offers to disconnect, so the same button is the whole relationship rather than a one-way door.

One agent, several rooms

Everything above is this room's own configuration. If several rooms should share one job description, save it once as a reusable agent in the workspace's Agents directory and connect it here instead. The room still keeps its own conversations, its own repository and its own permissions — only the instructions are shared, and this room can narrow anything the agent asks for without being able to widen it.

Runs across all your rooms are listed together under Agent activity in the workspace sidebar. Both are covered in Reusable & personal agents.

Who can see it

Sessions in the room are private to the person who started them, unless the room has shared sessions switched on. Beyond that, the space's owner and admins — and the organization's owner — can read every session in the room, and the organization's owner and admins can read every agent conversation in the organization from Organization → Chat logs.

Tips

• One room per repository. Knowledge, skills and integrations are per room, and they are most useful when they are all about one codebase.
• Set the per-run cap before the first scheduled workflow. It is the only bound on an unattended run.
• Start on "Ask before committing". Watch a few runs, then loosen. Going the other way — discovering in the pull request list what unattended meant — is more expensive.
• Put the acceptance criteria in the card's checklist. It is what the agent builds against, and what the verification pass checks.

FAQ

Does the agent run my code? No. It reads the repository, edits files, commits and opens a pull request. Your own CI runs the tests on that pull request.

Can it merge? No. Merging is always a human decision in your code host.

What does a run cost? It depends on the organization's mode. In self hosted mode it runs on your organization's own provider key, your provider bills you directly, and nothing is metered or capped by the platform. In managed mode it runs on the platform's key and every token counts against the organization owner's token allowance, shared across every Bookbag product — and a run that starts when the allowance is spent is refused before any provider is called. Credits no longer exist. See AI usage & the token allowance.

Can I have more than one agent room in a space? Yes, and it is the normal arrangement when a team owns several repositories. Each board points at one of them.