A device that understands four useful requests can be a better product than one that answers forty questions unreliably. The trouble starts when its interface invites the forty questions while its engineering supports only the four requests. A chat box suggests that the user can explain a complicated situation and receive judgment. A bounded model may have been trained to select a tool and fill a few fields. Those are different promises. I would rather ship a narrow product with an honest boundary than spend the rest of its life explaining why a fluent answer was never supposed to count as advice.
Yesterday’s Needle article examined the value of giving up general conversation to support a more specific contract. The broader lesson applies without choosing that product or any particular parameter count. Tiny is a deployment constraint, not a task definition. Tool selection, slot filling, extraction, and narrow device commands offer outputs that a team can enumerate and inspect. Open-ended planning asks the system to decide which intermediate steps matter. Ambiguous policy asks it to interpret authority and exceptions. Broad factual assistance depends on knowledge beyond a small action catalog. Putting all of those behind the same text field does not make their failure conditions equivalent.
The history of speech interfaces offers a useful distinction. Pete Warden’s Speech Commands work defines a dataset for recognizing a limited set of spoken commands, a different task from transcribing arbitrary sentences. That bounded research task is not evidence that any particular product will recognize every speaker or noisy environment correctly. It shows why wake-word-like judgments can be useful without pretending to provide general speech understanding. A developer can specify which labels exist, collect difficult negatives, and test the conditions in which recognition fails. The scope is part of what makes the evidence meaningful. Speech Commands paper.
Consider a hypothetical warehouse inventory terminal. This is a proposed design, not a deployed system or a benchmark. A worker can ask it to look up a scanned item’s location, report a count for a specified bin, or display the next approved counting task. The terminal has access to the active item and bin identifiers, and its application defines the allowed operations. A tiny model translates ordinary phrasing into a candidate operation with typed fields. It does not decide which stock adjustments company policy should permit, invent a missing SKU, or determine whether a supplier is honest. Those duties would require a different specification and different evidence.
A request to record a count illustrates the distinction between extraction and invention. The worker says there are six units in the scanned bin. The model can propose a count operation, the integer six, and the bin supplied by the scanner. The application checks that the bin is current, the item matches, the quantity is within the operation’s accepted form, and the worker has permission. If the worker instead says there are several units somewhere behind the damaged boxes, converting several into an invented integer creates a false record even if the resulting JSON parses. A missing required value should trigger a precise clarification. The product has to preserve uncertainty through the interface instead of erasing it to satisfy the output schema.
The terminal also needs distinct responses for distinct failures. An unsupported question about next quarter’s purchasing strategy should not become a count request with guessed arguments. A recognized request to write off stock may still be prohibited for this worker. A lookup that cannot reach its inventory service is an execution problem, even when the requested operation was recognized correctly. Collapsing all three into a generic low-confidence answer makes recovery difficult. The application should preserve whether it needs more information, lacks a supported operation, denies permission, or cannot complete the selected action. The model can help interpret language; the product owns these operational states.
Permission must remain outside that interpretation. OWASP’s authorization guidance recommends denying access by default and validating permissions on every request. A convincing paraphrase of a user’s instruction does not establish the right to execute it. In the proposed terminal, the same authorization check applies whether the candidate operation came from a button, the tiny model, or a more capable model. Credentials stay with the component that enforces that decision. An escalation cannot quietly convert an employee’s request into an administrator’s action. OWASP Authorization Cheat Sheet.
Refusal is useful only when the product gives the user a workable next step. For an ambiguous count, show the specific field that needs confirmation. For an unsupported planning request, explain the supported task and direct the worker to the established planning process. For an unavailable service, distinguish a request that never left the terminal from one whose result is unknown. Tell the worker when nothing was submitted; otherwise show that verification is pending and reconcile the original operation before retrying. These are proposed interface behaviors, not claims that a model will reliably generate the correct explanation. A system with a small number of states can use fixed messages for them. The language model does not need to improvise an apology every time the application already knows what happened.
A larger model can receive a difficult interpretation task when the product explicitly supports that route, but the handoff needs limits. It should receive the approved request and relevant context, not an indiscriminate copy of the device’s records. Its candidate answer returns through the same field validation and authorization checks. If network access disappears, a cloud escalation is unavailable; the terminal must expose that state rather than manufacture an offline answer. A human handoff also needs someone responsible for receiving it. These constraints shape whether escalation belongs in this product at all. Adding another model endpoint before defining the recipient, permitted data, and accepted result simply moves the uncertainty to a more expensive component.
Evaluation should challenge the boundary as well as the supported requests. Include paraphrases of valid operations, missing fields, contradictory quantities, stale scanner context, unrelated questions, and requests the user is not allowed to perform. Keep schema validity separate from whether the chosen operation and its arguments are correct. Measure the accepted actions, the mistaken actions, and the requests refused or redirected. Selective-classification research formalizes a trade between coverage and risk on the cases a classifier accepts, but the cited work studies image classification. It does not certify this inventory terminal or supply a transferable threshold. The terminal needs evidence from its own workload. Geifman and El-Yaniv, Selective Classification.
A product team can then make an honest release decision. Perhaps the tiny model handles location requests well but still confuses inventory counts with stock adjustments. Ship the supported location workflow if it meets the defined requirements, and keep the other operation unavailable while it is investigated. Perhaps buttons and scanner input already solve the task with fewer errors; keep them. Natural language earns its place by helping users complete a specified job, not by making every screen resemble a general assistant. The question for the next release is concrete: which requests can this device complete correctly, which requests can it decline correctly, and can a worker tell the difference before a record changes?
Subscribe to Signal Over Noise for practical analysis of AI agents and automation: what to test, which constraints matter, and when a tool is worth using. Bring the next idea to one bounded workflow and check the result before expanding it.
If this was useful, forward it to one engineer who needs less noise in their feed.