Skip to content
NTPU AI Learn

AI 302 · Module 2

State, Loops & State Machines

For a system to run reliably, it must know where it is right now.

Start Section 1
  • Duration60 min
  • LevelArchitect
  • PrerequisiteAI 302 Module 1 recommended; AI 202 (Agentic AI Planning & Reasoning) recommended
0 / 7 completed
Sync my progressJoin a session to keep progress across devices and share it with your instructor

Info

After you join, your completed lesson numbers are sent to your instructor together with your learner code, so they can see your progress. Use the codes your instructor gave you, and do not enter your name, company secrets or other personal data. Progress is kept with the rest of that session's data.

Learning objectives

  • Explain State, and distinguish Workflow state, Agent state and Execution state
  • Distinguish Ephemeral state from Persistent state and decide which to use
  • Represent a workflow as states, transitions and transition conditions, with a state machine
  • Design Terminal states, Error states and Human review states
  • Answer the six state design questions for each state
  • Design a controlled execution loop with a clear stop condition, and avoid unbounded loops
  • Convert an Agentic workflow into an Agent State & Transition Map using simulated data

Problem and need

8 min

When nobody knows where the run is

In Module 1 you saw that a harness controls how a run is carried out. Every one of those controls depends on one thing: the system must know where the run is right now. The core question is: for a system to run reliably, how does it know where it currently is?

Work scenario (simulated)

An agent processes a supplier invoice. It reads the invoice, matches it to a purchase order, checks the amount, and prepares a payment request. The run stops. Somebody asks: has the invoice been matched? Has the amount been checked? Is the payment request waiting for a person, or was it never created? The agent cannot answer, because the only record of progress was inside its own conversation, which is gone. The team has to read the whole history to guess.

  • If the run has no explicit position, it cannot pause and resume with confidence
  • If the next step is chosen only by the model, the same run can go different ways each time
  • If failure and review are not named situations, they are handled by improvisation
  • If nobody can name where a run is, nobody can say who should act on it

Warning

Keeping track of progress inside a long conversation is fragile. Making the position of the run an explicit, named state is a design decision, and it is what the rest of this course builds on.

Key takeaway: Reliable execution starts with knowing where the run is. Make the position of a run an explicit state and not something buried in a conversation.

State

9 min

What is State? Workflow, Agent and Execution state

State is the information a system needs to remember about an execution so that it can continue correctly. Three kinds are easy to confuse, and each answers a different question.

Three kinds of state (simulated invoice example)
KindThe question it answersExample
Workflow stateWhere is the run in the designed process?Invoice matched; amount check in progress; payment request not yet created
Agent stateWhat does the agent currently hold in order to decide?The working notes, the plan for the next step, the facts it extracted from the invoice
Execution stateWhat is the run itself doing, as a running system?Run started at 09:02; attempt 2 of 3 on the amount check; waiting for a reply from the purchase order system

Workflow state: the map position

  • Belongs to the designed process
  • Has a small set of named values, such as MATCHING or AWAITING_REVIEW
  • Decides what may happen next

Agent state: the working memory

  • Belongs to the agent and its reasoning
  • Is rich and changes often, such as notes and extracted facts
  • Informs what the agent chooses, but does not by itself define where the run is

Info

A common mistake is to let the agent state stand in for the workflow state. The agent may write "I think I am nearly done", but the harness needs a named state such as VERIFYING that it can read, check and act on.
Check yourself

The record says "amount check, attempt 2 of 3, waiting for a reply from the purchase order system". Which kind of state is this mainly?

The record says "amount check, attempt 2 of 3, waiting for a reply from the purchase order system". Which kind of state is this mainly?

Key takeaway: Workflow state is where the run is in the process, Agent state is what the agent works with, and Execution state is what the running system is doing. Keep them separate.

9 min

Persistent and ephemeral state

Not all state needs to survive an interruption. Persistent state is saved so that it outlives the process and the conversation. Ephemeral state exists only while a step is running and can be lost or rebuilt. Deciding which is which is a design choice, and it determines what a run can recover from.

