The same words can mean completely different things depending on what I am trying to accomplish. “What happened with the Meridian project?” could be a request for a status summary, a root cause analysis of a failure, a chronological timeline, or a relationship map of stakeholders. The words are identical. The retrieval strategy is completely different for each interpretation.
Query classification is the routing layer that determines how Tessera searches. Get it right and the trimodal system delivers. Get it wrong and the best retrieval architecture in the world returns irrelevant results.
The Classification Taxonomy
I identified eight query types through analysis of six months of my own information-seeking behavior: Factual Lookup, Pattern Matching, Decision Replay, Chronological Reconstruction, Relationship Mapping, Comparison, Synthesis, and Action Planning.
Each type maps to a different weighting of the three retrieval modes. Factual Lookup weights lexical search heavily. Pattern Matching weights graph traversal. Decision Replay uses all three equally. Synthesis requires multiple retrieval passes with progressive refinement.
The classifier runs on the query before any retrieval begins. It examines query structure, keyword signals, conversational context (what was the previous query?), and the active life context windows to determine type. The classification takes about fifty milliseconds and saves seconds of wasted retrieval on the wrong path.
The Action Planning Type
Action Planning is the most complex query type and the one most relevant to technical remediation. When I say “prepare a remediation plan for the database corruption at Client X,” Tessera classifies this as Action Planning, which triggers the full agentic workflow: decompose the request, plan the retrieval sequence, execute in stages, synthesize results, and verify completeness.
Action Planning queries are the only type that invoke the agentic layer. All other types are handled by single-pass or multi-pass retrieval without the planning and verification overhead. This distinction keeps simple queries fast while allowing complex queries the processing time they need.
The classifier’s accuracy on my test set is about ninety-two percent. The remaining eight percent are ambiguous queries that could reasonably be classified as two or more types. For these, Tessera asks a clarifying question rather than guessing. I prefer a system that admits uncertainty over one that confidently misinterprets.
Context-Aware Classification
Query classification is not stateless. If I have been asking questions about a specific client for the last ten minutes, a new query without a client name is probably about the same client. If I just finished a remediation and ask “what should I document?”, the classifier knows the context is post-incident documentation, not a general question about documentation practices.
This statefulness is maintained in the working memory. The classification model receives not just the current query but a summary of recent queries, their classifications, and their results. The effect is a system that understands conversational flow, not just isolated questions.
Conversational understanding is what separates a useful assistant from a sophisticated search engine. Search engines process queries. Assistants participate in conversations. Tessera needs to do the latter.