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

State machines are a way to model an AI agent as a set of defined states, with rules that control how it moves from one state to another. In AI agents, a state machine keeps the agent predictable by making each step depend on the current state, the input it receives, and the transition rules you define.

How It Works

Think of a state machine like a card payment flow.

A payment starts in initiated, moves to authorized, then either becomes captured, failed, or reversed. You do not let the system jump from “initiated” straight to “settled” unless the right conditions are met. The same idea applies to an AI agent handling work like customer support, fraud review, claims intake, or dispute resolution.

For engineering managers, the useful mental model is this:

• •State = what phase the agent is currently in
• •Event/input = what happened next
• •Transition rule = whether the agent is allowed to move forward
• •Action = what the agent does when it enters a new state

Example:

This is different from letting an LLM “just decide.” A pure prompt-driven agent can be inconsistent. A state machine gives you control over what happens next, which matters when your workflow touches money, compliance, chargebacks, underwriting, or customer communications.

A simple analogy: think of an airport security line.

You do not let every passenger go wherever they want. They move through checkpoints in order: ID check, bag scan, manual inspection if needed, then boarding. If something fails, they do not continue as if nothing happened. That is exactly how a good AI agent should behave in payments: controlled progression, explicit exceptions, and no silent skipping of steps.

Why It Matters

Engineering managers in payments should care because state machines solve problems that show up in production immediately:

• •

  They reduce hallucination risk

  The agent cannot invent new paths if every valid path is explicitly defined. That matters when the output triggers money movement or customer-facing actions.

• •

  They make audits easier

  You can trace why the agent moved from one step to another. In regulated environments, “the model decided” is not enough.

• •

  They improve failure handling

  Payments systems already have retries, reversals, timeouts, and idempotency concerns. State machines fit naturally with those patterns.

• •

  They help teams scale safely

  Product teams can understand the workflow at a high level, while engineers can map each state to concrete services, prompts, and validators.

A practical bonus: state machines also make it easier to test. You can write tests for each transition instead of trying to validate one giant prompt end-to-end.

Real Example

Let’s take a banking example: an AI agent that helps process disputed card transactions.

The goal is not for the agent to “solve disputes” freely. The goal is for it to gather facts, classify the dispute type, decide whether more evidence is needed, and route correctly.

A simple state machine might look like this:

1. •

   case_opened

   • •Triggered when a customer submits a dispute.
   • •Agent collects transaction metadata and merchant details.
2. •

   evidence_check

   • •Agent checks whether required fields exist:
     • •transaction date
     • •amount
     • •reason code
     • •supporting documents
   • •If data is missing, move to request_more_info.
3. •

   classification

   • •Agent classifies the dispute:
     • •fraud
     • •service not received
     • •duplicate charge
     • •billing error
4. •

   policy_evaluation

   • •Agent checks internal policy rules:
     • •Is this within filing window?
     • •Is this eligible for auto-resolution?
     • •Does it require manual review?
5. •

   resolution_ready

   • •Agent prepares a recommendation:
     • •approve provisional credit
     • •deny due to policy mismatch
     • •escalate to analyst
6. •

   Terminal states

   • •approved
   • •denied
   • •manual_review
   • •closed

What makes this useful is control.

If the LLM misclassifies a dispute as fraud when it is actually a billing error, the state machine can still block an invalid transition if policy says fraud cases above a certain amount require analyst review. The model assists with classification and summarization; the workflow engine enforces process boundaries.

That separation is what you want in payments:

• •LLM handles language-heavy work
• •State machine handles workflow integrity
• •Deterministic rules handle compliance gates

Here is a simplified version:

class DisputeStateMachine:
    def next_state(self, state, event):
        if state == "case_opened" and event == "docs_received":
            return "evidence_check"

        if state == "evidence_check" and event == "info_complete":
            return "classification"

        if state == "classification" and event == "policy_clear":
            return "resolution_ready"

        if state == "policy_evaluation" and event == "needs_manual_review":
            return "manual_review"

        return state  # no invalid jumps

In production you would add logging, idempotency keys, retries for external calls, timeout handling, and explicit terminal states. But even this small example shows the core idea: every action has a place in the flow.

Related Concepts

• •

  Finite State Machines (FSMs)

  The classic version of this pattern: fixed states and fixed transitions.

• •

  Workflow orchestration

  Tools like Temporal or Step Functions often implement business workflows using similar ideas.

• •

  Guardrails

  Rules that prevent unsafe or invalid outputs from moving the agent forward.

• •

  Idempotency

  Critical in payments so repeated events do not create duplicate actions.

• •

  Human-in-the-loop escalation

  A common terminal or fallback path when automation cannot safely continue.

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.