Persistent and ephemeral state (simulated invoice example)
Persistent stateEphemeral state
MeaningSaved outside the running process, so it survives interruptionHeld only while the step runs, and lost if the step stops
ExamplesThe current workflow state, the invoice reference, which actions already took effect, the result of each verificationA partly written draft, a temporary calculation, the current model conversation turn
If lostThe run cannot continue with confidence, and may repeat or skip actionsThe step can usually be run again with no harm
CostNeeds storage, care and sometimes protection because it may hold sensitive dataCheap and simple, but not something to rely on afterward
  • Persist what you need to continue correctly: the position, the decisions made, what has already happened outside
  • Do not persist everything. Storing every scrap makes state large, costly and harder to protect
  • Prefer a reference to a sensitive document over a copy of it, and never store what you do not need
  • Information that can be rebuilt from persistent state can usually stay ephemeral

Info

Checkpoints, which save state at chosen points so that a run can resume, are the subject of a later module. Here the goal is only to decide, for each piece of information, whether it must survive an interruption.
Check yourself

A run has already sent a payment request to an outside system. Which is the best way to treat the fact "payment request sent"?

A run has already sent a payment request to an outside system. Which is the best way to treat the fact "payment request sent"?

Key takeaway: Persist what the run needs in order to continue correctly, and especially what has already happened outside. Keep the rest ephemeral, and store as little sensitive data as possible.

State machines

9 min

State machines: states and transitions

A state machine describes a workflow as a set of named states and the allowed transitions between them. Each transition happens only when a stated condition is met, so the next step is decided by an explicit rule and not by chance. A state machine can still contain agent reasoning inside a state. What it fixes is the shape of the run.

A state machine for a simulated invoice run
  1. START: the run is created from a trigger
  2. PLANNING: the agent decides how to handle this invoice
  3. EXECUTING: the agent carries out a step, for example matching to the purchase order
  4. VERIFYING: the harness checks the result, and one of four transitions follows
  5. PASS goes to NEXT: continue to the next step, or finish in a terminal state
  6. RETRY goes back to EXECUTING: try the step again, within a limit
  7. HUMAN goes to REVIEW: a person reviews or decides
  8. FAIL goes to FAILED: the run stops as failed

Text equivalent: the run begins in START and moves down to PLANNING and then EXECUTING. From EXECUTING it moves to VERIFYING. VERIFYING is the branching point and has four outgoing transitions. If the result passes, the run moves to NEXT, which starts the next step or ends the run in a terminal state. If the result should be tried again, the run returns to EXECUTING, which forms a loop, and this loop must have a limit. If a person must decide, the run moves to REVIEW and waits. If the result cannot be accepted and cannot be retried, the run moves to FAILED and stops. Every arrow has a condition, and every state is reachable by at least one arrow.

Parts of a state machine
PartMeaningExample
StateA named situation the run can be inEXECUTING
TransitionAn allowed move from one state to anotherVERIFYING to EXECUTING
Transition conditionThe rule that must be true for the moveThe check found a problem and attempts are below the limit
Terminal stateA state with no way out; the run endsDONE or FAILED
Check yourself

In the state machine, what is the main purpose of the VERIFYING state?

In the state machine, what is the main purpose of the VERIFYING state?

Key takeaway: A state machine names the states, the allowed transitions and the condition for each. It makes the next step an explicit rule, and it must have terminal states.

9 min

Error states, human review states and design questions

Two kinds of state are easy to forget when designing the happy path: states for when something goes wrong, and states where a person is involved. If they are not named, they will be handled by improvisation.

Error states

  • Name what kind of failure occurred, such as FAILED or BLOCKED
  • Say whether the run can recover or must stop
  • Keep the reason, so a person can see what went wrong

Human review states

  • Name the point where the run waits for a person, such as AWAITING_REVIEW
  • Say what the person must decide and what they need to see
  • Define what happens next for each answer: approve, reject or change
Six state design questions, asked of every state (simulated: state AWAITING_REVIEW)
QuestionExample answer for AWAITING_REVIEW
What information is required?The invoice reference, the check results and the reason review was requested
What actions are allowed?A reviewer may approve, reject or send back; the agent may not act
What causes transition?The reviewer decision; or a timeout after two working days
What happens on failure?If no reviewer responds in time, notify a named person and keep waiting
Is state persisted?Yes, because waiting can last a long time and must survive interruption
Can execution safely resume here?Yes, because no outside action has happened yet in this state

