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

By Cyprian AaronsUpdated 2026-04-21
state-machinesctos-in-paymentsstate-machines-payments

State machines are a way to model a system as a set of states, with rules that control how it moves from one state to another. In AI agents, a state machine keeps the agent predictable by limiting what it can do at each step and defining the allowed transitions between actions.

How It Works

Think of a payment flow like a card transaction at an ATM or checkout terminal.

The transaction does not jump around randomly. It moves through clear states:

  • initiated
  • authenticated
  • authorized
  • settled
  • failed
  • reversed

A state machine formalizes that flow. If the agent is in authorized, it can move to settled or reversed, but not back to initiated unless you explicitly allow it.

For AI agents, this matters because the model itself is probabilistic, but the business process cannot be. You do not want an agent deciding whether to skip KYC, retry a failed payment endlessly, or send two refund instructions because it “felt right.”

A simple mental model is a bank teller with a checklist.

  • Before cash is handed over, identity must be verified.
  • After verification, the teller can approve or reject.
  • Once approved, the teller cannot go back and pretend verification never happened.

That is a state machine: each step has rules, and those rules prevent invalid actions.

Here is a minimal example for an AI agent handling payment disputes:

from enum import Enum

class State(Enum):
    NEW = "new"
    VERIFYING = "verifying"
    APPROVED = "approved"
    REJECTED = "rejected"
    ESCALATED = "escalated"

transitions = {
    State.NEW: [State.VERIFYING],
    State.VERIFYING: [State.APPROVED, State.REJECTED, State.ESCALATED],
    State.APPROVED: [],
    State.REJECTED: [],
    State.ESCALATED: []
}

def can_transition(current_state, next_state):
    return next_state in transitions[current_state]

In production, this logic usually sits beside the LLM, not inside it. The model suggests actions; the state machine decides whether those actions are allowed.

Why It Matters

CTOs in payments should care because state machines reduce operational risk without removing AI from the workflow.

  • They prevent invalid actions

    • An agent cannot issue refunds before fraud review is complete.
    • It cannot close a case that still needs compliance approval.
  • They make auditability easier

    • Every transition is explicit.
    • That gives you cleaner logs for PCI reviews, internal audit, and dispute investigations.
  • They reduce prompt fragility

    • You do not rely on prompt wording alone to keep the agent on track.
    • Business rules live in code and config, where they belong.
  • They improve incident containment

    • If an agent starts behaving badly, you can freeze specific transitions instead of disabling the whole system.
    • That is useful when you need to keep low-risk workflows running.

Real Example

Take chargeback handling for a card issuer.

An AI agent receives a dispute from a customer saying they did not authorize a transaction. The workflow might look like this:

StateWhat happensAllowed next states
receivedDispute created in CRMtriage
triageAgent checks merchant type, amount, velocity signalsrequest_docs, auto_approve, escalate
request_docsAgent asks customer for evidencereviewing_docs, closed_no_response
reviewing_docsAgent evaluates uploaded receipts and timelinesapprove_chargeback, deny_chargeback, escalate
approve_chargebackCase sent to network workflowclosed
deny_chargebackCustomer notified with reason codeclosed
escalateHuman analyst takes overclosed, maybe back to reviewing_docs

Now add an LLM into this flow.

The LLM can summarize documents, classify intent, and draft customer messages. But it does not get to decide that a case in received can jump straight to closed. The state machine blocks that transition.

That separation is what makes the system production-grade:

  • The model handles language and classification.
  • The state machine handles process control.
  • Your orchestration layer enforces both.

In banking and payments, this pattern also helps with:

  • fraud case routing
  • merchant onboarding
  • AML alert triage
  • refund approval workflows

You get deterministic process control around nondeterministic AI behavior. That is the core value.

Related Concepts

  • Finite state machines

    • The classic formal version of state-based logic.
    • Useful when you need strict control over workflows and lifecycle events.
  • Workflow engines

    • Tools like Temporal or Camunda often implement richer versions of state management.
    • Better when your process spans retries, timers, human approvals, and long-running tasks.
  • Agent orchestration

    • How multiple tools, prompts, and models are coordinated.
    • State machines often sit underneath orchestration as the guardrail layer.
  • Event sourcing

    • Stores every change as an event rather than only current state.
    • Strong fit for financial systems where traceability matters.
  • Policy engines

    • Used to enforce business rules like limits, permissions, and regulatory constraints.
    • Often paired with state machines to decide what transitions are legal.

Keep learning

By Cyprian Aarons, AI Consultant at Topiax.

Want the complete 8-step roadmap?

Grab the free AI Agent Starter Kit — architecture templates, compliance checklists, and a 7-email deep-dive course.

Get the Starter Kit

Related Guides