Forge, and the model as a swappable part

Forge is BlueCrow’s agentic development system: it reads a repository, answers questions about it, makes changes, and verifies them by building and running the tests. This was the fortnight it stopped being tied to one model.

• Forge is the agent; the model is a backend. Composition used to name a specific model, so the only supported way to build a Forge session was to build a session for that model. Nothing in the agent required it — the coupling lived in one place, which is the cheapest place for it to be and the easiest to mistake for a design decision.
• Three backends, one agent. A local model, or either of two hosted reasoning providers. Selected from a menu, with an explicit priority order when left on automatic. The tools, the workspace boundary and the safety rules do not change when you switch.
• Local means local. With the on-machine model, Forge needs no account, no key and no network call to anyone. The hosted options are there for when a harder problem justifies one, never as a requirement to get started.
• Failover that reports itself. When one backend cannot serve and another takes over, the interface says which one actually produced the answer. A silent substitution is how you end up debugging the wrong model’s behaviour. A backend that failed for a reason retrying cannot fix is not retried.
• The preference survives a restart, so the choice is made once rather than every session.

Two of the fixes along the way are worth naming, because both are the same lesson. Tool names had to be reshaped before hosted providers would accept them at all — the agent’s internal naming was simply not valid over those APIs. And a credential lookup that read only one location failed on a machine where the value was set somewhere else entirely, producing a “not configured” message about a key that was plainly there. Neither was visible from the inside; both needed running against the real thing.