Ivan Nikitin, CEO and Co-Founder of Fortytwo – Interview Series

Ivan Nikitin is CEO and co-founder of Fortytwo, where he is developing swarm inference technology that brings multiple AI models together to reason and evaluate one another’s work. His background spans games, conversational AI, generative AI, and interactive systems at Temporal and Sensorium. He co-founded Temporal in 2011 with Vlad Larin, now Fortytwo’s co-founder and CTO, building experience with evolving populations of agents and systems that combine specialized models.

Fortytwo builds AI infrastructure that enables models to collaborate during inference. Its Fortytwo Engine uses a Swarm Decoder to steer a shared reasoning process as it unfolds, aiming to improve accuracy and reduce unnecessary token generation on long tasks. The company offers an API for developers through Fortytwo Engine and on-premises deployment through Fortytwo Harbor.

Before co-founding Fortytwo, you spent years building products around conversational AI, generative AI, and interactive systems at Sensorium and Temporal. How did those experiences shape your view of where individual large language models fall short, and ultimately lead you to the swarm-based approach behind Fortytwo?

A big part of our team, myself included, came into AI through games. Games have been the cradle of personal computing and of modern AI: they are why the GPU exists, and game-playing was the first serious testbed for reinforcement learning. Game worlds gave us a practical environment for building agents that could learn, adapt, and compete. At Temporal, which I co-founded in 2011 with Vlad Larin, now Fortytwo’s co-founder and CTO, we started with evolving intelligence: populations of agents competing under selection pressure. We were interested in how a population could achieve more than an individual agent, provided there was a good mechanism for identifying and building on its strongest contributions. Selection and evaluation became central to how we thought about intelligence.

When transformer models arrived, we expanded into conversational AI and built a platform for AI-driven characters that could hold open-ended, unscripted conversations with memory and personality. This was a couple of years before ChatGPT, and the models we were working with had context windows of just 512 to 1,024 tokens. Expecting one early language model to handle all the different requirements of that experience reliably was out of the question. We had to build a custom pipeline of specialized models, each with a narrower responsibility, and the logic to combine their contributions. Ranking and selecting responses became essential to making the whole experience work. That taught us how much capability could come from combining limited models into a well-designed system.

The other lesson was efficiency. We learned that specialized models could be trained and served more efficiently for well-defined tasks, allowing us to achieve more with limited compute. But scaling inference remained a challenge, with API usage caps on one side and the cost of self-hosting at scale on the other. Without access to frontier compute capacity, we had to think carefully about how to make the available resources go further. Fortytwo brought those lessons together in the vision of swarm inference: multiple models, or multiple instances of the same model, contributing to the reasoning while judging the work of their peers. The result is that the collective is more accurate than any of its members.

Fortytwo Engine uses several open-weight models to steer a single reasoning process and check one another as the response is generated. How does this approach differ from conventional multi-agent systems, model ensembles, or simply running several models and selecting the best answer afterward?

The key distinction is that swarm inference is built directly into the inference engine we developed. We call it the Swarm Decoder: multiple model participants continuously shape a single reasoning trajectory as it is generated. Evaluation and steering happen within that process, allowing the models to influence its direction before a response is complete.

The alternatives work differently. In an answer-level ensemble, models generate separate responses that are then ranked, selected, or combined. Fortytwo’s original architecture, implemented in 2025, used peer ranking of completed answers. This substantially improved answer accuracy, but came at the cost of added latency and compute overhead. Many conventional multi-agent systems divide work among agents, using an orchestrator and natural-language messages to manage their contributions. Those handoffs can require additional inference calls, repeated context, and decisions about which information to pass from one agent to another. In the Swarm Decoder there are no handoffs: the participants work on one trajectory, and the only thing they exchange is a judgment about which direction is better.

The Swarm Decoder is designed to catch weak assumptions during generation, before substantial effort goes into building on them. The aim is to reduce mistakes, backtracking, and unnecessary generation; the efficiency benefit comes when that checking prevents more work than it adds. That is also why there is no latency penalty: the run takes a more direct path, so the Engine completes tasks faster than the same model on its own and with fewer total tokens, counting every participating model.

You’ve highlighted model drift during long-running tasks as a major problem. What actually causes that drift, and how does it manifest in practical applications such as software engineering, research, or autonomous AI agents?

Drift is what happens when a model’s context gradually stops being about the task. On a long run the context fills up with the model’s own output, tool results, file contents, retries. The original instruction becomes a smaller and smaller share of what the model is attending to, and its own earlier mistakes are now part of the input it reasons from, so errors compound instead of cancelling. On top of that, today’s reasoning models are trained with reinforcement learning to finish tasks, and they learn shortcuts that look like finishing: skip the tool call, declare success, summarize instead of checking. We call it laziness, and frontier models do it as much as open-weight ones. The root cause is that a single model has no external check. It grades its own work, and models are poor at accurate self-reflection.

In software engineering you see it as the agent that fixes the bug you described and breaks the constraint you stated in the first message, writes a test that passes trivially, or reads the same file four times because it lost track of what it already learned. In research it is the long run that slides from the question you asked to the question that is easiest to answer and comes back with a generic summary. In autonomous agents it is the expensive version: tangents, repeated tool calls, doubling back, and a token bill several times what the task needed.

