What is state machines in AI Agents? A Guide for developers in retail banking

State machines are a way to model a system as a set of defined states and the allowed transitions between them. In AI agents, a state machine controls what the agent can do next based on where it is in the workflow.

How It Works

Think of a retail banking agent like a branch teller handling a loan application. The teller does not jump randomly from “collect documents” to “approve loan” to “disburse funds.” They follow a sequence: verify identity, collect income details, run checks, request missing documents, then approve or reject.

That is a state machine.

Each state represents the current condition of the agent or workflow:

• •idle
• •collecting_customer_details
• •verifying_identity
• •waiting_for_documents
• •running_risk_checks
• •escalated_to_human
• •completed

Each transition is triggered by an event or condition:

• •Customer submits ID
• •KYC check passes
• •Document upload fails
• •Risk score exceeds threshold
• •Agent needs human review

In an AI agent, the model may generate text, but the state machine decides whether that text is allowed to move the workflow forward. That matters in banking because you want deterministic control around regulated steps.

A simple mental model is a train line with fixed stations. The train can only move to the next station if the track exists. You do not let it skip from onboarding directly to account closure just because the model guessed a plausible answer.

Here is what that looks like in practice:

from enum import Enum

class State(Enum):
    IDLE = "idle"
    VERIFYING_IDENTITY = "verifying_identity"
    WAITING_FOR_DOCS = "waiting_for_docs"
    RUNNING_CHECKS = "running_checks"
    ESCALATED = "escalated"
    DONE = "done"

def transition(state, event):
    if state == State.IDLE and event == "start_onboarding":
        return State.VERIFYING_IDENTITY
    if state == State.VERIFYING_IDENTITY and event == "kyc_passed":
        return State.RUNNING_CHECKS
    if state == State.VERIFYING_IDENTITY and event == "docs_missing":
        return State.WAITING_FOR_DOCS
    if state == State.RUNNING_CHECKS and event == "risk_flag":
        return State.ESCALATED
    if state == State.RUNNING_CHECKS and event == "approved":
        return State.DONE
    return state

This pattern keeps your agent honest. The LLM can help interpret messages, extract fields, or draft responses, but the state machine owns control flow.

Why It Matters

• •

  Controls risk

  • •Banking workflows need hard boundaries.
  • •A state machine prevents an agent from skipping KYC, AML checks, or approval gates.
• •

  Makes behavior testable

  • •You can unit test every transition.
  • •That is much easier than testing free-form prompt behavior across hundreds of conversation paths.
• •

  Improves auditability

  • •Regulators and internal risk teams care about traceability.
  • •A state log gives you a clear record of what happened and why.
• •

  Reduces production surprises

  • •LLMs are probabilistic.
  • •State machines add deterministic guardrails so your agent behaves consistently under load and edge cases.

For retail banking teams, this usually means fewer broken customer journeys and fewer “the bot did something weird” incidents in production.

Real Example

Consider an AI assistant for credit card dispute intake.

The customer says: “I don’t recognize a $120 charge from last Friday.”

A good implementation would use these states:

The LLM’s job here is narrow:

• •Extract merchant name, amount, and date from natural language
• •Ask follow-up questions when fields are missing
• •Summarize the issue for the case management system

The state machine’s job is broader and stricter:

• •Ensure authentication happens before case creation
• •Block eligibility checks until required fields are present
• •Escalate if fraud language appears or policy rules fail

Example flow:

1. •Customer enters chat.
2. •Agent moves from idle to authenticate_customer.
3. •Identity verification succeeds.
4. •Agent transitions to collect_dispute_details.
5. •LLM extracts $120, Friday, and merchant name.
6. •Policy engine flags that the charge is older than the dispute window.
7. •Agent transitions to escalate_to_agent instead of creating a case.

That last step is the point. Without a state machine, an LLM might still sound confident while doing the wrong thing. With one, it can only take approved paths.

Related Concepts

• •

  Finite State Machines (FSMs)

  • •The classic formal version of this pattern.
  • •Useful when your workflow has clear states and transitions.
• •

  Workflow engines

  • •Tools like Temporal or Camunda handle long-running business processes.
  • •Better when you need retries, timers, compensation steps, and persistence.
• •

  Policy engines

  • •Decide whether an action is allowed based on rules.
  • •Often paired with state machines for compliance-heavy flows.
• •

  Tool orchestration

  • •How an agent calls APIs, databases, and internal services in order.
  • •State machines help prevent tool calls from happening out of sequence.
• •

  Human-in-the-loop routing

  • •Used when confidence is low or policy requires manual review.
  • •Common in disputes, lending exceptions, fraud review, and claims handling.

For retail banking teams building AI agents, the practical takeaway is simple: let the model handle language, but let the state machine handle control flow. That separation gives you safer automation without turning every conversation into an unpredictable experiment.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.