Every innovation that has been added to Xbase++ over the years followed the same guiding principle: give developers new power, but never take away any code of the past. New technologies are added not as an isolated island, but integrated into the existing technical landscape. Put simply, we never made things black or white — we always made them gray. The forthcoming Xbase++ V3 AgenticAI framework is the next innovation in that line — and, like the others, it is built on that same principle. Even the Microservice Architecture (MSA) supports your existing legacy application.
This essay is the reasoning behind it. It explains, on an abstract level, why the AgenticAI framework is deliberately a hybrid — why it combines a Large Language Model (LLM) with a Finite State Machine (FSM), instead of letting an LLM drive everything. Once this is understood, the design of the framework will feel natural, even obvious.
Most Xbase++ developers build Line-of-Business (LOB) applications. These applications calculate tax. They post to a ledger. They approve or reject a credit limit. They generate a legal invoice number. These are not tasks where "usually correct" is acceptable. They must be correct, repeatable, and explainable.
When a customer disputes an invoice, the application must show exactly how the number was produced. When the tax office asks a question, it must reproduce the same calculation from the same data and return the same result. When a bug appears, the same input must produce the same behavior again, so the developer can find and fix it.
A programming language such as Xbase++ is deterministic: the same input produces the same output, no matter how many times it runs. That is what makes the software built with it testable and traceable.
An LLM is, at its heart, a probabilistic system. It predicts likely text. This gives it remarkable flexibility with language and with messy, unstructured data. But it carries a weakness that cannot be removed: it is not deterministic.
Give the same model the same prompt twice, and it may return two different answers. Even when we try to force stable output by setting the temperature to zero, small differences in the model, the hardware, or the way requests are processed can change the result.
The model can also be confidently wrong — it can invent a value that looks perfectly reasonable but is simply not true. This is called a hallucination, and it has its roots in a simple fact: the LLM produces an answer about something it has not learned and cannot derive.
For a chat assistant, this variability is acceptable, even pleasant. For a system that posts money to a ledger, books flights, or processes customer complaints, it is a serious risk. A system of record cannot rest on a component that may answer differently tomorrow than it did today. This single fact shaped the entire design of the AgenticAI framework.
There is a fashionable idea today called the "agent." The concept is that an LLM drives the whole workflow. It reads a request, decides which tools to call — for example through MCP, the Model Context Protocol — looks at the results, decides the next step, and repeats until the job is done. In a demonstration, it looks like magic.
But for LOB applications, letting an LLM drive the entire workflow creates two further practical problems, in addition to the non-deterministic gap — and both grow without limit.
Latency: A single call to a capable LLM does not take microseconds, as a compiled routine does. It takes seconds. An agent workflow is not one call — it is a loop of many calls. The model thinks, calls a tool, reads the result, thinks again, and calls another tool. Five or ten steps are common. What used to be an instant operation now takes twenty, thirty, or sixty seconds. Users who are used to pressing Enter and seeing the result immediately will not accept this for their daily work.
Cost: LLMs are billed by the token — every word in and every word out. An agent that carries a large context and takes many steps can consume tens of thousands of tokens for a single task. That may be a fraction of a cent or several cents. It sounds small. But an LOB application does not run one task. It runs hundreds or thousands of transactions per day. Multiply a "small" per-task cost by that volume, and the operating bill does not grow gently — it skyrockets. Worse, it becomes variable and hard to predict, which is exactly what a business hates in its running costs.
Compare this to the Xbase++ solution - your code - your customers already trust. A deterministic routine running on a server they own costs almost nothing per transaction, runs in milliseconds, and behaves the same way every time. That is a very hard advantage to give up — and there is no good reason to give it up.
There is a further problem beneath these two. An FSM gives a clean trace: this state, this event, this rule, this transition. An LLM's internal reasoning is opaque and cannot be reproduced. As the primary decision-maker in a regulated workflow, it is weak. It cannot be fully explained, and it cannot be fully reproduced.
So three problems stack on top of each other: non-determinism, high latency, and unpredictable cost. For LOB software, all three point in the same direction.
This is why we did not design the AgenticAI framework as an "LLM that runs the application." We designed it as a hybrid, on one clear rule: put determinism at the core, and intelligence at the edges.
At the core sits a Finite State Machine. The business process is expressed as explicit states and transitions. An order, for example, moves through clear states — created → validated → approved → fulfilled → invoiced → paid — and each transition is governed by clear rules. This FSM is the backbone of the workflow. It is:
This is the system of record. This is where money moves and where decisions become official. In the AgenticAI framework, the LLM can be a component that performs a single task — such as extracting structured data from a business document, or judging the tone of an email — but it does not drive this core loop.
Instead, the LLM works at the boundaries, where the clean, structured system meets the messy, unstructured human world. This is exactly where the LLM is strong and the FSM is weak:
If there is one sentence to take from this essay, take this one: the LLM proposes, the state machine disposes.
The LLM may suggest a value, a classification, or a next step. But its output is treated as untrusted input, exactly like data typed by an unknown user. Before it can trigger a state transition, it must pass through deterministic validation: Is it in the right format? Is the value within the allowed limits? Does it satisfy the business rules? Only then may the FSM act on it. The LLM never directly causes an irreversible business action on its own.
This is what lets the framework offer both things at once: the intelligence of an LLM exactly where it is needed, and full determinism, speed, low cost, and auditability everywhere else.
The LLM is another such wave, like the early HTTP days — and this time the capability is real and valuable. But the lesson is the same as always. We do not hand the keys of a business-critical system to a component that cannot be predicted, cannot be fully explained, and cannot be afforded at scale. We use it for what it is genuinely good at, and we keep firm control of the rest.
That is why the Xbase++ V3 AgenticAI framework is a hybrid. Intelligence at the edge, determinism at the core — the LLM and the Finite State Machine, each doing the job it does best. It is not a compromise between old and new. It is the same engineering discipline that has guided this platform from the start.
This essay is the reasoning behind it. It explains, on an abstract level, why the AgenticAI framework is deliberately a hybrid — why it combines a Large Language Model (LLM) with a Finite State Machine (FSM), instead of letting an LLM drive everything. Once this is understood, the design of the framework will feel natural, even obvious.
The principle behind the platform
Most Xbase++ developers build Line-of-Business (LOB) applications. These applications calculate tax. They post to a ledger. They approve or reject a credit limit. They generate a legal invoice number. These are not tasks where "usually correct" is acceptable. They must be correct, repeatable, and explainable.
When a customer disputes an invoice, the application must show exactly how the number was produced. When the tax office asks a question, it must reproduce the same calculation from the same data and return the same result. When a bug appears, the same input must produce the same behavior again, so the developer can find and fix it.
A programming language such as Xbase++ is deterministic: the same input produces the same output, no matter how many times it runs. That is what makes the software built with it testable and traceable.
The inherited weakness of LLMs
An LLM is, at its heart, a probabilistic system. It predicts likely text. This gives it remarkable flexibility with language and with messy, unstructured data. But it carries a weakness that cannot be removed: it is not deterministic.
Give the same model the same prompt twice, and it may return two different answers. Even when we try to force stable output by setting the temperature to zero, small differences in the model, the hardware, or the way requests are processed can change the result.
The model can also be confidently wrong — it can invent a value that looks perfectly reasonable but is simply not true. This is called a hallucination, and it has its roots in a simple fact: the LLM produces an answer about something it has not learned and cannot derive.
For a chat assistant, this variability is acceptable, even pleasant. For a system that posts money to a ledger, books flights, or processes customer complaints, it is a serious risk. A system of record cannot rest on a component that may answer differently tomorrow than it did today. This single fact shaped the entire design of the AgenticAI framework.
The agent trap: latency and cost that grow without limit
There is a fashionable idea today called the "agent." The concept is that an LLM drives the whole workflow. It reads a request, decides which tools to call — for example through MCP, the Model Context Protocol — looks at the results, decides the next step, and repeats until the job is done. In a demonstration, it looks like magic.
But for LOB applications, letting an LLM drive the entire workflow creates two further practical problems, in addition to the non-deterministic gap — and both grow without limit.
Latency: A single call to a capable LLM does not take microseconds, as a compiled routine does. It takes seconds. An agent workflow is not one call — it is a loop of many calls. The model thinks, calls a tool, reads the result, thinks again, and calls another tool. Five or ten steps are common. What used to be an instant operation now takes twenty, thirty, or sixty seconds. Users who are used to pressing Enter and seeing the result immediately will not accept this for their daily work.
Cost: LLMs are billed by the token — every word in and every word out. An agent that carries a large context and takes many steps can consume tens of thousands of tokens for a single task. That may be a fraction of a cent or several cents. It sounds small. But an LOB application does not run one task. It runs hundreds or thousands of transactions per day. Multiply a "small" per-task cost by that volume, and the operating bill does not grow gently — it skyrockets. Worse, it becomes variable and hard to predict, which is exactly what a business hates in its running costs.
Compare this to the Xbase++ solution - your code - your customers already trust. A deterministic routine running on a server they own costs almost nothing per transaction, runs in milliseconds, and behaves the same way every time. That is a very hard advantage to give up — and there is no good reason to give it up.
There is a further problem beneath these two. An FSM gives a clean trace: this state, this event, this rule, this transition. An LLM's internal reasoning is opaque and cannot be reproduced. As the primary decision-maker in a regulated workflow, it is weak. It cannot be fully explained, and it cannot be fully reproduced.
So three problems stack on top of each other: non-determinism, high latency, and unpredictable cost. For LOB software, all three point in the same direction.
The design decision: intelligence at the edge, determinism at the core
This is why we did not design the AgenticAI framework as an "LLM that runs the application." We designed it as a hybrid, on one clear rule: put determinism at the core, and intelligence at the edges.
At the core sits a Finite State Machine. The business process is expressed as explicit states and transitions. An order, for example, moves through clear states — created → validated → approved → fulfilled → invoiced → paid — and each transition is governed by clear rules. This FSM is the backbone of the workflow. It is:
- Fast: — it runs in milliseconds.
- Cheap: — it uses compute the customer already owns.
- Testable: — a test can be written for every transition.
- Auditable: — every step leaves a clear, reproducible trace.
- Deterministic: — the same input always leads to the same path.
This is the system of record. This is where money moves and where decisions become official. In the AgenticAI framework, the LLM can be a component that performs a single task — such as extracting structured data from a business document, or judging the tone of an email — but it does not drive this core loop.
Instead, the LLM works at the boundaries, where the clean, structured system meets the messy, unstructured human world. This is exactly where the LLM is strong and the FSM is weak:
- A customer sends a free-text email with an order. The LLM reads the language and extracts structured fields — product, quantity, delivery date. Those fields then enter the deterministic pipeline.
- A user asks a question in plain language. The LLM translates it into a structured query, which the engine executes deterministically.
- A scanned document arrives. The LLM classifies its type and pulls out the key values, which are then validated by rules.
- A finished transaction needs a friendly summary for a human. The LLM turns structured data into readable text.
The rule at the heart of the framework: the LLM proposes, the state machine disposes
If there is one sentence to take from this essay, take this one: the LLM proposes, the state machine disposes.
The LLM may suggest a value, a classification, or a next step. But its output is treated as untrusted input, exactly like data typed by an unknown user. Before it can trigger a state transition, it must pass through deterministic validation: Is it in the right format? Is the value within the allowed limits? Does it satisfy the business rules? Only then may the FSM act on it. The LLM never directly causes an irreversible business action on its own.
This is what lets the framework offer both things at once: the intelligence of an LLM exactly where it is needed, and full determinism, speed, low cost, and auditability everywhere else.
Continuity, not revolution
We have watched many waves of technology arrive, each announced as the end of everything that came before. The platform survived them, and our customers' applications kept running and vertical solution vendors are growing because the design stayed pragmatic. We adopted what genuinely helped, and we never gave up the foundation that keeps the software evolving.The LLM is another such wave, like the early HTTP days — and this time the capability is real and valuable. But the lesson is the same as always. We do not hand the keys of a business-critical system to a component that cannot be predicted, cannot be fully explained, and cannot be afforded at scale. We use it for what it is genuinely good at, and we keep firm control of the rest.
That is why the Xbase++ V3 AgenticAI framework is a hybrid. Intelligence at the edge, determinism at the core — the LLM and the Finite State Machine, each doing the job it does best. It is not a compromise between old and new. It is the same engineering discipline that has guided this platform from the start.
