Prompting is becoming routing

Prompting tells a model what to do. Routing decides which intelligence gets the job. The first live test also taught me something else: routing is only useful while it makes the work simpler.

I used to think the skill was getting better at asking one AI for what I wanted. Increasingly, I think the more useful skill is deciding where the work should go in the first place.

For a long time, professional AI use was basically a prompting problem. You opened ChatGPT or Claude, explained the task as clearly as you could, and tried to get a useful answer out of one conversation. That made prompt quality feel like the central skill, and I still think it matters. I just think it is becoming a smaller part of the system.

My own work no longer happens inside one model. I use different models for different things, coding environments for build work, and GitHub as a persistent knowledge layer. One model can help me develop an argument, another can give it a colder editorial pass, and a coding agent can deal with implementation. Something routine can go to a cheaper model; something difficult can be escalated. I had been doing this manually for a while without really naming it.

I think the name is routing.

Prompting asks one question, routing asks another

Prompting asks how should I tell this model what to do? Routing asks where should this piece of work go?

That second question barely mattered when there was only one capable model in front of me. It matters a lot more once there are several capable models, specialist tools and different price tiers.

A routine transformation might need a fast, inexpensive model. A difficult synthesis might deserve stronger reasoning. A coding task might bypass general chat entirely. A substantial public argument might benefit from another model used as a second editor. Something genuinely consequential might justify an adversarial review or independent verification.

And a small metadata edit probably should not summon the most expensive intelligence available to humanity.

Written down, that sounds obvious. Most of my own workflow was less deliberate until I looked at what I was already doing.

I already have a crude routing system

The clearest example is how I handle Editorial Intelligence work.

The observation or judgement usually starts with me. ChatGPT often helps me develop it, connect it to previous work and turn it into a usable draft. Useful context gets persisted into GitHub rather than being left inside one conversation. Claude or Claude Code can then encounter the work more coldly and rewrite, challenge or implement it. I decide what survives.

I have written about that particular split in the second model is not a proofreader. The important point was never that one model is objectively smarter. It was separation of perspective.

That is routing already. It is just routing done manually by opening a different tool.

Use sufficient intelligence, not maximum intelligence

This also connects to when the best AI model stops being worth it. The practical question is not whether one model wins a benchmark. It is whether a stronger and more expensive model makes a meaningful difference to the job in front of you.

Quite often, it does not.

If a cheaper model clears the threshold for the task, use it. If it struggles, escalate. If another tool is better suited to the job, route around the general-purpose model entirely.

The principle is simple:

Use sufficient intelligence, not maximum intelligence.

The most capable model should be an escalation tier, not the default engine for everything.

The router should be boring

Once I had named the pattern, I started thinking about whether some of it could be automated.

My first instinct was deliberately modest. I did not want an enormous autonomous agent making every decision. I wanted a small layer that could recognise the type of work in front of it and recommend where it should go.

Is this a rewrite? Research? Argument development? Verification? Code? Does failure matter much? Does a second perspective add enough value to justify the handoff?

That is still the version I find interesting.

But then I tried to apply the idea to a real article and immediately made it too complicated.

The first live test over-routed the work

The article idea itself was straightforward. I had been thinking about the return of the media brand, distribution becoming less dependable, and whether brand content should build recognisable intellectual territory rather than optimise isolated assets.

The routing check helped at first.

We checked whether I had already published the argument. We looked at what external evidence would be needed. We developed the stronger version of the thesis and avoided some weaker claims.

All useful.

Then the process kept going.

Because the piece was substantial, I decided it should receive an independent challenge from Claude. That turned into a dedicated challenge brief. The brief had to be persisted in GitHub. It was put on a separate branch. Claude was working from another branch and quite correctly said the file did not exist from where it was sitting. So another branch had to be created and the brief copied across before the challenge could even begin.

At that point the system had succeeded technically and failed editorially.

I was spending more attention arranging the handoff than thinking about the article.

The router had become the work.

The overhead did not go to waste, though.

The independent challenge that all that branch-juggling made possible found something real: the argument duplicated a framework and two essays I had already published, closely enough that a new article would have said the same thing a third time. I extended the existing pieces instead of publishing another one.

I would rather have reached that finding a cheaper way. But it is worth being honest that the heavy version of the process is the one that caught it. A quick duplication check might have flagged the framework. It is less clear it would have surfaced how much of the argument two specific essays already carried, because that took reading the corpus properly rather than scanning for an obvious repeat.

So the correction below is not skip the scrutiny. It is reserve it for when the argument is substantial enough to be worth checking properly, and then do not let the checking cost more attention than the argument itself deserves.

Routing is a decision, not a pipeline

That failure changed the design.

I had started to imagine routing as a sequence:

idea → novelty check → evidence → argument development → persistence → independent challenge → human gate → drafting → verification → logging

