4242 is an applied AI lab in Amsterdam

We want to close the last mile between what today’s models can do and the value they create inside real organizations. We study recursive self-improvement: the use of AI systems to train and improve other AI systems. And we build bridges: between what is possible in theory and what is useful in practice.

The last mile

The capability of frontier models is not the limiting factor for most organizations. By our estimate, today’s models are already sufficient for the large majority of enterprise use cases, on the order of ninety-five percent of them. And yet, in practice, very little of that capability turns into value.

We call this the last mile problem. As in logistics, the last mile is the part of the journey you can already see and still fail to cross. The distance between a capable model and a working system inside a company is short, but it is also where the real difficulty lives. Closing it is the reason this lab exists.

A capable model is not yet a working one

Imagine hiring the most capable person you can find and placing them inside an unfamiliar company. On their first day, they are not yet useful. They become useful only as they learn how the company actually works: its conventions, its history, the small nuances that are never written down anywhere.

The same is true of language models and the agents built on them. The underlying intelligence is sufficient. What is missing is everything that makes a general-purpose model fit a specific organization: how that organization works, the tools the model can draw on, the standards it is held to. We treat this as the central design problem. It is not how to make a model smarter, but how to shape an already-capable one to the particulars of the work it is meant to do.

Learning from experience

A good employee becomes more valuable over time, because they learn from experience. Most deployed models do not. Their weights are fixed at training time and do not change as they work. For as long as this remains true of the dominant architecture, learning from experience has to happen somewhere other than the weights.

We locate it in the harness, the flexible layer of context, instructions, tools, and feedback that surrounds a model. The harness is where an agent can be shaped to a company’s specific needs, and where it can keep changing as those needs change. In the current paradigm, this is what continuous learning looks like in practice: not updating the model on the fly, but continually reshaping what surrounds it.

We do not claim that reinforcement learning and fine-tuning are without value; they clearly have their place. Our thesis is narrower and more practical. For adapting an agent to a particular organization and use case, optimizing the harness is more flexible, more cost-effective, and more efficient than repeatedly updating model weights.

The bottleneck is no longer the model

We are AI engineers, and we build agents the way most builders do. You deploy an agent, watch its traces, study the cases where it fails, run experiments to improve it, and repeat.

This works until it doesn’t. Past a certain scale, you fall behind. There are too many traces to read. New edge cases appear faster than you can address them. The dataset you rely on to catch regressions keeps growing. At that point something quietly shifts: the constraint is no longer the intelligence of the model. It is the human doing the evaluating and improving.

Using AI to build AI

If the bottleneck is human work, then the human work is what should be automated. So we rebuilt our own job. We took the loop that every agent builder runs (deploy, observe, evaluate, experiment, improve) and turned it into a system that runs on top of any agent, independent of framework, model, or use case.

We call it meta meta: a meta system whose purpose is to do the work we used to do by hand. Unlike a human team, it can spin up as many copies of itself as a problem requires, running thousands of experiments in parallel in search of the harness that works best for a given agent.

This is what recursive self-improvement looks like once it is made concrete. Not a single system bootstrapping itself in the abstract, but AI doing the systematic, patient labor of making other AI systems better.

Agents are living systems

Traditional software is largely deterministic. Given the same input, it returns the same output, and once it is correct it tends to stay correct. Agents are different. Language models are non-deterministic, and most useful agents are open-ended: people will use them in more ways than anyone designed for, inside environments that keep changing.

This is why evaluation and optimization cannot be treated as a phase that finishes. If the harness is where an agent becomes specific to an organization, then the harness has to keep learning. The work is not to find the right shape once. The work is to build a system that can keep finding the right shape as the agent, the company, and the world around them change.

That is the practical meaning of recursive self-improvement for us: AI systems doing the continuous, systematic labor of making other AI systems better. Not because agents are broken, but because useful agents are alive to the work they do. The last mile is not crossed once. It is crossed again and again. Building the systems that make that possible is what 4242 exists to do.

Work with us

A lab that calls itself applied has to stay close to real systems in real organizations. Alongside our own research, we work with a small number of companies on their hardest agent problems: not as a broad consultancy, but as an applied lab looking for the cases where the difficulty is real and the upside is meaningful.

Most of what we learn comes from systems that are already pushing against the edge of what works. If you are building agents for valuable, demanding use cases and have reached the point where the model is no longer the thing standing in your way, we would like to hear about it.

If that describes you, write to us.