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

State machines are a way to model a system as a set of states and the allowed transitions between them. In AI agents, a state machine controls what the agent can do next based on its current state, so the agent behaves predictably instead of improvising every step.

How It Works

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

A customer starts in one state: idle. They enter card details, so the system moves to authenticating. If 3DS or OTP is required, it moves to challenge_pending. If the user passes verification, it moves to authorized. If the bank declines, it moves to declined. If the customer abandons the flow, it moves to expired or cancelled.

That is a state machine:

• •States are the valid modes the system can be in
• •Events trigger movement between states
• •Transitions define which move is allowed
• •Guards enforce rules before moving
• •Actions run when entering, exiting, or staying in a state

For AI agents, this matters because an agent is not just “thinking.” It is deciding what tool to call next, what data to request, and when to stop. A state machine keeps that process controlled.

Example:

The key idea is simple: the agent cannot jump from collecting_payment_details straight to completed. It must pass through allowed states in order. That gives you deterministic control over something that would otherwise be messy.

A good analogy is airport security.

You do not go from curbside pickup directly to boarding. You move through check-in, baggage drop, security, and gate control. Each step has rules, and each rule determines whether you can proceed. A state machine works the same way for an AI agent handling payments or support workflows.

Why It Matters

Developers in payments should care because state machines solve real production problems:

• •

  They reduce bad agent behavior

  • •The agent cannot skip compliance checks or call tools out of order.
  • •That matters when money movement depends on strict sequencing.
• •

  They make retries safe

  • •Payment systems fail often: timeouts, duplicate webhooks, network splits.
  • •A state machine helps you retry only where it is valid, without double-charging or re-running irreversible steps.
• •

  They improve auditability

  • •Every transition can be logged.
  • •That gives ops teams and auditors a clear trail of what happened and why.
• •

  They help with human handoff

  • •Some cases need manual review: suspicious activity, chargeback disputes, failed KYC.
  • •The agent can move into a needs_review state and wait for an analyst instead of guessing.

For payments specifically, this is not theory. It is how you keep an AI agent from turning a customer support workflow into an uncontrolled tool-calling loop.

Real Example

Let’s take a bank dispute assistant handling a card chargeback claim.

The customer says: “I did not authorize this transaction.”

The AI agent should not immediately file the dispute. It should follow a controlled sequence:

1. •

   intake_started

   • •Collect transaction ID, date, amount, and merchant name.
2. •

   identity_verification_pending

   • •Verify the customer using OTP or existing session trust level.
3. •

   transaction_lookup

   • •Pull the ledger record and authorization details from core banking or card processor APIs.
4. •

   eligibility_checking

   • •Confirm whether the transaction qualifies for dispute based on scheme rules and internal policy.
   • •Example guard: dispute window must be within 120 days.
5. •

   evidence_collection

   • •Ask for supporting evidence if required.
   • •For example: “Was your card present?” “Did you receive goods?”
6. •

   case_submitted

   • •Create the dispute case in the back-office system.
7. •

   waiting_on_processor_response

   • •Pause until Visa/Mastercard/acquirer responds.
8. •

   resolved or rejected

   • •Notify the customer with next steps.

Here is what that looks like in code:

type DisputeState =
  | "intake_started"
  | "identity_verification_pending"
  | "transaction_lookup"
  | "eligibility_checking"
  | "evidence_collection"
  | "case_submitted"
  | "waiting_on_processor_response"
  | "resolved"
  | "rejected";

type Event =
  | { type: "IDENTITY_VERIFIED" }
  | { type: "TRANSACTION_FOUND" }
  | { type: "ELIGIBLE" }
  | { type: "NEEDS_EVIDENCE" }
  | { type: "CASE_SUBMITTED" }
  | { type: "PROCESSOR_RESPONDED"; outcome: "won" | "lost" };

function nextState(state: DisputeState, event: Event): DisputeState {
  switch (state) {
    case "intake_started":
      return event.type === "IDENTITY_VERIFIED"
        ? "transaction_lookup"
        : state;

    case "transaction_lookup":
      return event.type === "TRANSACTION_FOUND"
        ? "eligibility_checking"
        : state;

    case "eligibility_checking":
      if (event.type === "ELIGIBLE") return "evidence_collection";
      return state;

    case "evidence_collection":
      return event.type === "CASE_SUBMITTED"
        ? "waiting_on_processor_response"
        : state;

    case "waiting_on_processor_response":
      if (event.type === "PROCESSOR_RESPONDED") {
        return event.outcome === "won" ? "resolved" : "rejected";
      }
      return state;

    default:
      return state;
  }
}

This is not about writing more code for its own sake. It is about making sure your AI assistant behaves like a payment workflow engine with language understanding on top, not like a chatbot that can wander off script.

Related Concepts

• •

  Finite State Machines (FSMs)

  • •The classic version of state machines with a fixed set of states and transitions.
• •

  Workflow engines

  • •Tools like Temporal or Camunda that orchestrate long-running business processes across services.
• •

  Guard conditions

  • •Rules that decide whether a transition is allowed.
  • •Example: only allow dispute submission if KYC is complete.
• •

  Event-driven architecture

  • •State changes often happen because events arrive from APIs, queues, or webhooks.
• •

  Tool orchestration for agents

  • •The layer that decides which API call happens next and when to stop calling tools.

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.