Arzach

Agents that look after your fine-tunes. They read the whole chain, work out what went wrong, and hand you the complete fix. You approve it, and the same eval gate that judges every push judges theirs.

Fine-tuning goes wrong quietly. A typo’d learning rate destroys a model’s attention. A new specialization wins its metric and silently loses an old one. And the tooling underneath sees only files that differ, so nobody can say which tensors moved, which version was best, or what a repair would even mean. You find out ten hours later.

Arzach is an agentic layer over a version-controlled weight registry. Its agents watch the chain while you sleep: a refused push is diagnosed before you are back. Every version is stored as a compressed delta against its base with its eval record attached, which gives an agent something real to read: the history, the drift, the lineage, the metrics. It works out which tensors moved when a metric fell, then hands you the whole fix, worked out end to end — no retraining, no new GPU hours. Which tensors to take from which version. What to call the result. What it should score when the gate re-runs. Nothing touches your weights until you approve it.

The Arzach console's commit graph: a chain of model versions with gate verdicts and compression ratios
the commit graph: every version with its gate verdict

Say a chain reaches the point where nothing is shippable. The eval bar has three floors: language quality, answer accuracy, math. Each candidate clears two of them and fails a different third. The math specialist has let its language quality slip past the ceiling; the version that reads well can’t do the math. Choosing between them will never produce a passing model, because the model that passes doesn’t exist yet.

An agent with the whole chain in view proposes building it. Interpolate the two at a named alpha, push the result as a new version, re-gate every capability. It states up front what it expects each metric to land at, so the gate’s verdict either confirms the fix or tells it exactly how far to move the alpha and go again. Interpolation can beat both parents on a capability, and the registry can measure that before an approval is spent.

A patch agent's live transcript: its reasoning in prose, the tools it called, and the eval chart showing the crash it found
a patch agent reasoning through a broken chain, tool call by tool call

None of this trains anything. The usual remedy for a regression is another training run: lower the learning rate, mix replay data back in, buy the GPU hours a second time, and hope the next checkpoint holds both capabilities at once. Surgery skips all of it. Grafting a tensor class back from an earlier version, or interpolating two versions at a named alpha, is arithmetic over weights that already exist. No gradients, no training data, no new run. What a repair costs is one evaluation, not one fine-tune, which is why the agent can afford to try an alpha, read the gate, and try another.

This runs at real size.1 The compression that makes it affordable is the same thing that makes it legible: the registry knows exactly which tensors moved and how far each one drifted, so the agent reasons over a few hundred measured changes instead of two directories that differ.

A drift map of one model version: layers by tensor slot, coloured by how far each tensor moved
the drift map where the agent reads the damage

1 A 70B DPO fine-tune: 141 GB stored as 3.1, a ratio of 45×. A 120B mixture-of-experts: 65 GB stored as 1.0, a ratio of 64×. On that 70B the agent reads 723 tensors one at a time, which is what makes the reasoning legible rather than statistical. If you run it and your numbers come out different, we would like to see them: hello@arzach.ai.