BlueCrow Forge
An engineering agent that works in the repository, under rules you set
Forge reads code, answers questions about it, makes changes, and verifies them by building and running the tests. It is built around two ideas: that you decide how much it is allowed to touch, and that it should never tell you something it did not actually go and check.
What works today
Three modes, and the mode is binding
Read Only, Edit, and Commit. You choose which one from the main window, and the choice is what the session actually runs under — not a label. In Read Only, editing, building and committing aren’t merely discouraged: those tools are never offered to the model, and nothing can escalate past the mode you picked.
Provider-flexible reasoning
Forge is the agent; the model is a backend. It runs on a local Ollama model, on Anthropic’s Claude, or on OpenAI — selected from a menu, with an explicit priority order when you leave it on Auto. Nothing in the agent, the tools or the safety rules changes when you switch.
Runs entirely on your own machine
With a local model, Forge needs no account, no API key and no network call to anyone. The hosted providers are there when you want a stronger model for a harder task, never as a requirement.
Repository and workspace tools
Search by content or by file name, read files, and list directories — all confined to the workspace you opened. Paths are validated against that boundary rather than trusted.
Git, build, and test
Status, log and diff for understanding a repository; compiling and running the test suite for verifying a change. After an edit, Forge builds and tests before it calls the work done.
Evidence-grounded answers
Forge is required to actually look. If a task names a file, that file must be opened before an answer is accepted — including every file, when a task names several. A read that fails is evidence too: asked about a file that doesn’t exist, Forge says so rather than describing what it assumes is inside.
Checkpoints before it changes anything
Edits are preceded by a checkpoint, so a change that turns out wrong can be undone rather than argued with.
Sandboxed Python
For the jobs a language model does badly — arithmetic over a file, parsing a CSV, reshaping JSON, a quick chart — Forge can run Python in a restricted environment: no network, no spawning other programs, file access limited to the workspace and a scratch directory, a time limit, and a cap on output.
A capability list it can’t overstate
Forge knows what this machine actually has. Each capability reports whether it’s available, what mode it needs, whether it can change files, whether it needs the network, and whether it can cost money — so Forge doesn’t offer something that isn’t there.
How it stays honest
Checked work, not confident work
The hard part of an engineering agent is not making it capable. It is stopping it sounding capable when it is wrong. Forge is built so that an answer has to be earned: the file has to be opened, the build has to pass, the tests have to run. Where something could not be established, the honest answer — that it could not be established — is a result Forge is allowed to give, rather than one it is pressured to talk its way out of.
In development
Being clear about what isn’t finished matters as much as showing what is.
- Visual asset generation — the provider-neutral seam is built and works end to end, but it currently produces local placeholder images. No hosted art service is connected yet.
- Training is ongoing. Forge is graded on unseen tasks against a predetermined answer key, and every defect that grading finds is fixed with a regression test behind it. That work is active, not finished.
- Longer autonomous work. Forge handles multi-step tasks that read and reason across several files; extended unattended sessions are deliberately not something it does yet.
- No installer or public download. Forge is currently built from source alongside the rest of BlueCrow.