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

State machines are a way to model an AI agent as a set of named states, with rules for when it can move from one state to another. In practice, they define what the agent is allowed to do next based on its current situation, so behavior stays predictable instead of drifting.

How It Works

Think of a state machine like a wealth management client onboarding workflow.

A new client does not jump randomly between “KYC review,” “risk scoring,” “document collection,” and “advisor approval.” They move through those steps in a controlled order, and each step has clear exit conditions. That is exactly what a state machine gives you for an AI agent.

For an AI agent, a state might be:

• •idle
• •collecting_documents
• •validating_identity
• •waiting_for_human_review
• •approved
• •rejected

The agent does not “decide” freely at every turn. It checks:

• •What state am I in now?
• •What event just happened?
• •Is this transition allowed?

That makes the system easier to reason about.

A simple example:

This is useful because AI agents often need guardrails. A language model can generate many possible responses, but your business process usually needs one valid next step. The state machine is the control layer that keeps the agent inside policy.

An everyday analogy: think of an elevator.

It has buttons, but it does not teleport between floors. It moves only through valid states: doors open, doors closed, moving up, moving down, stopped. Your AI agent should work the same way in regulated workflows. It should not skip from intake straight to approval because the model “feels confident.”

For engineering teams, this matters because the state machine becomes the source of truth for orchestration. The LLM can interpret text, summarize documents, classify intent, or draft responses. The state machine decides when those capabilities are invoked and what happens after each result.

Why It Matters

Engineering managers in wealth management should care because state machines reduce operational risk.

• •

  They make AI behavior auditable

  • •You can explain why the agent took a path.
  • •That matters when compliance asks for traceability on client-facing decisions.
• •

  They reduce hallucination impact

  • •The model may suggest something wrong.
  • •The state machine can block invalid transitions and force verification before action.
• •

  They simplify human-in-the-loop design

  • •Some steps need advisor review, compliance review, or operations approval.
  • •A state machine makes those handoffs explicit instead of burying them in prompt logic.
• •

  They improve failure handling

  • •If document extraction fails or sanctions screening returns a mismatch, you need a defined fallback.
  • •State machines make retry, escalation, and timeout logic deterministic.

For wealth management specifically, this helps with workflows like:

• •account opening
• •suitability checks
• •portfolio rebalancing approvals
• •beneficiary updates
• •adverse event escalation

These are not chatbots. They are regulated processes with branching logic and exceptions. State machines fit that reality better than free-form agent loops.

Real Example

Let’s say you are building an AI agent for new client onboarding at a wealth management firm.

The goal is to help advisors process incoming applications faster without losing control over KYC and suitability checks.

States

The agent uses these states:

• •intake_received
• •documents_missing
• •documents_complete
• •identity_check_running
• •identity_failed
• •risk_profile_pending
• •advisor_review_required
• •approved
• •rejected

Flow

1. •Client uploads forms and ID documents.
2. •The agent enters intake_received.
3. •It extracts data from documents and checks completeness.
4. •If something is missing, it moves to documents_missing and sends a precise request list.
5. •If complete, it moves to identity_check_running.
6. •A screening service validates identity and AML flags.
7. •If there is a mismatch, it goes to identity_failed and creates a case for compliance.
8. •If identity passes, the agent collects suitability answers and calculates risk profile.
9. •Once complete, it moves to advisor_review_required.
10. •An advisor approves or rejects the application.
11. •Final states are either approved or rejected.

Why this beats a pure LLM loop

Without a state machine, you might have prompts like: “Review the client file and decide what to do next.”

That sounds flexible, but it creates problems:

• •repeated document requests
• •skipped compliance checks
• •inconsistent routing to humans
• •hard-to-debug production incidents

With a state machine:

from enum import Enum

class OnboardingState(Enum):
    INTAKE_RECEIVED = "intake_received"
    DOCUMENTS_MISSING = "documents_missing"
    DOCUMENTS_COMPLETE = "documents_complete"
    IDENTITY_CHECK_RUNNING = "identity_check_running"
    IDENTITY_FAILED = "identity_failed"
    ADVISOR_REVIEW_REQUIRED = "advisor_review_required"
    APPROVED = "approved"
    REJECTED = "rejected"

def transition(state, event):
    if state == OnboardingState.INTAKE_RECEIVED and event == "missing_docs":
        return OnboardingState.DOCUMENTS_MISSING
    if state == OnboardingState.INTAKE_RECEIVED and event == "docs_complete":
        return OnboardingState.IDENTITY_CHECK_RUNNING
    if state == OnboardingState.IDENTITY_CHECK_RUNNING and event == "kyc_fail":
        return OnboardingState.IDENTITY_FAILED
    if state == OnboardingState.IDENTITY_CHECK_RUNNING and event == "kyc_pass":
        return OnboardingState.ADVISOR_REVIEW_REQUIRED
    return state

The value here is not the code itself. It is that every transition is explicit, testable, and reviewable by engineering, risk, and compliance teams.

Related Concepts

• •

  Finite State Machines

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

  Workflow Orchestration

  • •Systems like Temporal or Step Functions often run these transitions in production.
• •

  Human-in-the-loop Design

  • •Essential when advisors or compliance officers must approve certain actions.
• •

  Guardrails

  • •Rules that constrain what an AI agent can say or do at each step.
• •

  Event-driven Architecture

  • •Useful when external systems trigger transitions such as KYC results or document uploads.

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.