System One, System Two, and a different way of thinking about AI agents.

1. First, I Believe in System One

Let me start with something I genuinely believe: System One models have enormous potential to advance AI.

Small, fast, specialized models are already demonstrating real value in classification, filtering, triage, and other well-defined tasks.

Take Airbnb's research, for example. They demonstrated that a fine-tuned small model could match much larger models on a production classification task at roughly 1% of the cost.

That's remarkable.

Why use an expensive general-purpose model for a narrowly defined task when a specialized model can deliver comparable results at a fraction of the cost?

I'm not questioning those achievements. Quite the opposite. I'm genuinely excited about what System One models could make possible.

But there's another application of System One that I want to challenge.

Using smaller models to anticipate the reasoning, decisions, and information needs of much more capable System Two models.

That's where my enthusiasm started turning into questions.

2. I Got Excited Too

Like many developers, I got caught up in the excitement around System One.

The idea sounded obvious.

We have incredibly capable reasoning models, such as Claude, consuming substantial computational resources and tokens. And now we have small, extremely fast models capable of making surprisingly useful judgments.

So why not combine them?

Why not let System One anticipate what Claude might need, prepare relevant information, or intervene at just the right moment?

I started exploring the research, studying implementations involving models such as Laya and Jev, and experimenting with integrating Laya into Claude Code.

One project I found particularly interesting was Laya-Code and its use within Laya-Codex.

Laya-Code learns relationships between development tasks and relevant code, enabling the system to score code by relevance rather than relying only on keyword matches.

It's a fascinating application of specialized models.

Laya-Codex has also reported promising session-level improvements. But its comparisons against lexical retrieval alone haven't established a statistically significant additional benefit attributable specifically to the small model.

That reflects a question I kept encountering in my own hands-on exploration and research:

How much of the improvement actually comes from the small model itself, rather than the engineering surrounding it?

Some approaches clearly show promise. Others produce less convincing results under closer examination.

I haven't found enough convincing evidence to make me believe this is where our engineering effort is best spent.

3. Are We Teaching the Wrong Model?

There are several ways to incorporate System One into or around a larger reasoning model.

Two context-management strategies illustrate the challenge.

Context reduction: Let a small model identify information that the larger model probably doesn't need.

The benefit is obvious: fewer tokens and potentially lower costs. But remove the wrong information, and you've saved a few cents at the expense of correctness.

Context enrichment: Let System One anticipate what the larger model will need and provide it proactively.

Relevant methods, code navigation hints, additional context, or information about an upcoming tool call.

This can be safer because we're adding information rather than removing it. But irrelevant information still costs tokens, and misleading context can send the reasoning model in the wrong direction.

Both approaches share a difficult assumption:

We're asking a relatively small model to make judgments about the information requirements of a considerably more capable one.

I believe we're asking too much of today's System One models.

The more conservatively we intervene, the less value we may create. The more aggressively we intervene, the greater the risk of errors, noise, or unnecessary cost.

At some point, I started wondering whether we were spending too much engineering effort optimizing how little damage we could do.

Congratulations. We've built an optimization whose greatest achievement might be occasionally not making things worse.

That doesn't mean these approaches never work. Some have demonstrated improvements, and future models may change the picture.

But there's another complication.

As System One gets smarter, System Two gets smarter too.

Will smaller models improve enough to anticipate the needs of increasingly sophisticated reasoning models more effectively?

Perhaps. But even if they do, will that remain the most valuable use of our engineering effort?

That's the question that changed how I think about this problem.

4. The Little Brother

Anyone who grew up with siblings can probably relate to at least one side of this story.

The older brother is comfortably settled on the couch, ready to watch a movie. His little brother has recently discovered that he can reach the light switch.

"Hey, can you turn off the light?"

The little brother runs over, delighted to demonstrate his new ability. Click. Lights out.

The older brother barely moves.

He knew what he wanted, recognized that his little brother could handle it, and chose the easiest way to get it done.

He didn't ask his little brother to figure out how to organize movie night. He gave him a simple task he knew he could handle.

And that's where I started seeing the problem differently.

The little brother didn't need to anticipate what his older brother wanted.

The older brother understood the objective, recognized the available capabilities, and decided what to delegate.

What if we approached System One and System Two the same way?