There are pieces where that level of scrutiny is justified. A major methodology change, an important factual claim, or an argument I genuinely do not trust yet might deserve it.

But making that the default for an ordinary Field Note is process theatre.

The better version is much simpler:

idea → quick duplication and evidence check → develop and draft → optional second-model edit → human decision → publish

The routing intelligence is mostly in deciding whether any extra stage is needed.

That is a much more important correction than it might sound. An operating system is useful because it hides complexity from the user. If my routing system makes me think about branch visibility, handoff packages and fixed schemas every time I have an article idea, it is doing the opposite.

The second model can just be a second editor

I also over-formalised the role of the second model.

There is value in a genuinely adversarial pass. Sometimes I want another model to attack the central claim, preserve disagreement and refuse to make the argument prettier.

But that does not need to happen every time.

For a lot of editorial work, the useful pattern is simply:

I have the idea → ChatGPT develops and drafts → Claude rewrites or reviews → I decide.

A rewrite can expose plenty.

Claude might remove a section because it is repetitive. It might flatten something I care about, which tells me that part needs defending more clearly. It might spot an unsupported leap, restructure a weak section, or make the prose cleaner while accidentally weakening the argument. All of those are useful signals.

I do not need a formal adversarial ceremony to get the value of a second perspective.

The important thing is that the second model is not the final authority. I compare what changed and decide what belongs in the finished piece.

Independence is an escalation, not a default

So I now think about second-model use in levels.

For routine work, there may be no second pass at all.

For a normal substantial article, a second editor or rewrite is often enough.

For a difficult or contentious argument, I can escalate to an explicitly adversarial review.

For canonical methodology or high-stakes factual claims, independent verification and a deliberate human gate make sense.

That is still routing. It is just proportionate routing.

The rule is not every meaningful task must pass through multiple models. The rule is use another model when independence is likely to improve the decision more than it increases the process cost.

The durable layer still matters

The over-complication does not change the part of the architecture I care about most.

I still do not want the intelligence trapped inside the router or any particular chatbot. The durable layer is the repository: evidence, previous arguments, frameworks, research, decisions and things learned from earlier work.

That is why the workflow should outlive the model still matters to me.

Models can change. Their relative strengths can change. The tool I prefer for drafting this year may not be the one I prefer next year.

The useful context should survive those changes.

But portability does not mean every handoff needs to be formalised. Sometimes portability simply means the relevant source material is available to whichever tool I open next.

That is enough.

The router should disappear most of the time

This might be the most useful design principle to come out of the first test.

A good router should be barely noticeable.

I have an idea. It quietly checks whether I already wrote it. It surfaces the relevant evidence. It notices if the claim is riskier than usual. It suggests a second pass when that is likely to matter. Otherwise it gets out of the way and lets me work.

The decision layer could be as small as three questions:

1. Does this already exist?
2. What evidence does it need?
3. Does another model or tool add enough value to justify the handoff?

That captures most of what I actually wanted.

Everything else is escalation.

A better article workflow

For my own work, the practical default now looks like this.

I bring the observation.

Before drafting, the system checks the repository quickly enough to tell me whether the idea is new, belongs inside an existing piece, or is probably duplication. If the argument makes an external claim, we establish what evidence is needed before fluent prose turns uncertainty into confidence.

Then we develop and draft.

If the piece is worth another perspective, I can send the draft to Claude as a second editor. It can rewrite it, challenge parts of it, or simply show me another way the same argument could be constructed.

I choose what survives.

Only when the stakes are higher does the workflow become more formal.

That feels much closer to the way I was naturally using multiple models before I tried to turn the habit into a system.

The failure is part of the experiment

There is an irony here I quite like.

The original version of this article said the router should learn from what it routes. Then the first real routing test immediately produced a useful negative result.

The process was too complicated.

So the process changed.

That is better evidence than another diagram explaining why the architecture ought to work.

It also gives me a clearer success condition for whatever I build next. The router should reduce the amount of thought spent on process while improving the quality of the decisions around the work. If it creates more cognitive load, more repository housekeeping or more model choreography than the job warrants, the correct response is not to automate the choreography.

It is to remove it.

Prompting still matters — one level down

None of this means prompting stops mattering. Every model still needs a useful brief. Context still matters. Bad instructions can still produce bad work.

But prompting increasingly sits one level lower in the stack.

The first decision may be whether this needs ChatGPT, Claude, a coding environment, a cheap model, a specialist tool, two perspectives, or simply no AI at all.

Then the prompt tells the chosen system what role to perform.

That is the shift I am interested in.

A chatbot is a destination: you go there and ask it things. A routing layer makes decisions about where work should go and what context should travel with it.

But the first lesson from trying to build one is more mundane than the architecture.

Routing should make complicated work simpler. It should not make simple work complicated.

Prompting tells a model what to do. Routing decides which intelligence gets the job.

And sometimes the best routing decision is to stop routing and get on with the work.