A colleague called me to go over the agent and how to use it. His first language isn’t English.

Partway through the call he told me his experience was worse than mine, and then he asked the question that I keep thinking about. Why does it route to pipelines and workflows when you do it, but not when I do it?

We both had to work to even understand what that question meant. He wasn’t describing a crash or an error. The tool ran.

It just gave him a thinner result than it gave me, on what we eventually figured out was the identical request.

It took us a while to land on the difference, because the difference was nowhere in the tool. It was in the words.

He writes English carefully. It’s his second language, so he reaches for plain, direct, correct phrasing.

And that plain phrasing slid right past the parts of the router that decide how much help you get. Same intent, same need, thinner outcome, purely on vocabulary.

I want to walk through why that happens, because once you see the mechanism it’s a genuinely hard problem, and I don’t have a clean answer to it.

What the router actually does

The /do router is a host, not a worker. I wrote up the routing mechanism before, but the short version is that it never does the work itself.

It sizes up your request, walks you to the right specialist, and notes afterward whether the seating worked. Five phases: it classifies the complexity, routes to an agent and a skill, enhances the job with extra machinery, executes, and then learns from what happened.

The classify-and-route part is where words start to matter. A script called pre-route.py takes your request text and matches it against literal trigger phrases stored in an index file.

Each phrase that matches scores +1.0. A skill marked force-route scores +2.0.

Stack a force-route plus two trigger hits and the router calls that “high” confidence, which means it skips the language model entirely and routes on keywords alone.

One force hit is “medium.” Nothing matches and you fall to “low,” which drops you into a slower fallback where a small model has to reason out where the request was probably headed.

So the fast, confident path is keyword matching. The slow, lossy path is for everyone whose words didn’t hit.

Here is the part that becomes uncomfortable once you line it up. Same intent, different words, different route.

Left column is the dialect. Right column is plain English describing the identical task. The router has no trouble with the intent. It has trouble with the phrasing.

The machinery you summon by accident

Routing to the right place is only half of it. The other half is the enhance step, and this is where the gap gets wider.

The enhance step reads your request for specific words and stacks extra machinery on top of whatever it routed to.

Say “comprehensive” or “thorough” or “full” and it fires three parallel reviewers at your code, one for security, one for business logic, one for quality. Say “with tests” or “production ready” and it prepends a test-driven-development pipeline with verification gates.

These are real upgrades to the quality of the work, and they’re completely invisible.

You don’t ask for three reviewers. You say “thorough” and they show up.

Now hold that next to the plain version of the same ask.

“Thorough review” fires three reviewers. “Can you check this carefully” fires none, because “carefully” isn’t a word in the table.

“Production ready” runs the full test pipeline. “Make sure it actually works” runs nothing, because that phrasing never matches.

“Look over my code” gets the default skill instead of the three-reviewer methodology, because “look over” isn’t the verb “review.”

I want to be precise about what’s happening, because it’s easy to misread. The router isn’t deciding that the plain-language user needs less rigor. It never makes that judgment at all.

It just doesn’t see the request as a request for rigor, because the rigor is keyed to words the person didn’t happen to use. The quality you get is a function of how you phrased the ask, not what you actually needed.

It gets worse when you look at the words themselves. Some of the trigger lists are saturated with engineer tokens nobody else types: goroutine, errors.Is, the %w verb, make check, mypy check, bandit scan, red green refactor, codex review.

That part I understood already. If you don’t write Go, you’ll never type “errors.Is,” and that’s fine, because you don’t need the Go path.

The part I didn’t see was the other words.

The words are not hard

Here’s where the call changed how I think about this. I’d assumed the barrier was the engineer jargon. Learn the tool’s vocabulary, get the tool’s power.

That’s a real barrier but it’s a familiar one, the same barrier every technical tool has.

But “review” is not jargon. Neither is “thorough.” Neither is “with tests.”

These are simple, plain English words. My colleague knows all of them. He could define every one of them.

That’s not where the gap lives.

The gap is that nothing tells you which of the simple words are levers. “Review” pulls a lever. “Look over” doesn’t.

“Thorough” pulls a lever, “carefully” doesn’t, and you would have no way to know that, because there is no rule you could derive from the language itself, since the line isn’t in the language at all, it’s in a table I wrote one afternoon and never thought of as a vocabulary requirement.

