We built this because we needed it.
We are a small engineering company. The first place our product runs is on our own software, because something you would not trust with your own business is not something you should be selling.
The gap was never the model.
We set out to run several software products with AI doing a real share of the work. Not a demo, the actual day job. Features shipped, bugs fixed, dependencies maintained, incidents looked into.
The AI turned out to be good enough. Everything around it did not exist. Work that survived longer than a chat session. Limits that actually held. A record you could put in front of an auditor. Somewhere to run it that could reach our own systems without asking a security team for something they would rightly refuse.
So we built that instead, and it turned out to be the thing every team trying this seriously runs into. We are engineers who built a tool we needed, which is the least fashionable origin story available and still the one that tends to produce the best products.
- Builds
- AI agents for engineering teams
- Runs on it
- Our own product portfolio, first
- Based
- Remote, with a US entity
- Contact
- success@novacore.ai
Four things we designed around.
Telling an AI what not to do is not a control
It is a request, and requests get ignored. Anything that matters has to be stopped by something the AI cannot argue with.
Real work does not fit in a chat window
It takes days, waits for people, and outlives whichever model was fashionable when it started. Anything that dies when a session ends was never going to do the job.
You should not be locked to one AI
This is the fastest-moving part of the industry. Which one you use should be a setting, not a decision you have to live with for two years.
A claim you have to walk back was never worth making
We would rather write the limitation on the page than have you find it in a security review.
We are customer number one.
Our own software runs on it as an ordinary customer, on exactly the same setup you would get, not a privileged internal version. Which means when something is wrong, we find it in our own work rather than in yours.
We are also clear about what that does not prove. Our codebases are newish and small. They do not test what an established organisation will hit first: an old codebase, a slow and flaky test suite, an entrenched process, a real approval hierarchy, and far more happening at once.
That gap only closes by running against somebody else's real code, which is the honest reason we would rather talk to you now than polish for another two quarters.
Come and try to break it.
The most useful conversations we have are with the people whose job is to find the hole. If that is you, bring the questions.