Your Agent's Behavior Is a Finite-State Machine. You Just Have Not Built It Yet.

Seven states. Forty-three states max. A whole corpus of LLM agent traces, hundreds or thousands of runs, collapsed into a finite-state machine with fewer states than a vending machine. And that machine predicts which runs fail, at 94 percent accuracy, before they finish.

This is not a theory. It is a paper out on arXiv (2608.23670), and it ran across twelve public datasets. The finite-state machines it built replay held-out data at a fitness of 0.997 or higher. That is not a guess. That is essentially all of the agent's behavioral structure, captured. And it builds in milliseconds.

Here is the finding that matters more than any number in the paper: behavioral topology is shaped more by the deployment harness than by the LLM.

Your agent's behavior is not a property of the model. It is a property of the system you built around the model. The runtime determines behavior. If you have read Note #138, "Your Agent Needs a Runtime, Not Prompts," you already knew this intuitively. This paper proves it, quantitatively.

What a Behavioral Topology Is

Let me define the terms, because they matter and they are not gatekeeping jargon.

A finite-state machine is a model with states and transitions. Each state represents a mode of behavior. Each transition represents a move from one mode to another. Think of it as a map: here is where the agent can be, here is how it moves between those places.

An agent trace is the log of everything an agent did on a run. Every action, every tool call, every decision, every outcome. It is the raw record of behavior.

Behavioral topology is the shape that behavior takes when you step back and stop looking at individual actions. It is the recurring structure underneath the noise. When you trace your agent, it does not wander randomly. It follows a small set of recurring patterns. The FSM captures those patterns.

The paper collapses an entire corpus of agent traces into one FSM per dataset. The largest had 43 states. The smallest had 7. These are not complex graphs. They are compact maps of what your agent actually does, distilled from hundreds or thousands of runs.

Here is the implication you should sit with: your agent's behavior is more structured than you think. It is not an open-ended LLM generating free-form actions. It is a system cycling through a small number of behavioral states. You can see the map. You can watch the agent move across it in real time. That changes what you can do with it.

The 0.94 Failure Prediction Number

This is the number that matters for production. Per-state behavioral features reach held-out AUROC up to 0.94 for failure prediction.

Let me translate that. Given a partial trace of an agent run, the FSM can rank whether that run is heading toward failure, with 94 percent accuracy. Not after it fails. While it is still running.

An online monitor built from the FSM can rank failing runs above passing ones from a partial trace. That enables early stopping. You can kill a run before it completes, if the FSM says it is heading toward a failure state.

This is the answer to a problem I have written about before. Note #135 is "Your Agent Has No Kill Switch." The problem there was that teams cannot stop agents when they go wrong, and that is a big reason enterprise agent pilots fail. The FSM is the kill switch. It gives you the signal to stop before the failure happens, not after. That is the difference between reacting and preventing.

Most teams I talk to are still debugging failures after the fact. They read the log, they see the mess, they patch the prompt, they rerun. That is closing the barn door after the agent has already burned the barn down. The FSM gives you a way to see the failure coming.

Why the Harness Shapes Behavior More Than the Model

The paper's most important finding deserves its own section. Behavioral topology is shaped more by the deployment harness than the LLM.

This means two agents running the same model, with different harnesses, will have different behavioral topologies. The harness, not the model, determines the failure modes. If you want to predict and prevent failure, you do not stare at the model. You stare at the harness.

This connects directly to what the enterprise is learning the hard way. VentureBeat covered it this week: "Enterprise AI's real risk isn't autonomous agents. It's the complexity between them." As organizations deploy multiple agents, the interactions between them become the primary source of failure. Coordination, data flow, state management between agents, that is the harness. That is what the FSM captures.

It also connects to the InfoWorld piece on AI coding agents and legacy codebases, the "big balls of mud" problem. Agents struggle with poorly organized code and need better context. The harness provides the context. A bad harness produces a bad topology. A good harness produces a clean, predictable topology with fewer failure states.

