Markov Decision Processes — The Math That Frames Every RL Problem

Behind every reinforcement learning algorithm is one formal structure: the Markov decision process. It's the precise way of writing down "an agent making a sequence of decisions under uncertainty," and once a problem is framed as an MDP, the whole toolkit of RL applies to it. This post builds the MDP from its parts and explains the one assumption — the Markov property — that makes the entire theory work.

Post 1 described RL informally as an agent-environment loop. This post gives it the mathematical frame that the rest of the series stands on. You don’t need heavy math to get the MDP — you need to understand its five components and why framing a problem as an MDP is the first real step in applying RL to anything.

The five components of an MDP

A Markov decision process (MDP) is the formal model of sequential decision-making under uncertainty. It has five parts, each naming something from post 1’s loop:

An MDP ties these together: the agent is in a state, picks an action, transitions (stochastically) to a new state and gets a reward, repeatedly. The goal, made precise: find a policy (post 1) that maximizes the expected cumulative discounted reward — the return. Every RL problem, from Atari to RLHF, is ultimately “solve this MDP.”

The Markov property: why the present is enough

The “Markov” in MDP is a specific, load-bearing assumption: the Markov property states that the future depends only on the current state, not on the history of how you got there. The present state captures everything relevant for deciding what to do next.

This matters enormously because it makes the problem tractable. If the agent had to consider its entire history at every step, the problem would be impossibly complex. The Markov property says: forget the past; the current state is a sufficient summary. A chess position is Markov — you don’t need the move history to decide the best move, just the board. This assumption is what lets RL use the clean recursive machinery (value functions, the Bellman equation, post 3) that the whole field depends on.

The practical consequence is that state design is everything: the state must contain enough information to be Markov. If a robot’s state is just its current camera frame, it isn’t Markov — the frame doesn’t capture velocity, which matters — so practitioners include velocity (or stack several frames) to make the state Markov. Much of the engineering of an RL problem is defining a state representation rich enough that “the present is enough” actually holds. When people say RL is hard to apply, a large part of what they mean is that framing the real problem as a clean MDP — especially designing a Markov state and a good reward — is hard.

Reward design: the subtle, decisive part

Of the five components, the reward function deserves special attention because it’s where RL most often goes wrong. The reward defines the goal, and the agent will maximize it literally — including in ways you didn’t intend:

So the MDP’s elegance — maximize reward — hides its hardest problem: saying what you actually want in the language of reward. Framing a real problem as an MDP is mostly the work of designing a Markov state and an intent-aligned reward, and that framing is where RL projects are won or lost before any algorithm runs.

The throughline: every RL problem is formalized as a Markov decision process — states, actions, a stochastic transition function (where uncertainty lives, often unknown and learned), a reward function (which defines the goal), and a discount factor γ (weighing future vs immediate reward) — with the objective of finding a policy maximizing expected cumulative discounted reward (the return). The load-bearing assumption is the Markov property (the future depends only on the current state), which makes the problem tractable and the recursive RL machinery possible — so state design must make “the present is enough” actually hold. And the subtle, decisive part is reward design: the agent maximizes reward literally, so misspecified rewards cause reward hacking, and aligning reward with true intent is RL’s central practical difficulty — the very problem RLHF later solves by learning the reward.

Key takeaways

Further reading

Sources & References