Frontier Intelligence Should Leave Something Behind

These articles come from lessons learned while building Eterna Clarity and the operating system I use to run it.

One of the strangest things about building with frontier AI is how easy it is to pay for the same intelligence twice. A difficult problem appears. A capable model reasons through it, discovers a structure that works, produces an answer, and the result gets accepted. Then the same class of problem appears again tomorrow and the system sends the whole thing back to frontier intelligence as though nothing was learned. The answer may be good both times. The workflow may even look automated. But I increasingly think there is a missing question in that design: what did the system keep from the first solve?

A solved problem should leave something behind

I have been running experiments inside Eterna around moving recurring work away from repeated frontier reasoning. The goal is not to eliminate AI calls for the sake of it, and it is not to prove that a local model is always better. The more useful objective is narrower: when a recurring task becomes stable enough, can the system convert some of the expensive reasoning that solved it into durable capability that requires less frontier intelligence next time without lowering accepted quality? That capability could be software. It could be a schema, a deterministic transformation, a validation rule, a test, an index, a tool, an authority boundary, a compact representation of the relevant context, or a smaller learned component for the part that remains genuinely semantic.

Sometimes the correct answer may be that very little can be compiled. The task might keep changing, depend heavily on current world knowledge, or require enough open-ended judgment that frontier reasoning remains the right tool. The important part is that the architecture should find out rather than assume.

This is different from ordinary automation

Companies have automated repeated work for decades. That is not the claim here. The interesting loop is what happens after frontier intelligence participates in solving a task that was not already fully specified. Traditional automation usually begins with a human who understands the process well enough to encode it. A frontier model changes that starting point. It can help discover the process, inspect examples, identify regularities, propose representations, generate tests, write deterministic components and expose where the real ambiguity remains.

That means the output of a frontier solve does not have to be only the answer to the immediate task. Part of the output can be a better system for handling the next instance.

This idea has clear prior art. Research such as Large Language Models as Tool Makers explores stronger models creating reusable tools for weaker models. Other recent work has investigated compiling agent behaviour into typed harnesses or deterministic orchestration around bounded semantic calls. Systems such as Palimpzest have explored optimizing AI data-processing plans across quality and cost, and small models such as FunctionGemma demonstrate that narrow learned capabilities can sometimes be delegated to much smaller models. I do not think the novelty is the existence of any individual mechanism. The question I care about is whether an operating system can make the reduction in frontier dependency cumulative and measurable across real recurring task families.

Better representation can remove model work before training does

A recent Eterna experiment made this especially obvious to me. I had been training a small local model for a recurring semantic task. It eventually performed well on a compact evaluation. Then the base model performed equally well once I represented the problem properly. That was already a warning that I might be optimizing the model before optimizing the interface.

When I separated the exact parts of the task from the semantic part, the architecture changed again. Eterna could establish eligibility, retrieve authoritative values and reconstruct the output deterministically. The model only needed to choose among a bounded set of meanings when a semantic decision was actually permitted. Some prompt behaviours stopped requiring the local model entirely. Others failed closed when the semantic component was unavailable. That result mattered more to me than squeezing another few points out of a fine-tune. The first improvement was not a better model. It was giving the model less of the wrong work.

Local models are optional, not the point

It would be easy to turn this into an argument that everything should eventually run on a small local model. I do not think the evidence supports that. A local specialist has real potential advantages when a semantic residue is stable, bounded and repeated enough to justify maintaining it. But it also creates training, evaluation, deployment, versioning and maintenance costs. If the task changes frequently, a frontier model may remain simpler and better.

There is also a third possibility that I initially underestimated: once exact mechanics and authority are moved into deterministic layers, the remaining semantic problem may be easy enough that a base model already handles it. In that case, training is solving a problem the representation already removed.

So the progression I care about is not frontier model to local model as a universal migration path. It is frontier reasoning to the smallest reliable capability that still satisfies the task. Sometimes that capability will still be frontier reasoning.

The measurement needs to include the whole system

Token reduction by itself can be misleading. Suppose a reusable capability reduces frontier tokens dramatically but requires weeks of construction, constant maintenance, frequent repairs and a second model reviewing its failures. It may be more complicated and more expensive overall even though one inference metric looks excellent. The useful quantity is closer to frontier dependency per accepted outcome, including the cost of construction, maintenance, repair, review and failures over enough repeated use for reuse to matter.