Instead of asking a small model to anticipate Claude's decisions, why not let Claude decide when to use specialized System One intelligence?

Claude already knows how to use tools. It decides when to read a file, search for a symbol, execute a command, inspect a result, or continue reasoning.

We give it capabilities, describe their limitations, and allow it to decide when they're useful.

So why not give it a different kind of tool?

System One Tools

Imagine a tool powered by a lightning-fast System One model running locally on your computer.

Not a cheaper agent taking over Claude's work.

A tool. One Claude knows exists, understands, and deliberately chooses to use.

Unlike a traditional deterministic operation, it can make probabilistic judgments.

Claude could configure its behavior, adjust thresholds, weights, or evaluation rules, and decide how to use—or ignore—the results.

Imagine a tool that scores hundreds of candidate code locations based on criteria Claude provides, returning a compact set of findings rather than requiring Claude to inspect every candidate itself.

The tool could even abstain when uncertain.

And because the underlying model runs locally, there's no per-call model API charge.

Probabilistic tools aren't new. Tools exposing specialized model operations already exist, including Laya's MCP integration.

But I believe there's a larger opportunity.

What if we trained System One models specifically to become configurable tools that reasoning models can think with?

Not simply another cheaper worker, but a fast, specialized instrument whose behavior the reasoning model can control.

We don't yet know what the most valuable versions of these tools would look like.

And that's precisely the direction I believe deserves more attention.

5. But Would It Actually Work Better?

I don't want to replace one exciting, unproven architectural idea with another.

A locally running model isn't entirely free. It consumes compute, memory, and time. Claude must still decide whether to invoke the tool, formulate its request, interpret the result, and potentially recover from mistakes.

All of that has a cost.

And perhaps a deterministic tool, an existing search mechanism, or Claude simply performing the work itself would be better.

We also need to consider what happens as models improve.

JetBrains published an interesting example of an agent skill that initially reduced token consumption by up to 50%. Their later update explained that newer models no longer reproduced the same benefit because they had become better at navigating the necessary code themselves.

Today's clever optimization can become tomorrow's unnecessary complexity.

And a System One tool could suffer exactly the same fate.

That's why isolated model accuracy isn't enough. We need end-to-end benchmarks comparing correctness, token consumption, latency, and total execution cost against simpler alternatives.

If a specialized probabilistic tool doesn't improve the overall workflow, there's no reason to add it.

So here's my position.

If I had to choose where to invest my engineering effort today, I'd choose developing System One tools over building systems that try to anticipate System Two's reasoning.

Not because I've demonstrated that System One tools will deliver greater improvements. I haven't.

But because I believe the potential return on that engineering effort is greater. Instead of refining predictions about what a reasoning model might need, we could explore an expanding range of capabilities that the reasoning model itself chooses how to use.

That's the bet I'd make.

6. What If This Is Only the Beginning?

Here's the possibility that excites me most.

Imagine that, through experimentation, we discover one or two System One tools that consistently demonstrate meaningful improvements.

Not just clever demonstrations, but tools with measurable benefits, well-understood limitations, and reliable interfaces.

Suppose those tools become widely adopted.

Now imagine a future generation of reasoning models explicitly trained to use them.

Not merely reading their descriptions, but learning through training when to invoke them, how to configure them, how to interpret their probabilistic outputs, and when to ignore them entirely.

Training language models to use tools isn't new.

But what happens when both sides of this relationship evolve together—specialized models trained to act as instruments, and reasoning models trained to operate them?

Could they discover ways of collaborating that we hadn't anticipated?

Could that produce significant improvements in efficiency, correctness, or even new capabilities?

I don't know. It might produce modest gains, or conventional tools might prove sufficient. Some capabilities might eventually be incorporated directly into larger models.

But I believe it's a fascinating direction to explore.

I started experimenting with System One because I wanted to make Claude work better.

Initially, I thought the answer was teaching System One to anticipate Claude's needs.

Now I'm wondering whether we've been approaching the problem backward.

Maybe we've been trying to make System One understand System Two, when we should have been teaching System Two how to use System One.

And perhaps the next meaningful improvement won't come from another system trying to predict what a reasoning model needs.

Perhaps it will come from giving reasoning models a new kind of tool—and discovering what they learn to do with it.