Section 31.2: Instructions, goals, constraints

A Careful Control Loop

For Instructions, goals, constraints, read the figure as an interface check: identify the language input, grounding evidence, action representation, safety gate, and logged result before accepting the agent behavior described below.

This section turns natural-language directives into a control objective that a symbolic planner, MPC stack, or policy can actually optimize.

The practical question is which clauses in the instruction should become equalities, inequalities, or preference weights in the downstream planner.

Theory

Suppose an instruction induces a goal variable $g$, a set of hard constraints $\mathcal C$, and a preference score $r_\text{pref}$. A planner can then solve $$\max_{\tau} \; \mathbb E\left[\sum_t r(s_t, a_t; g) + \lambda r_\text{pref}(s_t, a_t, x)\right] \quad \text{s.t.} \quad c_k(s_t, a_t, x) \le 0 \; \forall k \in \mathcal C.$$ The language front end decides what enters the reward and what enters the constraint set.

This distinction matters because optimization behaves differently under each choice. If 'do not tip the cup' is encoded as a mild reward penalty, a planner may accept spills when the goal is otherwise attractive. If it is encoded as a hard constraint or shield, the system must seek an alternative path or ask for clarification.

Worked Example

Code Fragment 1 shows a compact parser that turns a single sentence into hard and soft task elements. The important detail is not the string matching itself, but the separation between mandatory and negotiable parts of the instruction.

# Split one instruction into a goal, a hard constraint, and a soft preference.
# Real systems use learned parsing, but the typed output contract is the same.
# The planner should inspect these slots directly instead of re-reading the sentence.
instruction = "bring the red mug, keep it upright, avoid the left shelf"

goal = "deliver(red_mug)"
hard_constraints = ["keep_upright(red_mug)"]
preferences = ["avoid(left_shelf)"]

print({"goal": goal, "hard": hard_constraints, "soft": preferences})

The expected output is a three-field task object with exactly one goal slot, one hard-constraint list, and one soft-preference list. If the parser merged keep_upright(red_mug) into the soft field or omitted it entirely, the downstream planner would optimize the wrong problem even if the natural-language instruction still looked correct to a human reviewer.

Practical Recipe

1. Write one schema for goals, one for hard constraints, and one for preferences.
2. Define a parser failure state for instructions that cannot populate the schema reliably.
3. Make the verifier inspect hard constraints before any preference score is reported.
4. Assign explicit units to every numeric threshold extracted from text, such as speed or distance.
5. Treat underspecified slots as a clarification trigger, not as permission to improvise.

This section is where language touches control theory most directly. Once the utterance becomes a constrained optimization problem, the usual machinery of feasibility, receding-horizon planning, and safety filtering applies. The LLM is useful because it proposes the task object; it is not the final judge of whether the task object is physically or ethically valid.

The best engineering pattern is therefore asymmetric: let language be flexible at proposal time and rigid at execution time. Proposal modules may entertain multiple parses, but execution modules should consume one validated, typed contract whose semantics are stable across seeds, prompts, and model versions.

Code Fragment 2 scores candidate plans against one hard constraint and one preference to make the distinction visible numerically. The hard constraint prunes infeasible plans first; only then does the preference score choose between survivors.

1. Generate several candidate plans from the same typed instruction object.
2. Reject every candidate that violates a hard rule before computing preference scores.
3. Score the surviving candidates with a transparent preference model.
4. If no candidate is feasible, ask a clarification question tied to the missing slot or impossible constraint.
5. Save both the feasible set and the rejected set so later audits can separate parser and planner failures.

The expected output is a feasible-set list that excludes short_path, followed by the name of the lowest-cost surviving plan, quiet_route. Reading the trace should make the algorithmic order obvious: feasibility filtering happens first, preference optimization happens second, and any output that still contains an upright=False plan indicates that the hard-rule gate failed.

If execution violates intent, inspect the failure in order: parsing, constraint typing, feasibility filtering, then preference ranking. Many so-called planning errors are actually parse errors where a soft preference was accidentally promoted or a hard rule was accidentally softened.