The quality side matters just as much. A system that saves 90 percent of its frontier usage by silently getting worse is not learning efficiently. It is degrading cheaply.

This is also why fixed subscription pricing complicates claims about monetary savings. If the frontier provider is already paid for through a fixed plan, using fewer tokens may not reduce the current cash bill at all. The immediate benefit could instead be capacity, latency, privacy, reliability, provider independence, context reduction or simply preserving scarce frontier usage for the work that benefits from it most. Those benefits need to be measured honestly rather than collapsed into a generic cost claim.

There are really two learning loops

I find it useful to separate one-time automation from compounding reuse. One-time automation asks whether a task can be made cheaper or easier after understanding it. Compounding reuse asks whether each accepted solve improves the system's ability to handle future members of the same task family. The second loop is much more interesting to me.

If frontier intelligence helps build a tool, test, schema or deterministic procedure that serves only one instance, that may still be worthwhile. But if the capability survives and keeps removing repeated reasoning from later instances, the system begins to accumulate operational knowledge in a form that is inspectable and reusable. There is another layer beyond that too: improved learning efficiency.

If Eterna gets better at recognizing which parts of new recurring problems should become software, which belong in authoritative data, which need tests, which remain semantic and which should stay frontier-native, then the process of building reusable capability itself can improve. That is where the idea becomes much more interesting than ordinary prompt optimization.

Frontier intelligence should be concentrated at the frontier

I still want the most capable models I can access. The conclusion I am reaching is not that frontier intelligence is wasteful. It is that frontier intelligence is unusually valuable, and repeatedly spending it on already-understood mechanics may be the least interesting use of it.

Use it where the problem is genuinely new. Use it where requirements are ambiguous. Use it to discover structure, challenge assumptions, synthesize evidence, design tests, inspect failures and work in parts of the problem that have not stabilized yet. Then look at what became stable. If a rule is now exact, make it a rule. If a transformation is deterministic, make it software. If a fact has an authoritative owner, stop asking a model to rediscover it. If a tool can carry a repeated behaviour reliably, build the tool. If a bounded semantic residue remains, decide whether a local specialist, a base model or continued frontier reasoning is actually the best fit.

The point is not to remove intelligence from the system. It is to stop confusing repeated inference with accumulated capability.

A system can appear intelligent without becoming more capable

This is the failure mode I want to measure. Imagine two systems that both solve a recurring task correctly for a year. System A sends every instance to frontier intelligence with roughly the same prompt, context and reasoning burden it used on day one. System B uses frontier intelligence heavily at first, but verified lessons become tools, state, software, schemas and bounded learned components. By the end of the year, frontier intelligence is still involved when something new appears, but the stable portion of the work no longer has to be reconstructed every time.

Both systems may produce the same immediate outputs. Only one has clearly demonstrated that accepted work changed its future operating requirements. That difference is measurable.

It is also falsifiable. Eterna may discover that the construction and maintenance burden outweighs the savings for many task families. Some supposedly stable problems may drift too quickly. Some local substitutes may be worse enough that frontier models remain the correct answer. A bounded experiment can fail without invalidating the broader architecture. That is important because I do not want this to become another principle that Eterna believes because it sounds elegant. The claim has to survive actual workloads.

The answer should not disappear after the response

A lot of current AI software treats inference as the end product. Ask a question, get a result, move on. For open-ended work, that may be exactly right. But when the same class of accepted reasoning keeps returning, I think the system should at least ask whether the answer contained something reusable.

The frontier model might have discovered the beginning of a program. It might have exposed an authority rule that belongs in the operating system. It might have shown that a huge context can be reduced to a compact interface. It might have generated a test that permanently catches the same mistake. It might have revealed that the supposedly intelligent portion of the workflow was deterministic all along. Or it may reveal that the problem genuinely remains semantic and changing, and that nothing simpler should replace the frontier model yet. Either result is useful.

What I no longer like is solving the same known problem from scratch indefinitely and calling the repetition learning. The most valuable output from today's frontier intelligence may sometimes be the part of tomorrow's system that no longer needs to ask.