% Generated by roxygen2: do not edit by hand
% Please edit documentation in R/tools.R
\name{route_input}
\alias{route_input}
\title{Route User Input to the Appropriate Handler}
\usage{
route_input(input)
}
\arguments{
\item{input}{Character string of user input.}
}
\value{
A list with:
\describe{
\item{mode}{Character: \code{"command"}, \code{"tool"}, or \code{"rag"}}
\item{reason}{Character: brief explanation of the routing decision}
}
For \code{"command"} mode, also includes \code{command} (the command name).
}
\description{
Classifies user input into one of three modes and returns a structured
routing decision. This function encapsulates the three-mode routing
architecture used by both the Shiny app and programmatic interfaces.
}
\details{
Routing logic:
\enumerate{
\item Input starting with \code{/} is routed to the \strong{command} handler
for deterministic execution (no LLM involved).
\item Input containing numerical data patterns (distributions, arrays,
dollar amounts, percentages with surrounding context) is routed
to the \strong{tool} handler where the LLM selects and calls tools.
\item All other input (conceptual questions, explanations) is routed
to the \strong{rag} handler where the LLM answers from the knowledge
base context.
}

Note: modes \code{"tool"} and \code{"rag"} both go through the LLM, but the
distinction affects how the query is framed (tool-calling emphasis vs.
RAG-context emphasis). The LLM ultimately decides whether to call a
tool, but the routing hint improves reliability with smaller models.
}
\examples{
\dontrun{
route_input("/mcs tasks=[...]")
# list(mode = "command", reason = "...", command = "mcs")

route_input("Simulate 3 tasks: Normal(10,2)...")
# list(mode = "tool", reason = "...")

route_input("What is earned value?")
# list(mode = "rag", reason = "...")
}

}
\keyword{internal}
