Why prompt routing belongs outside the model

I kept using one prompt style for everything. Code review, planning, research — same mental template, pasted into whatever chat window was open, then a slow loop of re-explaining context when the answer came back shaped for the wrong kind of task. The friction wasn't the model getting things wrong. It was me handing every job to the same generic instructions and hoping.

The fix that actually stuck was boring: decide which template fits before talking to any model at all. That decision doesn't need intelligence, it needs classification — and classification is cheap, deterministic, and belongs on my machine.

That's what PromptCore does, and it's why it lives outside the model rather than inside a system prompt. When I hand it a task, nothing calls out over the network first. The routing turn happens locally: read the task, estimate its category and complexity and intent, rank the registered templates against that estimate, select one. Only then does anything downstream see a model. What the downstream model receives is a Meta-Prompt built from the selected template, delivered alongside my original task — so the original intent stays visible instead of being silently rewritten by some hidden layer.

The mechanism is deliberately small. Estimate category, complexity, intent. Rank 40 registered reasoning templates against that estimate and pick one. Build the Meta-Prompt locally and leave the actual answering to whoever called the router. PromptCore never generates an answer; it generates the framing an answer should have. That separation is the whole point. A system prompt baked into a product can't adapt per-task, and asking the model to route itself means paying latency and tokens for a decision that shouldn't require either.

Speed was the part that surprised me. Because the entire pipeline runs locally with no inference involved, the numbers look less like AI infrastructure and more like ordinary code: the bundled test suite passes 22 / 22, and the local pipeline measured 0.0430 ms p50 over 2,000 runs. At that cost you can afford to route every single call, not just the ones you remembered to configure in advance. Routing stops being an optimization you debate and becomes a default you forget about.

Now the honest part. Of those 40 templates, synthetic coverage exercises 20 / 40 — half the registry has never been hit by the benchmark at all. And where the benchmark does score, exact framework match sits at 19%, meaning the selected template's structure matched the expected framework fewer than one time in five.

Both of those numbers point at the same limitation, and I'd rather state it than soften it: the expected templates are ones I defined myself. This makes the benchmark an internal calibration tool, not independent validation. It tells me the router behaves consistently against my own expectations, quickly and reproducibly. It does not tell me whether the Meta-Prompt it selects produces a better downstream answer than no routing at all. Those are different claims, and only the first one has any evidence behind it right now. A 19% exact-match rate could mean the ranking needs work, or it could mean my notion of "expected" is too rigid — near-miss templates might frame a task nearly as well. The current benchmark can't distinguish those cases, which is exactly the kind of ambiguity I don't want to paper over.

The open question I keep coming back to: can the exact-match rate against author-defined expectations be replaced by an external benchmark? Something that scores routing decisions against outcomes measured outside my own head — downstream answer quality judged independently of the templates I happened to register. Until that exists, PromptCore is a fast, tested, well-instrumented hypothesis. I'm comfortable shipping that, as long as the label says hypothesis.