Dynamic workflows and graph engineering: the new paradigm for business AI (an SMB guide)

For ten years business automation had one shape: the sequence. A happens, so do B, then C, and if a condition is met jump to D. It works beautifully as long as reality behaves as expected. The problem is that in real processes reality almost never behaves as expected: the customer attaches a PDF instead of filling the form, the requested item isn't on the price list, the supplier answers with a counter-proposal, the document arrives incomplete. Every exception becomes one more branch in the diagram, and after a year the flow is a cobweb nobody dares touch.

The dynamic workflow — or, as practitioners call it, graph engineering — is the answer to that problem. Instead of drawing every possible path up front, you describe the process as a graph: a set of nodes (the things the system can do) connected by possible transitions. At each step an AI model decides which node comes next, based on the current state of the case. The path isn't written into the code: it emerges from the data.

An example makes the difference clear

In the old model, a flow for sales enquiries says: read the email, extract the items, look up prices, generate the PDF, send. If a field is missing, the flow stops or errors out. In the graph model, the system has a set of capabilities available — read an attachment, query the ERP, ask the customer for clarification, involve a salesperson, generate the document — and picks which one to use each time. If the quantity is missing, it asks. If the item isn't on the list, it looks for an equivalent and flags the doubt. If the value crosses a threshold, it hands over to a person. The same graph handles the simple case in thirty seconds and the complicated one in three steps, without anyone having had to draw that specific path in advance.

Technically, a dynamic workflow has four elements

First, the state: a structured object holding everything known about the case at a given moment, enriched at every step. Second, the nodes — the available actions, each with a clear contract about what it takes in and what it returns. Third, the transitions, defining which nodes may follow which — this is where discipline lives, because a graph without constraints is a system that can do anything, including the wrong things. Fourth, the exit criteria: when the case counts as closed, and what happens if the graph runs too long without concluding.

The term graph engineering refers precisely to the work on that third element: designing the constraints. It's the part that separates a demo from a system you can put into production. A good business graph has nodes with differentiated permissions (read the ERP yes, write only after approval), human checkpoints at irreversible steps, a hard cap on iterations, and a full log of every decision taken — because when something goes wrong you need to reconstruct why the system chose that route.

For an SMB the practical advantage shows up on three fronts

Coverage: a rigid flow handles the expected path and pushes exceptions onto people; a well-designed graph can compose different paths from the same capabilities. Maintenance: adding a new capability means adding a node, not redrawing the whole diagram. Time to value: you start with the most frequent case and add capabilities as you go, instead of mapping every exception before seeing the first result.

Where I see it work best, concretely

In complex sales enquiries, where every customer asks in a different format. In accounts payable, where supplier invoices arrive in different layouts and the anomalies are not always the same. In after-sales, where the same report may need an informational reply, a technical intervention or a warranty claim. And in customer or supplier onboarding, where missing documents are frequent and the system has to ask, remember and pick the thread back up days later.

Where it isn't needed, plainly

If the process is genuinely linear — three steps, no exceptions, always clean data — a classic workflow costs less, is faster and more predictable. If volume is low, a few dozen cases a month, the return doesn't justify the design work. And if the business rules were never written down, the graph doesn't invent them: it inherits the confusion. In that case the first job isn't technical but organisational, and it comes first.

On costs, better to be explicit

The infrastructure is the same as traditional automation: an orchestrator such as n8n or a graph framework, a server at 10-40 euros a month, and AI model usage which at SMB volumes stays in the tens of euros a month. The real cost is the design: a graph with four or five nodes on a single process, built, tested against historical cases and put into production, typically lands between 4,000 and 9,000 euros; a system covering a whole process with ERP integration, controls and human supervision goes to 8,000-18,000 euros. In exchange, the line item that usually drops to zero is rework: it's maintenance, not construction, where rigid flows get expensive.

The right way to start isn't buying a technology: it's taking the process that generates the most exceptions today and counting them for two weeks. How many requests arrive off-format, how often a field is missing, how often a second round is needed. If that number exceeds 20-25% of cases, a dynamic workflow is almost certainly the right call and pays for itself within the year. If it's under 10%, keep the linear flow and invest elsewhere. It's a calculation you can do in an afternoon, and it's worth more than any demo.

If you want to know which of the two your company falls into, in a fifteen-minute call we look at the process, count the exceptions and I tell you the realistic price range — and if the return isn't there, I say so straight away.