From State Machines to Emergent Agents: A Different Approach to Agent Design

Memrail Team • November 24, 2025

Most agent frameworks today still behave like explicit state machines.

Frameworks like LangGraph make this visible: you define nodes, wire them together with edges, and describe how state moves through the graph. That’s a reasonable starting point, but it runs into hard limits once you want agents that are richer, more reusable, and less brittle.

Memrail’s SOMA AMI™ is built around a different design assumption:

Instead of encoding control flow as a graph, let behavior emerge from structured state and declarative triggers.

In practice, this leads to a very different way of thinking about agent behavior, especially around scalability, reuse, and analyzability.

1. The “Graph Explosion” Problem

In a LangGraph-style model, you explicitly define edges:

“If A happens, go to node B.”

At small scale, that’s intuitive and easy to reason about. A simple booking flow might look like:

  • Ask for service
  • Ask for date
  • Confirm booking
  • Take payment

You can visualize the graph and see exactly how the user moves through it.

Problems appear as soon as you try to generalize or add cross-cutting behavior.

LangGraph Booking Agent Architecture: LangGraph Booking Agent Architecture

When edges start to blow up

Consider a seemingly minor requirement:

“The user should be able to cancel from any state.”

In a graph-centric design, that typically means:

  • Adding an edge from every relevant node to a “cancel” node.
  • Deciding, for each state, whether cancel is allowed, and how it interacts with in-progress work.
  • Keeping these edges in sync as you add new nodes over time.

As you grow features, the number of edges grows combinatorially:

  • Every new action needs to be threaded through existing states.
  • Every new state needs a policy for every existing action.

Over time, the graph tends to:

  • Become visually and conceptually “spaghetti”.
  • Accumulate hidden assumptions inside edge handlers.
  • Make it difficult to prove system-level properties (e.g., “Can we get stuck?” or “Is this state even reachable?”).

You’re fundamentally managing control flow as the primary artifact. That doesn’t scale cleanly.

2. A Flat Topology with Emergent Flow

SOMA AMI™ takes the opposite stance: it removes the explicit control-flow graph.

Instead of defining “from this node, go to that node,” you define Executable Memory Units (EMUs) with Triggers that specify when they are allowed to fire.

Conceptually, an EMU answers:

“Under which conditions on state should this behavior run?”

An EMU is activated when:

  • Its trigger conditions over state are satisfied.
  • The runtime scoring and selection rules say it is appropriate to execute.

Memrail SOMA AMI Booking Agent Architecture: Memrail Booking Agent Example

Declarative behavior instead of imperative edges

Rather than:

If we’re at node A and X is true, transition to node B.

you express rules like:

If tag.intent == 'book' and state.booking.service is missing,
then ask the user which service they want.

You don’t encode:

  • Where the user “came from”.
  • Which “node” they’re on.

You encode:

  • What the current state is (via ATOMs).
  • Which conditions are satisfied.
  • Which EMUs are eligible to act on that state.

The effective control flow is not hard-coded. It emerges at runtime from:

  • The evolving state.
  • The set of EMUs and their triggers.
  • The runtime’s selection and conflict-resolution rules.

The “cancel from anywhere” example, revisited

Revisit the earlier requirement:

“Allow the user to cancel at any time.”

In SOMA AMI™, you don’t add edges between all nodes. You define one EMU:

  • Trigger: tag.intent == 'cancel'
  • Action: apply cancellation logic (e.g., update booking state, emit confirmations, call tools).

You don’t modify any other EMUs.

Because the topology is flat and trigger-based:

  • That EMU becomes available anywhere that tag.intent == 'cancel' is true.
  • Future flows automatically gain access to cancellation as long as they produce that ATOM.
  • You avoid re-plumbing the graph every time you touch the behavior.

The “graph” is now a conceptual artifact that emerges from which EMUs are valid in which states, rather than a thing you have to maintain explicitly.

3. Structured State (ATOMs) Instead of Loose Dicts

