What is state machines in AI Agents? A Guide for CTOs in fintech

State machines are a way to model an AI agent as a set of defined states, with rules that control when it can move from one state to another. In AI agents, a state machine makes the agent behave predictably by limiting what it can do at each step.

How It Works

Think of a state machine like a bank’s loan application workflow.

A customer starts in Submitted, moves to KYC Review, then Risk Check, then either Approved or Rejected. The system does not “think” freely at each step. It follows allowed transitions based on events, data, and policy.

For AI agents, this matters because you do not want an LLM improvising across every turn. You want it to operate inside a controlled flow:

• •State: where the agent is right now
• •Event: what happened next
• •Transition: the rule that moves the agent forward
• •Action: what the agent does in that state

A simple fintech example:

This is much closer to how production systems work than a free-form chatbot. The model can still reason, summarize, extract fields, or classify documents, but the orchestration layer decides what happens next.

A useful analogy is an airport boarding process.

You do not let passengers jump from check-in straight to the plane. They must pass through security, gate verification, and boarding. A state machine is that gate logic for your AI agent.

For CTOs, the key point is this: state machines separate decision-making from control flow. The LLM handles interpretation. The state machine handles sequencing, retries, approvals, and escalation.

Why It Matters

CTOs in fintech should care because state machines solve problems that show up immediately in regulated workflows:

• •

  Predictability

  • •Agents stop behaving like black boxes.
  • •You know exactly which actions are possible in each stage of a process.
• •

  Compliance

  • •You can enforce mandatory steps like KYC, AML checks, or human review before final decisions.
  • •That makes audit trails easier to defend.
• •

  Fault tolerance

  • •If an API fails or a document is incomplete, the agent can stay in the same state and retry safely.
  • •You avoid broken flows and duplicate actions.
• •

  Separation of concerns

  • •Engineers define business logic in states and transitions.
  • •The model focuses on language tasks such as extraction, classification, or explanation.

This is especially important in banking and insurance where “almost correct” is not good enough. A chatbot that skips verification because it sounded confident is a liability. A state machine prevents that class of failure.

Real Example

Let’s take a credit card dispute workflow in a bank.

A customer reports an unauthorized transaction through an AI assistant. The assistant should not immediately promise reversal or start a refund. It should move through a controlled sequence:

1. •

   Intake

   • •Collect merchant name, amount, date, and reason.
   • •Confirm account ownership.
2. •

   Identity verification

   • •Ask for OTP or authenticate through existing session.
   • •If verification fails, stop and escalate.
3. •

   Case classification

   • •Determine whether this is fraud, billing error, or service dispute.
   • •Use the LLM here for classification and summarization only.
4. •

   Policy check

   • •Check if the transaction falls within dispute window.
   • •Check if provisional credit rules apply.
5. •

   Decision

   • •If eligible: create case and issue provisional credit.
   • •If not eligible: explain denial reason with policy reference.
   • •If ambiguous: route to human operations.

Here is what that looks like conceptually:

states = {
    "intake": ["verify_identity"],
    "verify_identity": ["classify_dispute", "manual_review"],
    "classify_dispute": ["policy_check", "manual_review"],
    "policy_check": ["approve_case", "deny_case", "manual_review"],
    "approve_case": [],
    "deny_case": [],
    "manual_review": []
}

current_state = "intake"

def transition(event):
    global current_state

    if current_state == "intake" and event == "identity_verified":
        current_state = "verify_identity"

    elif current_state == "verify_identity" and event == "verified":
        current_state = "classify_dispute"

    elif current_state == "classify_dispute" and event == "classified":
        current_state = "policy_check"

    elif current_state == "policy_check" and event == "eligible":
        current_state = "approve_case"

    elif current_state == "policy_check" and event == "ineligible":
        current_state = "deny_case"

    else:
        current_state = "manual_review"

In production, this would be backed by durable workflow infrastructure, not just a Python dict. But the pattern stays the same: each stage has explicit allowed transitions.

That gives you three things banks care about:

• •deterministic flow control
• •auditable decision points
• •safe human escalation

Related Concepts

• •

  Finite State Machines (FSMs)

  • •The classic implementation pattern behind many agent workflows.
• •

  Workflow engines

  • •Tools like Temporal or Step Functions often back stateful agent orchestration.
• •

  Guardrails

  • •Rules that constrain model output before it triggers transitions or external actions.
• •

  Human-in-the-loop review

  • •A required fallback for high-risk cases where automation should stop.
• •

  Tool calling / function calling

  • •The mechanism an LLM uses to invoke services while the state machine controls when those calls are allowed.

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.