The intelligence officer who saw the bottleneck
Tyler Edwards did not come to AI infrastructure from a research lab or a big tech company. He came from British intelligence, where he worked at MI5 and MI6 overseeing teams that explored how AI could automate intelligence analysis and other high-stakes processes. It was there, he says, that he saw the problem that would become Overmind: building models for highly specialised environments was difficult, expensive, and confined to a handful of expert teams, even though the need for specialised models was everywhere.
His framing of the problem has stayed consistent since. Some of the hardest problems in AI, Edwards argues, are not about building a bigger model but about building the right model for the right job. In intelligence, generic solutions often were not enough; the same, he believes, is true in business, where companies have unique data, code and expertise yet still rely on general-purpose models built for everyone. The gap between what a team knows about its own product and what its model knows about it is the gap Overmind exists to close.
Edwards founded Overmind alongside Sam Brunt, a serial startup operator who has helped scale Funding Circle, Pipe and Vertice into high-growth companies. The pairing is deliberate: one founder who lived the specialised-model problem inside intelligence, one who has repeatedly turned early-stage companies into scaled ones. Together they set out to make specialised AI practical, affordable and accessible to organisations far beyond intelligence and national security.
A seed round, then the open-source bet
In February 2026, Overmind announced a £2m seed round led by Osney Capital, a specialist cybersecurity investor, with 14Peaks, Portfolio Ventures, Antler and Endurance Ventures also taking part. At the time the company was about seven months old, and its pitch was already pointed: as Edwards put it in the funding announcement, the AI security industry is trying to secure the wrong thing. Models will always be open to adversarial inputs, he argued, but most teams have no view of an agent in production whose behaviour starts to drift — and that drift, in live operation, is where the risk actually sits.
The funding set up the bigger move. On 1 October 2026, Overmind announced the open-source release of its training and deployment platform, giving developers and companies a new way to build AI systems tailored to their own data, code and business needs. The platform gives engineering teams one workflow for turning proprietary data and software into production-ready AI, from agent observability and data preparation to training, evaluation, fine-tuning, and deployment. Teams can benchmark models against real-world tasks and continuously improve them — and, crucially, the company says the platform is already being used by organisations in financial technology, legal services, healthcare and cybersecurity.
Open-sourcing the platform was a statement about who the customer is. Overmind is not selling a better model; it is selling the ability to make your own. That only works if teams can inspect, run and own the machinery, which is why the release, not just the product, matters to the story.
Every product gets its own AI lab
When Edwards launched Overmind on Product Hunt, his pitch was a single line: Overmind is the open-source platform for AI agent training, and what the team is working towards is giving every product its own AI lab. Most AI products, he noted, run on the same few frontier models, while a frontier lab works differently — collecting data, building evals, training, testing, shipping, and repeating. Overmind's goal is to let any team building an agent run that same loop on its own data, without hiring an ML team or building infrastructure.
Getting started is deliberately small: connect Overmind's MCP, and paste one prompt into Cursor, Claude Code, Codex or OpenCode. From there, the loop has six stages. Tracing captures OpenTelemetry traces, scored as they arrive and matched to the part of the agent that produced them. Datasets turn production traces into versioned eval and training sets. Evals let a team define what good means for each capability, then measure it on live traffic. Optimisers run prompt, tool and code experiments in the team's repo, and the winner comes back as a git diff. Fine-tuning trains small specialised models on the team's data, benchmarks them against the model it runs today, and lets the team download and export the weights. Inference puts a team's own models and frontier models behind one OpenAI-compatible API.
The through-line is ownership at every stage. Traces are scored against the team's own agent, datasets are versioned, evals are defined by the team, experiments land as diffs, and the resulting models belong to the team that trained them. It is the frontier lab's loop, rebuilt for teams that will never be frontier labs.
Diagnosing the agent, not just watching it
Edwards has written about the diagnostic idea at the heart of Overmind in a post called Secret Agent Overmind, which frames the problem as one of joined-up evidence. An observability tool records behaviour, but behaviour alone cannot explain itself: a trace tells you what happened, not what could have happened. Without the codebase, you cannot tell whether a behaviour was one of many available paths or the only one, which tools the agent never reached for, or which parts of its surface nobody has ever watched run.
That is why Overmind joins code, traces, datasets, evals and training runs into one grounded view of an agent. Agent coverage analysis, in this framing, measures traces and dataset rows against the agent's full capability surface, taken from the code: which behaviours are well represented, which tools never appear, and which production paths no dataset row touches. The delta between what the agent can do and what has been observed or trained on is what decides whether data is fit to evaluate against or train on.
The distinction matters because it changes what a team fixes. A wrong answer in isolation invites a prompt tweak; a wrong answer joined to its code path, its missing dataset rows and its eval gap invites a structural fix. Overmind's bet is that the teams who can see that joined picture will improve faster than teams who can only watch their agents run.
Why this gap, and why now
Edwards has an analogy for the moment Overmind is trying to create. Computing became widespread, he argues, as processors became cheap enough to build into almost anything and development tools made them useful to far more people. Intelligence, in his view, needs a similar expansion in who can build it and where it can run. Today, millions of developers can build with AI, but creating and improving the models behind it still requires expertise concentrated in relatively few teams. He believes that gap will close — and that the companies which close it for themselves will have an advantage that compounds.
Every application, business, device and individual has different needs, and meeting those needs will require more people to be able to create, test and run specialised models. That is a long argument, and Overmind's open-source release is its opening move rather than its conclusion. But the shape of the bet is now clear: not a bigger model, not a better wrapper, but the loop itself, handed to any team willing to run it. If Edwards is right, the next frontier labs will not look like labs at all — they will look like ordinary product teams, each with its own AI lab, each training models on data nobody else has.
The playbook
- Steal the frontier lab's loop, not its model — Edwards argues the advantage of a frontier lab is not one model but a loop: collect data, build evals, train, test, ship, repeat. Overmind packages that loop so a product team can run it on its own data.
- Join the evidence instead of collecting more of it — Traces, datasets, eval scores and code usually live in separate tools. Overmind's diagnosis starts by joining them, so a wrong behaviour can be traced to the code path, the dataset gap, or the eval that missed it.
- Make the winner a git diff — Prompt, tool and code experiments run inside the team's own repo, and the winning change comes back as a diff. Improvement lands through the workflow developers already use.
- Let teams own the model they ship — Fine-tuned models are benchmarked against the model a team runs today, and the weights can be downloaded and exported. Ownership, not just access, is the point.
- Start with one prompt, not an ML hire — One MCP connection and one pasted prompt is the whole onboarding. If specialised models require hiring an ML team first, only a few companies will ever build them.