Policies and Value Functions
Imagine a robot navigating a warehouse to fetch packages. At every aisle, it chooses whether to turn left, turn right, or wait. Every choice it makes is dictated by some rule. That rule maps what it currently perceives to what it does next. That rule is a policy. Understanding policies precisely is the hinge on which all of reinforcement learning turns. Once an agent commits to a policy, we can ask a deeper question. How much reward should we expect, on average, if the agent follows this policy from any given situation? Answering that question rigorously produces the value function. It is the single most important object for reasoning about long-term consequences of behavior. This matters far beyond toy robots. Recommendation engines decide which policy of content-serving maximizes long-term engagement. Autonomous vehicles evaluate policies over steering and braking. These must be safe over entire trips, not just the next instant. Game-playing agents, such as those that master Go or Atari, are at their core searches over policies. These searches are guided by estimates of value. In every one of these systems, the mathematical objects introduced here — policies and value functions — are the vocabulary in which the entire problem is posed. Building on the Markov Decision Process framework and the notion of Rewards and Returns, this article makes precise what it means for an agent to "behave." It also makes precise what it means for that behavior to be "good." We treat a policy not as vague intuition but as a well-defined mathematical mapping. We treat "goodness" as an expectation computed under the dynamics of the environment. Getting these definitions exactly right matters greatly. It is what allows later machinery — the Bellman Equations and the distinction between State-Value and Action-Value Functions — to be built without ambiguity. By the end, you should be able to write down a policy for a concrete MDP. You should be able to compute the expected return it induces from any state. Do this by hand for small examples. You should also understand precisely why value functions are the right currency for comparing different behaviors. This groundwork is what all of dynamic programming, Monte Carlo methods, and temporal-difference learning are built upon.
- A policy π is a mapping from states to a probability distribution over actions: π(a|s).
- Policies can be deterministic (a single action per state) or stochastic (a distribution over actions).
- Following a policy from a state generates a random trajectory of states, actions, and rewards, governed by both π and the MDP's transition dynamics.
- The expected return under a policy is the expectation, over all such trajectories, of the cumulative discounted reward.
- This expectation, as a function of the starting state, defines what will later be called the state-value function.
- Comparing policies rigorously means comparing the expected returns they induce, state by state.
A policy tells an agent how to act, and the value of a policy is nothing more than the expected long-run reward that acting this way produces.
The idea
Formally, given a Markov decision process with state space and action space , a policy is a function
satisfying for every state . This says: whenever the agent finds itself in state , it samples its next action from the distribution . A policy is stationary if this mapping does not change with time step ; unless otherwise stated, we always mean stationary policies, since for MDPs with an infinite or indefinite horizon, stationary policies suffice to achieve optimal behavior (a fact justified later via the Bellman optimality equations). Two important special cases deserve names. A policy is deterministic if for every state there is a single action with ; we then abuse notation and write directly as an action rather than a distribution. A policy is stochastic if it assigns positive probability to more than one action in at least one state — useful for exploration, for handling partial observability, and for games with adversaries where randomized behavior is provably necessary for optimality (as in rock-paper-scissors-like MDPs). A policy alone does not determine what happens; it interacts with the environment's transition function and reward function to generate a stochastic process. Starting from state , we draw , the environment responds with reward and next state , then we draw , and so on. This produces a random trajectory
The return from time is the (typically discounted) sum of future rewards,
for discount factor (or a finite sum in episodic tasks with ). Because both the policy and the transition dynamics are stochastic, is a random variable even conditional on the starting state. The single most important derived quantity in reinforcement learning is the expectation of this return, which is exactly what a value function measures:
This equation is the bridge between "a rule for acting" (the policy) and "a number worth optimizing" (the value). Everything that follows — the Bellman equations that make this expectation recursively computable, and the split into state-value versus action-value functions — is built on exactly this definition.
How it works
Mechanically, evaluating what a policy is worth means simulating (or analytically solving for) the expected return it produces. There are two complementary ways to think about "how it works": generating trajectories under a fixed policy, and computing the expectation of return in closed form for small, fully known MDPs.
Trajectory generation. Given an explicit policy and a known MDP, we can sample rollouts directly. This is the operational meaning of "following a policy," and it is exactly what a simulator or robot does at run time. ``` function GENERATE_EPISODE(policy π, MDP M, start_state s0, max_steps T): trajectory = [] s = s0 for t = 0 to T-1: sample a ~ π(· | s) # stochastic action choice sample (s', r) ~ M.step(s, a) # environment dynamics p(s', r | s, a) trajectory.append((s, a, r)) s = s' if M.is_terminal(s): break return trajectory function MONTE_CARLO_RETURN(trajectory, γ): G = 0 for (s, a, r) in reversed(trajectory): G = r + γ * G # accumulate discounted return backward return G ``` Running many episodes from a fixed start state and averaging the resulting values gives a Monte Carlo estimate of — a direct, simulation-based reading of the definition .
Exact evaluation for small, known MDPs. When the transition and reward functions are fully known and the state space is small, we don't need sampling at all. The definition of satisfies a self-consistency condition — the seed of the Bellman equation, though we state it here only as a direct consequence of expectations, not yet as the general recursive machinery: ``` function EVALUATE_POLICY_EXACTLY(policy π, MDP M, γ, tol):
# v is a table indexed by state, initialized arbitrarily (e.g., all zeros) v = { s: 0.0 for s in M.states } repeat: Δ = 0 for s in M.states: if M.is_terminal(s): continue old_v = v[s] total = 0 for a in M.actions(s): action_prob = π(a | s) expected_next = 0 for (s_next, r, p) in M.transitions(s, a): # p = p(s',r|s,a) expected_next += p (r + γ v[s_next]) total += action_prob * expected_next v[s] = total Δ = max(Δ, abs(old_v - v[s])) if Δ < tol: break return v ``` This is iterative policy evaluation: it repeatedly applies the expectation implied by and the MDP dynamics until the value estimates stop changing meaningfully. It is not yet the full Bellman equation (that formalism and its contraction-mapping proof of convergence belong to a dedicated treatment), but it is a direct computational unpacking of : each state's value is the probability-weighted average, over the policy's action choices and the environment's transition randomness, of immediate reward plus discounted value of what comes next.
Complexity & correctness
Space. Storing a general stochastic policy over a finite MDP requires numbers — one probability per state-action pair. A deterministic policy needs only since one action index per state suffices. Storing the value table used in evaluation requires real numbers.
Time for Monte Carlo estimation. Each simulated episode of length costs to generate and to compute its return, so episodes cost . The estimator of from independent episodic returns starting at has variance shrinking as by the standard concentration of sample means — this is a direct consequence of for i.i.d. samples, so Monte Carlo evaluation is unbiased but requires many episodes for tight estimates, especially when returns have high variance (long horizons, large , or high-variance rewards all increase the number of episodes needed for a fixed confidence interval).
Time for exact iterative evaluation. One full sweep over all states costs where bounds the branching factor (number of possible next states per state-action pair), since for each state we loop over actions and, for each action, over possible outcomes. The number of sweeps required to reach a fixed tolerance is where the deeper correctness argument lives.
Why iterative evaluation converges — the core argument. Define the update in the evaluation pseudocode as an operator acting on any candidate value table :
Two facts, both provable directly from this definition, guarantee correctness: 1. is the unique fixed point of . Substituting the true expected-return function into the right-hand side and using linearity of expectation over the one-step decomposition of shows exactly — this is the content of what becomes the Bellman equation for , and uniqueness follows because is a contraction (next point). 2. is a -contraction in the max-norm. For any two value tables ,
because the difference is a - and -weighted average of terms , each bounded in magnitude by , and a weighted average of numbers cannot exceed the largest one in magnitude. Since , the Banach fixed-point theorem guarantees that repeated application of from any starting table converges to the unique fixed point , and the error shrinks geometrically: after sweeps, . This geometric shrinkage is what justifies stopping the loop once successive updates differ by less than a small tolerance — the true error is bounded by a known multiple of the observed change, so the number of sweeps needed for a target accuracy is , giving a total time complexity of
Tradeoffs. Exact evaluation requires full knowledge of and scales poorly as grows (the "curse of dimensionality"), while Monte Carlo evaluation needs no model of the environment at all but pays in variance and sample count. Both approaches, however, are computing the same mathematically well-defined object, — the distinction is purely about how the expectation is realized, not what it means.
Worked example
Consider a tiny two-state MDP: a "Study" state and a "Rest" state , both non-terminal, with . From each state the agent can choose action stay or switch. Dynamics (deterministic for simplicity):
| State | Action | Next state | Reward |
|---|---|---|---|
| S | stay | S | +2 |
| S | switch | R | 0 |
| R | stay | R | +1 |
| R | switch | S | -1 |
Consider the stochastic policy : in state , choose stay with probability 0.8 and switch with probability 0.2; in state , choose stay with probability 0.5 and switch with probability 0.5. We run `EVALUATE_POLICY_EXACTLY` by hand. Initialize .
Sweep 1:
Sweep 2: using from sweep 1,
Sweep 3: using ,
The table below shows the trend over sweeps, converging geometrically (each error term shrinking by roughly the contraction factor per step, consistent with the correctness argument above):
| Sweep | v(S) | v(R) |
|---|---|---|
| 0 | 0.000 | 0.000 |
| 1 | 1.600 | 0.000 |
| 2 | 2.752 | 0.720 |
| 3 | 3.711 | 1.562 |
| ... | → 6.30 | → 5.07 |
Continuing the recursion (or solving the two linear fixed-point equations directly, and ) gives the exact fixed point around , . This confirms concretely: is strictly the expectation of discounted return starting in and always sampling actions from — no single trajectory realizes this exact number, but it is what a Monte Carlo average over many trajectories would converge to as well.
Common pitfalls & traps
| Pitfall | Why it happens | Fix |
|---|---|---|
| Confusing a policy with a plan | Treating as a fixed sequence of actions rather than a state-indexed rule | Remember is defined for every state, not just those on one trajectory |
| Forgetting policies can be stochastic | Habit of thinking in terms of deterministic control rules | Always check whether sums to 1 over multiple actions before assuming determinism |
| Evaluating using only one rollout | Treating a single sampled return as if it equals | is an expectation; use many episodes and average, or solve exactly if the model is known |
| Ignoring the discount factor's role in convergence | Assuming iterative evaluation always converges regardless of | The contraction argument requires (or a properly terminating episodic setting); check this before trusting convergence |
| Mixing up which distribution the expectation is over | Forgetting that both action and transition randomness contribute to 's randomness | State explicitly: expectation is over the joint randomness of and |
Pioneers & history
Origins · 1 minRichard Bellman and how this was discovered
Bellman formalized dynamic programming and the principle of optimality in the 1950s, providing the mathematical language — states, decisions, and expected returns — in which policies and value functions are still expressed today.
Where this matters
Every reinforcement learning algorithm — from tabular Q-learning to deep policy-gradient methods used in large-scale robotics and game-playing systems — is ultimately manipulating one of two objects: a policy or a value function derived from one. Recommendation systems at scale formalize "which content to show" as a policy over user states, and evaluate candidate policies via estimated expected long-term engagement, directly mirroring . Autonomous driving stacks encode driving behavior as a policy over perceptual states and must certify that its expected return (safety-weighted) exceeds some threshold before deployment. Industrial control systems, from HVAC optimization to data-center cooling, are tuned by comparing policies through exactly the expected-return criterion introduced here. The distinction between policies (how to act) and value functions (how good acting that way is) is also the organizing principle behind actor-critic architectures in deep reinforcement learning, where one neural network represents and another approximates or a related quantity.
Ask the tutor: How does policy improvement use the value function v_π to construct a strictly better policy π′?
Can a policy depend on the entire history of states and actions, not just the current state?
In principle, yes — a policy could be defined over full histories rather than just the current state. However, for a Markov decision process, the Markov property guarantees that stationary, state-dependent policies are sufficient: no additional value can be extracted by conditioning on history beyond what the current state already encodes, since the future is conditionally independent of the past given the present state. This is why the standard definition restricts to depend only on , simplifying both the theory and the algorithms built on it, without losing any achievable performance.
Is the value function part of the policy, or something computed from it?
The value function is derived from a policy, not part of its definition. A policy only specifies action probabilities per state; it says nothing directly about long-run reward. The value function is a separate object computed by taking expectations over all the trajectories that , combined with the environment's dynamics, can generate. Two very different policies can, in principle, produce identical value functions, and conversely a single value function is meaningful only relative to the specific policy that generated it.
Why do we need the discount factor γ for the expected return to make sense?
Without discounting (γ = 1) in a task that can run indefinitely, the sum of infinitely many nonzero rewards can diverge, making the expectation undefined or infinite. Setting guarantees the geometric series of discounted rewards converges whenever rewards are bounded, since is a finite geometric sum. In episodic tasks with guaranteed termination, γ = 1 is often fine since the sum is naturally finite; the choice of γ is really about ensuring the mathematical object is well-defined and finite.
How is a policy actually represented in a real reinforcement learning system?
In tabular settings with small, finite state and action spaces, a policy can be stored explicitly as a table of probabilities, one row per state. In large or continuous state spaces, this is infeasible, so policies are instead represented parametrically — for example, as a neural network that takes a state as input and outputs either action probabilities (for stochastic policies) or a single action (for deterministic policies). The core mathematical definition, π(a|s), remains identical; only the representation and the method for adjusting π change between tabular and function-approximation settings.
What is the difference between evaluating a policy and improving a policy?
Evaluating a policy means computing or estimating for a fixed, unchanging π — this is the entire content of this article. Improving a policy means using that value information to construct a new, better policy π′, typically by acting greedily with respect to the computed values. These are two distinct operations that, when alternated, form the basis of policy iteration; but the concept of policy improvement itself and its correctness proof belong to later material building on the value functions introduced here.
Does every policy have a well-defined value function?
Yes, provided the expected return itself is finite — which holds automatically whenever rewards are bounded and either the discount factor satisfies γ < 1, or the task is episodic and guaranteed to terminate in finite expected time under π. If neither condition holds (for instance, an infinite-horizon undiscounted task where the policy never terminates and accumulates unbounded positive reward), the expectation defining can diverge, and the value function is not well-defined for that policy in that setting.
Why introduce the state-value function here rather than jumping straight to optimal policies?
Reasoning about optimal behavior requires first being able to compare any two policies, and the only rigorous way to compare them is through the expected returns they induce — exactly what captures. Attempting to discuss "optimal" policies before defining value functions leaves no precise criterion for what "optimal" even means. This ordering — policy, then expected return, then value function, then optimality — mirrors how the Bellman Equations and the notion of an optimal policy are subsequently built directly on top of these definitions.