Why State Is Crucial for Agentic Frontends
While large language models may seem omniscient, it’s clear that prompt engineering alone is neither a desirable nor sustainable way to build software.
For instance, OpenAI’s recently published A Practical Guide to Building Agents offers a great example of this thinking. One of their key criteria for using agents is when a task involves “difficult-to-maintain rules.” But what if the rules are easy to define? In many cases, a structured flow might still be the better option.
- Predictability: Flows are deterministic — you always know what the next step is. This is crucial in scenarios where compliance is critical (e.g., legal workflows), audit trails are required, or outcomes must be traceable.
- Control: Flows offer precise control over what is asked and how responses are handled, helping ensure consistent achievement of business goals.
- Ease of Debugging: Errors can be quickly identified by inspecting the flow diagram, state machine, or underlying logic.
- Cost & Performance: Flows are more cost-effective (no token usage or model latency) and faster to execute. They’re also easier to build, requiring no training data — just logic.
An agentic framework, therefore, should embrace a hybrid approach — combining the strengths of LLMs with traditional software constructs. This allows developers to choose the right tool for each task and build systems that are both intelligent and reliable. In fact, all most all agent framework support the notion of flow, but is flow enough for all the deterministc behavior we need?
In fact, almost every modern agent framework supports the notion of a flow — a structured way to define step-by-step interactions, for example Google agent development kit. But this raises an important question: Is flow alone enough to handle all the deterministic behavior we need?
Why do we separate frontend and backend
User-facing applications are typically structured into a frontend and a backend. This decomposition offers many benefits, both from technical and human resource perspectives:
- Separation of Concerns: Frontend handles UI/UX — what users see and interact with. Backend handles logic, data, and security — the behind-the-scenes engine.
- Scalability: Each can scale independently (e.g., frontend via CDN, backend via server clusters).
- Security: Sensitive logic and data stay on the backend, out of user reach.
- Parallel Development: Teams work faster by building UI and logic separately, connected via APIs.
- Multi-Platform Support: One backend can serve web, mobile, and other clients. This makes it easy to deliver consistent user experience across different touch points.
Why do frontends need state machines?
While the backend is typically modeled as a flow, the frontend is often modeled as state machine. This is because of a fundamental difference between the two: backend primarily handles the ‘happy path’ defined by business logic since user needs are known, whereas frontend must account for the various ways users might interact or negotiate the terms of the service.
When users have complex needs, it’s common that they can’t express what they want in a single step. They may refine their input or change direction as the interaction progresses. To ensure a consistent and predictable experience, regardless of the path taken, each transition (conversation) must depend only on the current state. The state machine can be a natural and robust model for managing user interactions, for other reasons:
1. Explicit Memory and Context: States act as memory units that hold contextual information, allowing the system to behave differently even with identical inputs, based on its current state.
2. Predictable and Verifiable Transitions: State machines provide a formal structure for defining and validating all possible transitions, facilitating verification and testing to ensure no unexpected paths or unreachable states.
3. Edge‑Case and Error Handling: By explicitly modeling error or fallback states, state machines make it easier to handle exceptional conditions and edge cases without cluttering the main flow logic.
4. Concurrency and Hierarchical States: Advanced state machines support parallel (orthogonal) and hierarchical states, enabling modeling of concurrent behaviors and reducing complexity by decomposing large systems into nested state regions.
5. Self‑Documentation and Maintenance: Each state and transition serves as a self‑documenting artifact, improving clarity and maintainability compared to exponentially sprawling flowcharts that become hard to read and update as complexity grows.
Parting words
Just because LLMs can be prompted to handle queries with common-sense responses doesn’t eliminate the need for deterministic programming to meet business objectives. On the backend, hybrid agentic frameworks need to support flows — and they do. But on the frontend, flow is not an effective conceptual model. To enable dependable interactions, the hybrid agentic framework must natively support state machines or statecharts, making it easier to build reliable conversational experiences when needed. This is the reason we build bethere.ai. Register today for early access to experience a principled way of building hybrid conversational experience.