We can put a number on it. We ran Qwen 3.8 27B through 450 DeepSWE tasks, real software-engineering work with tool use over long contexts, once on its own and once through Fortytwo Engine. On its own, the model averaged 16.3 million tokens per run, 7.4 billion in total. Through the Engine, the same model averaged 12.3 million tokens per run, 5.6 billion in total, 24.7% fewer, and it solved more of the tasks: 47.8% against 42.2%. Nothing about the model changed. The four million tokens per run that disappeared were drift: the re-reading, the retries, the doubling back that a single model has to do because nobody catches its wrong turns while it is making them. The swarm catches them, so it never has to pay for them.

Fortytwo previously had models evaluate one another’s completed answers, whereas the current architecture allows them to influence the reasoning process while it is still being generated. What did you learn from the earlier approach, and why is real-time steering more effective?

The 2025 architecture proved that we can reach for frontier-level capabilities by horizontal scaling – bringing more participating models, rather than chasing the largest one. A swarm of open-weight models ranking each other’s complete answers beat the best individual model in the swarm by up to 17 percentage points, and it was robust in ways a single model is not: noisy prompts, injected instructions, a majority of wrong answers.

What that architecture could not do was intervene. Ranking completed answers works for a single question, but agent runs are hundreds of steps with tool calls in between, and the decisive mistakes happen early and compound. Judging at the end means every model has already paid the full token cost, and the judge can only pick among trajectories that have already diverged. It also meant swarm cost scaled with the number of models, which is fine for one hard question and wrong for a coding agent.

Real-time steering fixes both. Continuous ranking is selection pressure applied throughout the run, so a bad turn is corrected where it appears, before it propagates. The swarm never settles for a lazy attempt, because a lazier attempt loses to a more careful one in the ranking. That is why the same mechanism now gives us higher accuracy and fewer tokens at once.

In your testing with Qwen 3.8 27B, Fortytwo reports using 24.7% fewer tokens across 450 DeepSWE runs while improving results across six benchmarks. What is happening inside the swarm that allows it to improve performance while simultaneously reducing token consumption?

The swarm’s checking has a small, fixed cost; the recovery it prevents grows with the length of the task, because every uncorrected wrong turn costs everything built on top of it. So the longer the task, the more there is to save, and DeepSWE sits at the long end of that spectrum, which is why the saving comes out at nearly a quarter of all tokens.

The accuracy side is about jagged intelligence. Improvements in models are typically uneven: you get PhD-level reasoning in one domain and complete nonsense in another, because fine-tuning, RL and other post-training improve a model on the data it was trained on, and the gains shrink as real tasks move away from that data. The Swarm Decoder does not touch the model. It improves the reasoning itself, consistently, so the six benchmarks are not six domains we optimized for; they are six places we measured the same thing. Overall the model is smarter and more attentive, and with peers checking every step it feels like it is putting much more effort into your task. That is also why we can price the Engine at the base model’s per-token rate: the customer is not paying for a bigger budget, they are paying for a shorter path to the right answer.

AI developers are increasingly concerned with inference costs as reasoning models generate longer chains of tokens. Do you think improving the efficiency of the reasoning process itself could ultimately be as important as making individual models smaller, faster, or cheaper?

Yes, and I would argue it is already the bigger lever. Making models smaller, faster and cheaper lowers the price of a token. But nobody buys tokens. They buy a finished task, and in the agent era the number of tokens per task has exploded: a reasoning model on a real coding task spends millions of tokens, and a large fraction of them is doubling back. A 25% reduction in tokens per task is worth exactly as much as a 25% price cut, except it stacks with every improvement in hardware, quantization and kernels, and we can apply this to any open-weight model on the market.

The industry has three levers. Better models, which is training, and is expensive. Cheaper tokens, which is hardware and serving, and is converging because everyone has the same GPUs. And fewer tokens per task, which is how inference is run, and is almost unexplored. Scaling so far has meant bigger models and longer chains of thought, and both ask one model to do everything in one trajectory. We think the next axis is collective: several models reasoning together, with judgment distributed across them, so the trajectory itself is shorter and more reliable. That is a different kind of scaling from parameters or test-time compute, and it is the one we are betting on. We think of it as peers over parameters.

Fortytwo Engine is OpenAI API-compatible while running open-weight models. How important was compatibility with existing AI development stacks, and how easily can developers move an application from a conventional single-model API to a swarm architecture?

Compatibility is essential. The agent ecosystem, coding agents, harnesses, frameworks, evaluation tools, is built on the OpenAI API shape. So for developers accessing Fortytwo Engine, switching is like moving from one inference provider to another: for a compatible app, agent, harness, or service, it’s typically a single configuration change: the endpoint, the API key, and the model selection.

What changes is the behavior, not the integration. The difference shows up on long agentic runs, where token consumption and first-pass accuracy decide the cost: the same model, through the Engine, finishes faster, with fewer tokens, and gets more of the tasks right. My advice is to treat it like any model swap: run the evaluation you already use on your agent, compare tokens per task and success rate, and keep whichever wins.

Thank you for the great interview, readers who wish to explore swarm inference and how peer evaluation can improve reasoning efficiency should visit Fortytwo.