The agent isn’t the hard part.
Models get better on their own. What they lack is a place to work: the repository as it is, the tests, what the team already decided, and a way back from production. That is the part we build.
Models write code faster than any team can read it. The missing piece isn’t a better agent. It’s the factory around it: somewhere to build, a way to ship that a team can trust, and a line back from production when something breaks.
Estelle started as a tool we built for ourselves, because we were shipping a large codebase with coding agents and the agents kept being confident about code that was not there.
A function that never existed, a signature that had moved, a decision the team made months ago that nobody wrote down — all of it stated with the same confidence as the parts that were right.
Reading every diff closely is the obvious fix. It doesn’t scale, and it’s the part people skip when they are tired.
So we built the factory around the agents. Each task gets a Silo with the real repository and its tests in it, the change is checked before anyone merges it, and when something that shipped breaks, the error comes back with a fix.
We run our own work through it every day.
Models get better on their own. What they lack is a place to work: the repository as it is, the tests, what the team already decided, and a way back from production. That is the part we build.
Every number we publish has a script behind it in the repository. We don’t publish one we cannot reproduce. When a result moves the wrong way we say so, and the limits of the test go in the same paragraph as the number. We write about that in our research.
We do not train on what is in your repositories. You bring your own model and key, so the code goes to your provider under your terms. The long version is on how Estelle improves itself.
Estelle proposes a change, shows the evidence behind it and waits. It does not deploy, and it does not push to production. What we have in place today, and what we do not, is written out on security.
Fate Labs is the trading name of Honour Systems Inc., incorporated in Ontario and working out of Toronto, and we’re a small team.
Nobody sits between a customer and the people writing the code. Write to khai@fatelabs.ca and an engineer answers.
We’re hiring in Toronto across engineering, deployment and go-to-market, and we take interns. Every role asks two written questions instead of a cover letter, because what someone has actually built tells us more than a template does.