“Explain what SLA means and write last week's progress report.” One sentence asks for two jobs. An assistant capable of both still needs to decide which task to do first and which source it may read. Skipping that boundary can turn glossary text into a report template or invent missing report facts from a term definition.
Why classify a request before opening sources?
Suppose the assistant supports only three jobs: assigning work, writing reports, and explaining terms. Each requires different material. An assignment may use verified organization information, a report draft uses a chosen form, and a term explanation uses a glossary. Loading every source before choosing the task increases the chance that unrelated material is presented as evidence.
“What does SLA mean?” has one clear mode. A request for both a definition and a report is different. Asking “Should I explain the term first or prepare the report first?” can be a more accurate first response than silently combining two outputs with different inputs and review criteria.
How do you restrict sources to the chosen mode?
Treat a model-proposed mode as a candidate. Application code validates the selected job and its permitted sources before retrieving any documents. The diagram shows a single mode proceeding to its source and a mixed request returning for clarification.
The diagram depicts the access boundary: classify first, validate one mode, and only then open the corresponding material.
SOURCES = {
"term": ("terms",),
"report": ("report_form",),
"assign": ("org_chart",),
}
REPORT_TYPES = {"instruction", "progress", "result"}
def plan(candidate, report_type=None):
modes = candidate.get("modes", [])
if len(modes) != 1 or modes[0] not in SOURCES:
return {"status": "clarify", "question": "Which task should I handle first?"}
mode = modes[0]
if mode == "report" and report_type not in REPORT_TYPES:
return {"status": "clarify", "question": "What kind of report do you need?"}
return {"status": "ready", "mode": mode, "sources": SOURCES[mode]}SOURCES lists the sources this mode is allowed to use; it does not contain their document contents. Retrieve documents only after ready. Also enforce each user's or organization's permissions in the retrieval code. This mode map alone is not an authorization system.
What if two tasks appear in one sentence?
If the classifier proposes both term and report, plan() refuses to choose one silently. A report request without a report type also returns a question:
print(plan({"modes": ["term"]}))
print(plan({"modes": ["report"]}, report_type="progress"))
print(plan({"modes": ["term", "report"]}, report_type="progress"))
print(plan({"modes": ["report"]})){'status': 'ready', 'mode': 'term', 'sources': ('terms',)}
{'status': 'ready', 'mode': 'report', 'sources': ('report_form',)}
{'status': 'clarify', 'question': 'Which task should I handle first?'}
{'status': 'clarify', 'question': 'What kind of report do you need?'}This code does not classify natural-language requests. It validates an already proposed classification. Measure the real classifier separately. If a term is absent from the glossary, the next step should report that absence rather than extract a plausible definition from a report form.
What else needs verification in production?
The source boundary alone does not guarantee factual answers. Check whether retrieved material supports the response, whether the user may read that material, and whether text inside a document is being mistaken for application instructions. Keep test cases for low-confidence or mixed-mode requests that should return clarify.
Key takeaways
Use the sequence classify request → validate one mode → select allowed sources → verify the answer. Ask when jobs are mixed or report details are missing. Describe the assistant's role in a prompt, but enforce allowed modes, retrieval scope, and user permissions in application code too.
