AI Problem Formulation and Solution Design

Artificial intelligence research settled early on a shared vocabulary for turning a vague task into something an algorithm can actually operate on. Russell and Norvig's widely used textbook organizes its third chapter around exactly this question, under the heading 'Solving Problems by Searching', formalizing a problem with five components: an initial state describing where the agent starts; a set of possible actions available at each state; a transition model specifying which state results from taking an action in a given state; a goal test that decides whether a given state counts as success; and a path cost function that assigns a numeric cost to a sequence of actions, so that candidate solutions can be compared and the cheapest preferred. This vocabulary generalizes far beyond puzzle-solving. A route-planning app's 'states' are intersections, its 'actions' are turns, and its 'path cost' is travel time; a robotic arm's 'states' are joint angles, and its 'goal test' checks whether the gripper has reached a target pose. Problem formulation is precisely the exercise of naming these five components explicitly, in writing, before selecting a search, optimization, or learning algorithm — because the algorithm can only ever be as good as the state space and cost function it is handed.

Skipping straight from a stakeholder's plain-language request to code is one of the most common and expensive mistakes in applied AI work, because a badly chosen state representation can make an easy problem look intractable or, worse, silently exclude the actual solution from the search space entirely. Consider the hospital wait-time example: if 'state' is defined only as the number of patients currently waiting, the representation throws away information about triage severity, staff availability, and time of day that any workable solution must condition on — no algorithm, however sophisticated, can recover decisions that the state representation makes invisible. Conversely, including too much irrelevant detail in the state (exact patient names, room lighting levels) inflates the search space without adding decision-relevant information, slowing every downstream algorithm for no benefit. Good problem formulation is therefore an act of deliberate abstraction: keep only the distinctions that make a difference to which action is best, and test that abstraction against concrete cases before committing engineering effort to a solver. A change in formulation, not a smarter algorithm, is often what turns an unsolved problem into a solved one.

Formulating states and actions answers 'what can the system do,' but a complete specification must also answer 'what is the system trying to achieve, and within what limits.' The agent-design framework associated with Russell and Norvig's treatment of rational agents supplies a compact checklist for this, often abbreviated PEAS: Performance measure (how success is scored), Environment (what the agent must operate within and cannot control), Actuators (the actions actually available to change the world), and Sensors (the information actually available to perceive it). Naming the performance measure explicitly is the objectives step — the number, or vector of numbers, the system is ultimately trying to optimize, which must be specified before any algorithm can be judged. Naming the environment surfaces constraints: a warehouse robot's environment constrains it to legal, collision-free moves; a loan-approval system's environment constrains it to decisions consistent with fair-lending law regardless of what a purely predictive objective would prefer. Treating constraints and objectives as the same thing is a common formulation error — an objective is something to be maximized or minimized, while a constraint is a condition that must hold regardless of how much it costs the objective, and confusing the two produces systems that violate the constraint whenever the objective term dominates the trade-off.

Reinforcement learning gives problem formulation its most explicit mathematical form: a task is cast as a Markov decision process defined by states, actions, a transition function, and a reward signal, and the agent's objective is to choose actions that maximize the cumulative reward it receives over time. Sutton and Barto's foundational treatment makes reward design a first-class part of problem formulation, not an afterthought: because the reward function is what the agent actually optimizes, a reward that only loosely approximates the real-world goal will be optimized faithfully and still produce behavior nobody wanted — a failure mode practitioners often call reward hacking. The final formulation component, evaluation criteria, is what lets a team check after the fact whether a deployed solution is actually achieving the intended objective, as distinct from merely scoring well on the metric it was trained against; this typically means holding out test cases, scenarios, or time periods not used to build or tune the system, and checking performance on those separately. A solution design is not complete until this evaluation plan is written down alongside the state, action, objective, and constraint definitions — otherwise there is no way to know, after deployment, whether the formulation chosen at the start was the right one.