Most graph-based frameworks pass around loosely structured state:

state = {
    "messages": [...],
    "booking_data": {...},
    "metadata": {...}
}

There’s usually no enforced schema; each node decides what keys it expects and how to interpret them. That creates a few issues:

  • It’s hard to validate that state is coherent globally.
  • It’s nearly impossible to statically analyze what sequences of states are possible.
  • Each edge can run arbitrary code, which defeats most attempts at global reasoning.

SOMA AMI™ enforces structure via ATOMs—typed, structured pieces of state, such as:

  • state.booking.service
  • state.booking.date
  • state.booking.id
  • tag.intent
  • user.profile.tier

Triggers are expressed directly over these ATOMs:

  • tag.intent == 'book' and not state.booking.service
  • tag.intent == 'cancel' and state.booking.id is not None
  • user.profile.tier == 'enterprise' and state.policy.requires_approval

Because both state and triggers are structured, several capabilities fall out naturally.

Reachability and dead-code analysis

With ATOMs and a well-defined trigger DSL, you can ask:

  • “Is there any possible configuration of ATOMs that would make this EMU fire?”
  • “Are there EMUs that are never satisfiable under any path?”
  • “Which states are reachable under the current set of EMUs?”

This enables reachability analysis, including:

  • Detecting EMUs that are effectively “dead code.”
  • Surfacing states that can be entered but never exited cleanly.
  • Generating decision topology reports that describe which EMUs are reachable from which conditions, and why.

Doing this for arbitrary Python in graph transitions is extremely difficult. Doing it over a constrained DSL and structured ATOMs is tractable.

The trade-off is explicit:

  • You invest more upfront in defining schemas and triggers.
  • In return, you gain the ability to analyze, refactor, and scale the system with much greater confidence.

4. A Useful Analogy: From Procedural Traversal to Query-Like Behavior

A helpful mental model comes from data systems.

With traditional, graph-based agents:

  • You’re writing something akin to procedural traversal:

    • “Start here, then follow these edges, then check this condition, then go over there…”

  • You manually encode how to move through the space of states.

With SOMA AMI™’s trigger DSL and ATOM structure:

  • You’re doing something conceptually closer to a query:

    • “For any state where these conditions hold, run this behavior.”

  • You describe the conditions and let the system handle when and where that behavior becomes active.

The syntax makes this feel familiar: a set of predicates over a structured state space, evaluated within a runtime that decides which matching behaviors to execute.

The key consequence is:

  • You’re no longer drawing and maintaining a giant flowchart.
  • You’re defining a set of rules over state, and the agent’s behavior emerges from those rules interacting with the live context.

5. Where the Complexity Actually Lives

In a graph-centric world, most of the complexity ends up in:

  • Managing control flow and transitions.
  • Avoiding combinatorial edge blow-up.
  • Keeping mental track of “what can happen from where.”

In a trigger- and ATOM-centric world, the complexity shifts to:

  • Designing a good state schema (ATOMs).
  • Defining clear, composable triggers.
  • Establishing runtime policies for scoring and conflict resolution.

That shift is intentional.

We know from other domains (databases, reactive systems, policy engines) that good structure on state and predicates scales better than hand-maintained, deeply nested control flow. SOMA AMI™ applies that lesson directly to agent design.

Closing Thoughts

This isn’t about declaring graphs “wrong” and declarative agents “right.” Graph-based tools are useful, especially for prototyping and visualizing flows.

The point is narrower and more practical:

  • If you want agents that are scalable, auditable, and amenable to analysis, it’s worth re-centering the design around structured state and declarative triggers, rather than a growing web of edges.
  • SOMA AMI™ is one concrete architecture that does exactly that: a flat topology, ATOM-based state, and a trigger-driven runtime that lets behavior emerge from conditions over state instead of from hand-assembled control-flow graphs.

That shift—from managing flows to modeling state and triggers—is where much of the leverage comes from as these systems grow beyond toy examples into real infrastructure.