As Scouting Ninja denoted, you need to have associated data for the sprite. Things I used in the past for each sprite in a data driven approach are:
* A unique ID.
* A references that denotes the sprite sheet to be used.
* A frame which denotes the pixel region on the sprite sheet.
* A base point, given relative to the frame on the sheet.
* A transition table with
** a condition,
** the ID of the following sprite,
** a distance that denotes how to alter the world / screen position when using this transition.
Regarding the base point: It defines the one point that is mapped to the world / screen position of the sprite. For example, each "legged figure on the ground" sprite has its base point between the feet on the ground. The base point need not fit into the sprite's frame; e.g. the base point may be on the ground during jumping.
Regarding the transition condition: Of course, player input (in case of PC) oder AI decisions (in case of NPC) plays a role here, and automatic transitions are possible. But also timing can be incorporated here, e.g. input need to occur in a defined time range. Even entity or world state flags can be used.
For advancing look at the transition table of the currently selected sprite, pick the first transitions that has its condition computed to be true, alter the world / screen position accordingly to the offset, and set the referenced follower as the new selected sprite.
For rendering fetch the base point of the currently selected sprite, multiply it with the "sprite-to-screen" pixel ratio, add the result to the current world / screen position. Fetch the size of the sprite's frame, scale it by the same pixel ratio, add it to the position computed beforehand, and use this for the vertices of the image carrying rectangle. For each vertex, set the belonging frame co-ordinates for the texture access.
The above is somehow course, of course; the details need to be elaborated with respect to the engine.