What the agent can do | Borago Board

Where it runs

Inside your project's Docker container. Never on your host.

Every run executes in the project container. Beyond the one project folder you mount in, the agent has no access to the host filesystem, none to the host shell, and none to other projects' containers unless you connect two projects on purpose. On Linux with gVisor, the container's kernel calls are intercepted by a user-space kernel. Network access is the container's, subject to the project's network and, when container management is on, the policy proxy's rules. The desktop app is the only process that talks to Docker.

The tools

The same set on Claude, OpenAI, Grok, Gemini and self-hosted models, with the exceptions in the last column.

Tool	What it does	Limits	Providers
Shell	A shell inside the container that persists for the whole run. Working directory, exported variables and background processes survive between commands	A command that prints nothing for 5 minutes, or runs for 15 minutes in total, is stopped and the agent is told to run it in the background instead	all
File editor	View, create and edit files	Files inside the container only	all
Repository search	Search the repository's contents	Results are capped per search	all
Propose a task	Propose a new board task from inside a run	Capped per run and per family. Created in Planning	all
Investigate	An investigation tool that reads the repository and reports what it found	A few uses per run	Claude, OpenAI, Grok, Gemini. Not self-hosted
Web search	The provider's own web search	Capped per run. Counted in the run's cost	Claude, OpenAI, Gemini. Not Grok, not self-hosted
Read a web page	Read a page by URL	Capped per run	Claude, Gemini
Notebooks	Jupyter notebooks shown as cells and outputs	Read-only	all

Not available, and why. No access to the host filesystem beyond the project folder you point it at. No vendor command-line tools. No session resume between runs. Each run starts a fresh conversation and knows earlier runs only through what is on the task.

What it knows about your task

Your project's AI instructions, the task's title and description with mentions expanded, the tasks and notes you mention, a summary of related earlier work in the project, the previous attempt's output when it is a retry, and the attachments. Never the values of your environment variables. Those are available only inside the container when a command runs.

How it reports back

A run ends by saying how it went. The board turns that into what you see on the card.

Outcome	What you see
Done or Blocked	The card moves to that column with a short summary comment. Blocked also raises a notification
A question	A question comment with buttons for the options. The task waits for your answer and cannot be moved to To Do until you give it
Steps for you	Things only a person can do arrive as an action comment, a marker on the card and a notification
Follow-up tasks	Created in Planning under the original task, capped, then moved to To Do unless they need you first
Files	Files the run names are attached to the task
A reply	When the task asked a question rather than for a change, the answer is kept as a Reply comment
Tools it installed	Reported so they can be kept in the project's Dockerfile, with a notification offering the restart that applies it
No outcome declared	The card lands in Done with a note asking you to check the output, never silently assumed complete

How it is guarded

Time limits, spend limits, one run at a time, and an optional second model checking the result.

Per-command ceilings as above. A run that produces nothing for a while is ended and the task is Blocked with a comment. A per-project cost budget pauses the queue at a spend you set. One run per project. The board itself never runs anything a task says. Only the agent, inside the container, does. With Review the result after a run on, a second model reads the finished work against the task and leaves a comment when something is missing. It never re-runs anything on its own. Repeated failures stop rather than loop, and a rate limit, exhausted credits or a refused model pauses the queue with a sentence saying why.

How you steer it

Lever	Where	Effect
AI instructions	Project, AI instructions tab	Prepended to every run
Review instructions	Same tab	Tune both reviewers, never the runner
Service and model per role	Project, AI Roles tab	Which provider and model each role uses
Model per task	The card	Override for one task
Enhanced accuracy	Project, AI Roles tab	Higher effort plus a run checklist
Mentions	Task text	Point at tasks, notes, files, folders
Prerequisites	`@#n` in the text	Ordering the queue honours
Environment variables	Project, Environment Variables tab	Injected into the shell
Cost budget	Project	Pauses the queue at a spend
Container management	Project, Containers tab	Lets the agent run sibling containers under the policy proxy

The other AI roles

Role	What it reads	What it may do
Pre-run review	The task text	Ask questions, suggest a rewrite, flag a duplicate. Never edits, never blocks
Post-run review	The diff and commit log	Leave a comment. Never re-runs
Chat	The conversation, plus what mentions grant: repository read-only tools, task history, earlier chats	Propose tasks with size, effort and order. Never creates without approval
Flows	A flow's steps	Decide which steps are plain logic and which need a model each time, and write the code for the plain ones
Dictation	Audio, locally	Text into the composer, never sent

Writing tasks the agent can execute

For a person, and for an assistant drafting tasks on a person's behalf.

Make each task self-contained. The description is re-read every turn. Never write "as discussed above".
State the check that means done. "Tests pass." "The endpoint returns 200."
Split at real boundaries only. Each task pays its context again.
Declare order with @#n mentions, not prose.
Put secrets in Environment Variables, never in the task text.
Put repository-wide rules in the project's AI instructions, not in every task.
Prefer one command the agent can run to a paragraph describing it.