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

State machines are a way to model an agent as a set of defined states, where each state has clear rules for what can happen next. In AI agents, a state machine controls the agent’s behavior by moving it from one state to another based on events, inputs, or completed tasks.

How It Works

Think of a state machine like a bank card transaction flow.

A card payment is not “just happening.” It moves through states:

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

At each step, only certain transitions are allowed. If authentication fails, you do not jump straight to settlement. You move to a failure state, maybe trigger retry logic, or send the case to manual review.

That is exactly how state machines help AI agents.

Instead of letting an LLM improvise every step, you define the agent’s lifecycle:

• •State: what the agent is currently doing
• •Event: what happened next
• •Transition: how the agent should move
• •Action: what code runs during that transition

A simple fintech agent might look like this:

The key idea is control. The LLM can still interpret documents, classify intent, or draft responses. But the state machine decides what happens next.

That matters because fintech workflows are full of branching logic:

• •identity verification
• •fraud checks
• •payment retries
• •exception handling
• •compliance escalation

If you let an agent free-run through those flows, you get brittle behavior. If you wrap it in a state machine, you get predictable execution.

A useful mental model is a train network.

The train is your AI agent. The stations are states. The tracks are valid transitions. The train cannot teleport from “customer onboarding” to “loan disbursed” without passing through the required stations like KYC, risk scoring, and approval.

Why It Matters

Fintech teams should care because state machines solve problems that show up in production fast:

• •

  Predictability

  • •Regulated workflows need deterministic control.
  • •A state machine makes it obvious what the agent can do next and what it cannot do.
• •

  Auditability

  • •You can log every state transition.
  • •That gives compliance and ops teams a clean trail for investigations and reviews.
• •

  Error handling

  • •Failed OCR, timeout on an API call, duplicate submission, or partial completion all map cleanly to failure or retry states.
  • •That makes recovery logic much easier to reason about.
• •

  Safer LLM usage

  • •The model handles interpretation.
  • •The workflow engine handles control flow.
  • •That separation reduces hallucinated actions and accidental skips in regulated processes.

For product teams, this also makes behavior easier to explain to stakeholders. For engineers, it means fewer hidden edge cases buried inside prompt chains and ad hoc if/else logic.

Real Example

Let’s use a banking onboarding flow for opening a business account.

The goal is simple: collect documents, verify identity, run compliance checks, then either approve the account or escalate it.

A practical state machine might look like this:

1. •

   start

   • •Customer submits onboarding form.
   • •Transition to collecting_documents.
2. •

   collecting_documents

   • •Agent requests certificate of incorporation, tax ID, and director IDs.
   • •If all files arrive, transition to document_validation.
   • •If the customer abandons the flow for 48 hours, transition to stalled.
3. •

   document_validation

   • •OCR extracts names and registration numbers.
   • •Rules check whether document formats are valid.
   • •If data matches expected patterns, go to kyc_check.
   • •If not, go to manual_review.
4. •

   kyc_check

   • •Agent calls sanctions screening and PEP checks.
   • •If clear, go to risk_assessment.
   • •If flagged, go to compliance_review.
5. •

   risk_assessment

   • •Agent scores the business based on industry type, geography, and transaction volume estimate.
   • •Low risk goes to approved.
   • •High risk goes to underwriter_review.
6. •

   Terminal states

   • •approved: create account and notify customer.
   • •manual_review: assign case to operations.
   • •compliance_review: alert compliance queue.
   • •rejected: close application with reason code.

Here is why this works well in production:

• •The LLM can read messy uploaded documents and extract fields.
• •The workflow never depends on the LLM deciding its own next step.
• •Every branch is explicit.
• •Every failure path is handled before launch.

In practice, this means fewer broken onboarding flows and less operator intervention when something goes wrong.

A good implementation usually stores state in a durable system like Postgres or Redis with persistence around workflow execution. Then each event updates the current state atomically so retries do not duplicate actions like sending emails twice or creating duplicate cases.

Related Concepts

If you are building AI agents in fintech, these adjacent topics matter:

• •

  Finite State Machines (FSMs)

  • •The classic formal model behind many workflow engines.
• •

  Workflow orchestration

  • •Tools like Temporal or custom orchestrators that manage long-running business processes.
• •

  Event-driven architecture

  • •Useful when agent decisions depend on asynchronous events like webhooks or queue messages.
• •

  Guardrails for LLMs

  • •Constraints that keep model output within safe operational boundaries.
• •

  Human-in-the-loop systems

  • •Manual review steps where humans approve high-risk or ambiguous cases before execution.

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.