Written for Teams pointing coding agents at a Bazel monorepo.
What problem it solves
An agent faces the same problem a new hire does, minus the ability to ask anyone.
How do I run the tests? Lint this? Regenerate the BUILD files? Every repository answers differently, through a pile of scripts that are undiscoverable, undocumented and slightly different everywhere. A new engineer asks someone; an agent has nobody to ask, so it guesses, infers from CI config, or does nothing.
Then the harder half. When the build fails, the agent needs to know why, and the only thing available is unstructured log text it has to guess at. So it retries blindly, burns compute on a wrong hypothesis, or escalates to a human, which erases the throughput gain that justified the agent.
Details that matter more to a machine than to a person
Failures that are only yours
Lint fails only on violations the current change introduced. Pre-existing findings stay visible and don’t fail the task.
For a person that is a convenience. For an agent it is the difference between a usable signal and an unusable one: an agent evaluating its own work against a repository with years of accumulated lint debt can’t tell its mistakes from the inheritance. Scope the failures to the change and every failure it sees is its own, so the signal is actionable without a human triaging it first.
Why we built it
Customers asked for the API and MCP by name.
The teams furthest along with agents hit this wall first, and they asked for machine-readable build truth before we offered it.
- Not an AI product, and not an agent. We don’t generate code. We make the build and its results legible to whatever is generating it: yours, ours, or whatever you switch to next year.
- Not lock-in. The CLI is free and open source and works on any Bazel repository, with or without the rest of our platform.
- Not a chat interface on top of your build. It is a command surface and an API.