A native speaker who has spent years around engineers absorbs some of these by osmosis, picks “review” over “look over” without knowing why, and gets rewarded for it.

Someone arriving in their second language reaches for the most direct correct phrasing, which is exactly the phrasing that misses, and there’s no signal anywhere that they missed.

That’s the thing that’s hard to fix. It’s not vocabulary difficulty.

You can’t study your way out of it, because the knowledge isn’t “what does this word mean,” it’s “which of these ordinary words happen to be wired to extra behavior in this specific tool.”

That’s invisible knowledge. You have no way to guess it.

There’s one wrinkle worth saying, because it’s a partial mitigation that already exists. On the call I showed him that he could just ask the router what it did, and it would tell him.

The system can describe its own routing. So the curtain isn’t sealed.

But you have to know to ask, in roughly the right words, and “why did this route the way it did” is itself something you only think to ask once you suspect there’s a lever you missed.

The mitigation is real and it’s also locked behind the same kind of knowledge as the original problem.

I only saw any of this because he told me. The tool works perfectly for the person who built it and speaks its language, which means nothing in my own use was ever going to flag it.

You can ship a gap like this without noticing, not because you were careless but because it’s invisible from where you’re standing.

What I’m weighing

I don’t have a fix I’m committed to. I’m looking at a few directions, and each one has a cost, so I’ll lay them out with the costs attached.

The one I lean toward is changing the default. Right now when the router is uncertain, it gives less. The rigor stays locked unless the words unlock it.

The alternative is to default up, which is to say that when you can’t tell whether someone wants the careful version, you give them the careful version anyway, and you treat the absence of the magic words as a question to resolve generously rather than a signal to do less.

The penalty for not knowing the words disappears the moment the absence of words stops meaning the absence of rigor.

It’s cheap, it doesn’t require rebuilding the matcher, and it removes the sharpest edge of the problem, which is that the people most likely to phrase plainly are the ones least likely to know what they’re missing.

I’m not certain about it. Defaulting up costs compute on requests that didn’t need it, and there’s a version where it’s annoying rather than helpful. But of everything I’m looking at, it’s the one that appeals to me most.

The most thorough idea is to make intent the first pass instead of the fallback. Right now semantic reasoning is the slow backup for requests that failed keyword matching.

Flip it, so that a model reads for intent first and “send my work upstream” routes as well as “push my changes,” and the plain phrasing stops being a second-class citizen.

The cost is real and it’s structural, because that’s a model call on every request, slower and more expensive than a regex, and it defeats the whole point of a router that prides itself on skipping the model when it can.

I’m not sure the fast path is worth giving up to close this gap. I’m also not sure it isn’t.

A lighter idea is to ask when the rigor is ambiguous. If a request could plausibly want testing and review but didn’t say the words, surface the choice instead of silently giving less.

“Want me to run tests on this too?” One question removes the silent penalty without an expensive rewrite.

The risk is asking so often that it turns into noise, and a tool that constantly asks you to confirm things you didn’t ask for is its own kind of friction.

The trick would be asking only when the signal is genuinely unclear, and I don’t know yet where that line is.

There’s a quieter direction too, which is to make the machinery visible. Show what got added and offer to add more, so the curtain stays open and someone learns the dialect by watching it operate instead of by already knowing it.

That’s closer to what helped my colleague on the call. It doesn’t fix the gap so much as teach people across it, which is a different bet.

There are other directions I’ve only half-considered. You could expand the trigger tables with paraphrases, or let the learning layer pick up an individual’s personal phrasing over time, or add a normalization step for translated phrasing before keyword matching ever runs.

I’ve barely thought those through and I don’t want to pretend otherwise.

Where this leaves me

I’m not sure. I’m looking for options and answers right now, and what I keep landing on is that this is a more interesting problem than it first looked.

The version in my head before the call was “newcomers don’t know the jargon,” which is a known problem with known answers. The version after the call is “the levers are made of ordinary words, and which ones are levers is unguessable,” which is a different and harder thing.

Default-up is where I lean, mostly because it’s cheap and it stops punishing plain phrasing. The rest is open.

I’d like to understand the tradeoff on intent-first routing better before I rule it out, and I want to watch what people actually type before I trust any paraphrase table.

For now I mostly just want to keep looking at it, because a gap that’s invisible from the inside is exactly the kind I’d otherwise ship without noticing.