Frequently Asked Questions

This is the intended use. An analyst writes a goal in plain language. Build plans it, breaks it into tasks, and works them. When it hits a decision it shouldn't make alone, the question appears on the project's Sessions page for the analyst to answer. No terminal, no command line. Project settings decide how much human review you want: wait before starting a goal, wait before merging, or both. An analyst can also file a report-style goal, such as "find out why the nightly sync drops records," which produces an answer rather than code.

Yes. Build works with products spread across many repositories: framework repos you build on, apps you maintain, community apps you install, integration services, and separate front ends that talk to external systems, all running on a dev server with a real database. The short version: connect the repositories you maintain and write to, run Build's agent in a Docker container on the same server or network as your dev environment so it can reach your database and other services, and let analysts write goals in plain language. The entries below answer each part of that question in turn.

No, and we recommend against it. Each connected repo passes a readiness gate before the fleet will work on it: toolchain, test tooling, write access, dependency install, and declared services. Start with two or three repos, get them green, then widen. The later repos are mostly repetition.

Yes. A Build project connects as many GitHub repositories as you need, and a single goal can span several of them. When a goal touches more than one repo it opens one pull request per repo, and the goal is only delivered when every one of those pull requests has merged. A change that needs both your main app and your integration app ships as one reviewed unit instead of two PRs you have to coordinate by hand. Connect the repositories you maintain and can write to. Foundation repos you never modify and community apps you only consume stay as dependencies that your package manager installs. They don't need to be connected.

A goal's preview runs on your own machine. If you already have a hosted dev server, the practical path is to make "deploy this branch to dev" a script or CI step the agent runs as part of the goal.

One agent on your dev server, your main app plus one front end connected, and three to five real goals written by an analyst. That surfaces the toolchain setup and database wiring in the first week. After that, adding the remaining repos is repetition.

Yes. Each repo carries a small pm-agent.yaml file that declares its test, type-check and lint commands and the services it needs. Build bundles throwaway Postgres and Redis instances for tests. For a service it doesn't bundle, such as MariaDB, you declare the host where it already runs. The agent health-checks that address and adopts it rather than starting its own. The agent can then work the way your developers do today: query the database, make a configuration change, and export it back into the repo. One caution: because that database is shared, run a single agent at first, or give each agent its own database, so two goals don't collide on the same data.

Build resolves Node and Python versions from what the repo declares, such as .python-version or .nvmrc. A toolchain with more moving parts, such as a framework CLI that needs a database client, Redis and a PDF renderer, takes a short setup pass inside the container. Every machine has an Open Terminal button for exactly that. Once a tool is installed it persists across restarts.

Build's agents run in a Docker container on infrastructure you control. Put that container on the same server or network as your dev environment and it can reach everything that machine can reach: your database, the external services your app talks to, and your running application. Credentials live in the container's environment on your machine. They are never written into a goal, a task, or a pull request, and they never leave your network.

Routers between Claude Code and the API often break Anthropic's prompt caching, so the full input context is billed again on every turn. In autonomous mode the router also asks the model what to do next on each turn, which resends the whole history. Build runs the Claude Code CLI directly on each fleet machine, so prompt caching works as designed. It also keeps orchestration decisions away from the model.

Each stage of a task starts with a fresh, focused context that holds only what that stage needs. No single conversation carries the whole job, so input tokens don't pile up the way they do in one long chat.

Build's own engine runs the project: task order, branches, pull requests and merges. The model doesn't make those calls. Routine CI failures are handled without calling the model, and a task can't be sent back for rework indefinitely. Tokens go to the coding work itself.