Info

Human-AI-Human: a human review state is a designed part of the process, not a sign of failure. A person defines when review is required, the agent prepares what the reviewer needs, and the person decides and remains responsible.
Check yourself

Which is the best reason to give a workflow an explicit human review state?

Which is the best reason to give a workflow an explicit human review state?

Key takeaway: Name your error states and human review states. For every state, answer the six questions: information, allowed actions, transition, failure, persistence and safe resume.

Execution loops

8 min

Execution loops, and how to keep them bounded

A loop is what makes an agent system adapt: execute, check, and try again or change course. Loops are useful, and loops are also how a run can cycle forever or waste cost. The rule is to use controlled loops, and to avoid unbounded loops.

A controlled execution loop
  1. Execute: carry out the current step
  2. Verify: check the result against a stated criterion
  3. Pass?
  4. Yes: continue to the next step
  5. No: choose retry, re-plan or human review, and count the attempt
  6. When the limit is reached: leave the loop and go to review or a failed state

Text equivalent: the loop starts by executing a step and then verifying the result. If the result passes, the loop ends and the run continues. If it does not pass, the harness chooses between retrying, re-planning or asking a person, and it adds one to an attempt counter. The loop is only allowed to repeat while the counter is below a limit. When the limit is reached, the run must leave the loop and move to a human review state or a failed state, and it must not go around again.

  • Every loop needs a loop condition, a stop condition, and a limit such as maximum attempts, time or cost
  • What to do on a failed check must be stated: retry the same step, re-plan, or ask a person
  • The counter belongs in persistent state, or a restart resets the limit and the loop can run again
  • A loop that changes nothing between attempts will only repeat the same failure

Info

Implementation example (not the only model): in a stateful framework such as LangGraph, a loop is a cyclic graph, where a conditional edge sends the run back to an earlier node. The framework does not add the limit for you, so the counter and the stop condition are still your design decision.
Check yourself

A run repeats "execute, then verify" whenever the check fails, with no attempt limit. What is the main risk?

A run repeats "execute, then verify" whenever the check fails, with no attempt limit. What is the main risk?

Key takeaway: Use controlled loops: a condition, a stop condition and a limit, with a counter that survives restart. When the limit is reached, go to a person or a terminal state.

Practice and apply

8 min

Practice: Build the State Model

Activity 2 asks you to convert an Agentic workflow into a state model. Use the worked example to practice, then do the same for your own system from Module 1. Please do not enter real company secrets, client personal data or any unauthorized sensitive information in this exercise.

Worked example (simulated): a supplier invoice workflow
StateTypeMoves on whenOn failure or limit
RECEIVEDStartThe invoice is stored and a reference is createdGo to REJECTED_INPUT
MATCHINGWorkingThe invoice matches a purchase orderGo to AWAITING_REVIEW
VERIFYINGVerificationThe amount is within the approved amountRetry up to two times, then AWAITING_REVIEW
AWAITING_REVIEWHuman reviewA reviewer approves, rejects or sends backAfter two working days, notify a named person
PAYMENT_PREPAREDWorkingThe payment request is created for a person to releaseGo to FAILED
DONETerminalA person has released the paymentNot applicable
FAILEDTerminal, errorNot applicableReason recorded; a person is told
  1. List the states
    For your system, name the start state, the working states, the verification states, the human review states, the error states and the terminal states.
  2. Draw the transitions
    For each state, write where it can go and the condition for each move. Make sure every state can be reached and every path ends in a terminal state.
  3. Bound the loops
    Mark every loop, and give it a stop condition and a limit. Say what happens when the limit is reached.
  4. Ask the six questions and classify data
    For each state, answer the six design questions and decide which information is persistent and which is ephemeral.

Info

Deliverable: an Agent State & Transition Map showing your states, transitions with conditions, terminal states, error states and human review states, with a text description of it. It becomes part of your Agent Harness & Reliability Canvas.
Check yourself

Which statement best describes a good Agent State & Transition Map?

Which statement best describes a good Agent State & Transition Map?

Key takeaway: Human-AI-Human: a person designs the states, transitions and review points, the agent works inside them, and a person reviews the result and stays responsible for it.

Save as PDF

What next?