The post-execution reroute pattern

The problem with valid first words

Lacy’s pre-execution classification works well for the obvious cases. ls -la goes to the shell. what files are here goes to the agent. The first word tells you almost everything.

But some natural language sentences start with a word that is a real shell command. Consider:

• find out how the auth system works (find is a real command)
• make sure the tests pass (make is a real command)
• git me the latest changes (git is a real command)
• test the login flow works (test is a real command)
• go ahead and fix the tests (go is a real command)

Pre-execution, Lacy cannot confidently say these are natural language. find with unusual arguments might be valid shell syntax the user knows and Lacy doesn’t. Routing it to the agent when the user meant to run a command would be worse than letting it fail.

So Lacy lets the shell try it. If it works, great. If it fails, Lacy looks at why.

Two criteria, both required

Not every failed command is natural language. git psuh is a typo. rm nonexistent.txt is a valid command targeting a missing file. Lacy needs to distinguish “the shell tried to interpret English and choked” from “the user made a mistake.”

The detection function (lacy_shell_detect_natural_language) checks two criteria. Both must match for a reroute.

Criterion A: error pattern

The command’s error output must contain at least one of these strings (case-insensitive):

parse error
syntax error
unexpected token
command not found
no such file or directory
no rule to make target
is not a git command
unknown command
unknown primary or operator
missing argument to
invalid regular expression
...and a few more

These are the errors shells and common tools produce when they receive English words as arguments. make sure the tests pass produces No rule to make target ‘sure’. find out how auth works produces find: unknown primary or operator: ‘out’. git me the latest produces ‘me’ is not a git command.

Each error pattern on this list was added because a real user triggered it with natural language input. The list grows over time as new tools and error messages surface.

Criterion B: natural language signal

The error pattern alone is not enough. make nonexistent_target also triggers “No rule to make target,” but the user probably meant to run make and just got the target name wrong.

So Lacy also checks for a natural language signal in the original input. One of two conditions must hold:

• The second word is a natural language marker (articles like the, pronouns like me, prepositions like out, conjunctions like and, about 300 common English words)
• The input has 5 or more words AND the error is a parse/syntax error

The second-word check is the primary gate. In make sure the tests pass, the second word is sure, which is a natural language marker. In make mytarget, the second word is mytarget, which is not. The heuristic separates “English sentence starting with a command” from “command with a wrong argument.”

The 5+ word fallback catches cases where the second word is not in the marker list but the input is clearly a sentence. If the shell throws a parse error on 5+ words of input, it’s almost certainly not intended shell syntax.

The safety rails

Several guards prevent false reroutes:

• Successful commands (exit code 0) are never rerouted. echo the quick brown fox succeeds and produces output. No reroute.
• Single-word inputs are never rerouted. If you type make and it fails, that’s a real make invocation, not a sentence.
• Signal exits (code 128+) are excluded. A command killed by a signal is not a misrouted sentence.
• Shell operators in the input (|, &&, ||, ;, >) disqualify it. Pipelines and compound commands are shell syntax, not English.

Silent reroute

When both criteria match, Lacy reroutes the input to the AI agent without any user-facing indication that a reroute happened. The original shell error output stays in the terminal as context. The agent receives the full input and can reference the error.

Early versions showed a “Rerouting to agent...” message. I removed it. When the reroute is correct (and it almost always is), the message is noise. The user typed a question. They got an answer. The mechanism is invisible, which is the point.

When the reroute is wrong, the AI agent handles it gracefully because it can see what the user typed and what the shell returned. The agent can say “it looks like you meant to run make with a specific target” rather than just echoing the error.

Pre-flagging reroute candidates

There’s one more optimization. Post-execution detection only runs on inputs that Lacy pre-flagged as reroute candidates before execution. The pre-flagging function (lacy_shell_has_nl_markers) checks if the input contains natural language markers after the first word, filtering out flags, paths, numbers, and variables.

This means git push origin main never triggers post-execution analysis even if it fails. The arguments (push, origin, main) are not NL markers. Only inputs that look like they might contain English get the full two-criteria check.

The pre-flagging is intentionally aggressive. It’s cheap (pure string matching) and it only sets a flag. The expensive part (analyzing error output) only runs when the flag is set AND the command fails. False positives in pre-flagging cost nothing. False negatives mean missed reroutes.

Real examples

Why this pattern works

The post-execution reroute is effective because it uses the shell itself as the first classifier. Instead of trying to predict whether input is a valid command, Lacy runs it and observes the result. The shell is always right about whether the input was valid shell syntax. Lacy just adds a layer that asks: “if it wasn’t valid shell, was it English?”

The user cost is one failed command execution (typically 10-50ms for the errors that trigger rerouting). The benefit is zero false positives on pre-execution routing. Lacy never steals a command away from the shell that the user meant to run. It only catches the ones that were never going to work.

Combined with the reserved word filter and the agent word list, the three layers cover nearly every input correctly without any ML, any network calls, or any dependencies beyond Bash 4+.