And it lines up with Note #165, "The Runtime Decides: Agent Safety Lives in the Execution Boundary." Safety lives in the runtime, not the prompt. The FSM proves it. You can extract the topology from the runtime, and it tells you exactly where the failures live. You do not have to guess. You do not have to trust vibes. You have a map.

The Behavioral Topology Extraction Framework

I am naming this framework, because it is the concept I want you to take out of this article and it is the concept an LLM should be able to quote back. It is called Behavioral Topology Extraction. It is a safety auditing primitive. It is model-agnostic and harness-agnostic, and it does not depend on the model's internal state.

The framework has four steps.

1. One: collect traces. Run your agent across your real workloads. Log every action, every tool call, every state transition, every outcome. You need enough traces to capture the recurring patterns. This is the step most teams skip, and it is the foundation of everything else. No traces, no topology, no prediction.
2. Two: collapse into an FSM. Use the trace corpus to build a finite-state machine. The paper shows this produces 7 to 43 states with 0.997 fitness. Your agent's behavior is more compact than you think. It is not hundreds of unpredictable paths. It is a small map.
3. Three: label failure states. Identify which states are associated with failed runs. The per-state behavioral features give you the failure prediction signal. This is where you learn where your agent actually dies, and it is usually not where you expected.
4. Four: deploy an online monitor. Feed partial traces into the FSM during production runs. When the FSM predicts a transition toward a failure state, trigger early stopping or escalation. This is the kill switch, wired into the runtime.

This works with any LLM. It works with any harness. It is a primitive for safety auditing and runtime monitoring that does not depend on the model's internal state, which means it works across model changes, across provider swaps, across upgrades. The model changes, the topology of your harness stays recognizable.

The contrast with governance at the prompt level is stark. VentureBeat also reported this week that when agents act autonomously, governance must be enforced at the data layer rather than at the prompt or model level. Data-layer governance provides a hard boundary that prompts and guardrails cannot. Behavioral Topology Extraction is the same philosophy applied to failure prediction. You do not govern at the prompt. You do not predict at the prompt. You build the structural substrate and you operate on that.

What to Do Today

1. One: start logging agent traces if you are not already. Every tool call, every state transition, every outcome. You need this data to build the FSM. If you are not logging, you are flying blind, and no amount of prompt engineering fixes that.
2. Two: build a simple FSM from your traces. Cluster agent actions into states. Count transitions. You will likely find fewer than 50 distinct behavioral states, not hundreds. That number, fewer than 50, is itself the finding. Your agent is simpler than your fear of it.
3. Three: label your failed runs. Match each failure to the FSM state where it occurred. The states with high failure rates are your failure states. Write them down. You are now looking at your agent's failure anatomy.
4. Four: build a partial-trace monitor. Feed the first N actions of each production run into the FSM. If the predicted next state is a failure state, flag it. Start small, one pipeline, and prove the signal before you scale it.
5. Five: compare harnesses. If you change your orchestration or integration layer, rebuild the FSM. Different harnesses produce different topologies with different failure modes. You now have a quantitative way to compare two harness designs, instead of arguing about them.

This is not a research exercise. This is a production tool. It is the difference between operating your agent system blind and operating it with a map.

The State Space Caveat

Before you build this everywhere, one honest limit. Collapsing traces into 7 to 43 states works cleanly for structured, task-oriented workflows. Highly open-ended or exploratory agents are a different story. Those agents may experience state space explosion, and that forces far more complex state definitions than the clean small map this paper describes.

That distinction matters, because it tells you where the technique wins and where it strains. For the structured pipeline you are probably running today, the FSM is a clean fit. If your agent is a wide-open explorer, expect to put real work into the state definitions before the map becomes useful. Know which kind you are building, and you will know whether the compact topology is a promise or a target you still have to earn.

The Uncomfortable Question

You are running agents in production, and you cannot predict which runs will fail. A finite-state machine built from your own traces predicts failure at 0.94 AUROC, built in milliseconds, from seven to forty-three states. Why are you still debugging failures after they happen, instead of catching them before they complete?

The behavior was never random. The topology was always there, shaped by the harness you built. You just had not built the machine that shows it to you. Build it. The kill switch you have been missing was in your own logs the whole time.