There is a version of the AI conversation, currently very loud, in which large language models are the new operating system. They plan, they reason, they call tools, they act. You give one an objective and let it work. I understand the appeal. I do not build that way and I would advise anyone running a serious operational platform to think very carefully before they do.
At HSS ProService Marketplace we run live agentic workflows in production. AI is not a pilot or a proof of concept for us; it sits at the boundary between our platform and a world of customers and suppliers that still, quite legitimately, runs on email and phone calls. But the design principle we have committed to is almost the inverse of the prevailing fashion. We do not let the AI run free. We constrain it, deliberately and narrowly, to what it is genuinely good at and we keep the decisions, the actions and the accountability inside a system we can reason about, test and audit.
What LLMs are actually good at
Strip away the marketing and modern language models do one thing extraordinarily well: they translate between unstructured and structured representations of the same information. Give one a customer’s order amendment email, written in whatever house style, dialect or level of grammatical care that customer happens to favour, and ask it to return a JSON payload with a contract reference, the amended item and a revised end date. It will do so reliably, quickly, and at a volume no human team could sustain.
That is a genuinely useful capability. It is also, in my experience, the only capability I would currently trust an LLM to perform unsupervised in an operational context.
The things LLMs are less reliable at, multi-step reasoning under uncertainty, arithmetic with financial consequences, following procedural rules consistently across thousands of similar-but-not-identical cases, happen to be precisely what our platform has to do correctly, every day, for every contract. So, we do not ask the model to do them.
The architecture: intelligence at the edges, determinism at the core
The platform is API-first and headless. At its core sits a set of deterministic services written in Scala, using the Cats library for pure functional programming. These services encode the business rules that govern a hire contract: how rates change when a hire is extended, what compliance documentation must accompany an asset, how revenue and supplier costs are reconciled day by day. Every rule is code. Every code path is testable. Every state transition is auditable.
Around that core, we operate a thin agentic layer whose job is exclusively translation. Supplier proof-of-delivery emails arrive. An LLM classifies them, extracts the relevant fields, and produces a structured API call – the same endpoint a supplier would hit using the portal we provide for them. The rules engine does not know, and does not need to know, that the input originated in prose. The LLM never decides whether to accept a delivery, whether to charge a customer, whether to trigger an exception; it proposes a structured interpretation of an unstructured input, and the platform decides what to do with it.
The quiet return of workflows
I want to be precise about what “agentic” means in our context, because the word is doing a lot of work in the industry right now. Our agentic workflows are designed pipelines with defined inputs, outputs, branching logic and failure modes. The LLM is one component within them, invoked for the specific tasks it is suited to – not orchestrating the pipeline, not choosing which tools to call, not deciding what “done” looks like. Those are determined by rules we have written, reviewed and can change.
Workflow engines are not a new technology. They have been around for decades, and fell out of fashion for a while, associated with heavyweight BPM suites and slow-moving enterprise IT. The rise of agentic AI has quietly brought them back. One of my developers put it to me recently that they are the unsung ingredient in any operational AI system that actually works, and I think that is exactly right. A workflow expresses a business process as an explicit, inspectable graph of steps, decisions and handoffs – exactly the substrate an LLM needs to be useful without being dangerous. The model provides intelligence at specific, well-defined points; the workflow provides the structure, state, escalation paths and audit trail. An LLM without a workflow is a very articulate improviser. A workflow without an LLM cannot handle the messy inputs the real world produces.
Our edge, insofar as we have one, is the combination: a strong API-first platform underneath, deterministic workflows expressing how the business actually operates, and LLMs positioned precisely where their capabilities align with the task. Any one of those three, on its own, is a partial solution. Together, they are what makes the platform work.
Humans in the loop, where oversight actually matters
The second principle is that we do not treat human oversight as a nice-to-have or a fallback. It is designed in.
Any input the AI is not confident about is routed to a person. Any case that touches a customer relationship, a complaint, an ambiguous request, an exception that could be read multiple ways, is handled by a human, with the AI providing structured context rather than executing on their behalf. As we extend the same pipeline outward to communications the platform sends to customers, the same discipline will apply: proactive notifications and confirmations that are routine and low-stakes can be generated and dispatched automatically; anything with commercial or reputational consequence gets human approval before it leaves.
The point is not that humans are more accurate than the model on every task; in several narrow domains they are demonstrably not. The point is that the boundary between automation and oversight has to be drawn on the basis of consequence, not confidence. High-consequence decisions get a person, even when the model is very likely to be right, because the cost of the rare wrong answer justifies it.
Why this survives an audit
We operate under ISO 27001 and Cyber Essentials, and we work with customers in regulated environments who ask reasonable questions about how AI participates in decisions that affect them. Every decision the platform takes is made by code we wrote, running against data we can trace. The LLM’s role is bounded, logged, and reproducible; a given input produces a structured output which produces a specific downstream action according to specific rules. There is no opaque middle layer where the model “figured it out.” If something goes wrong, we can point to the rule that fired, or the extraction that was inaccurate, and fix it at the appropriate layer.
This is also what makes the system extendable. Because the surface area where AI acts is narrow and well-defined, we can iterate on it aggressively – new models, new prompts, new classifiers – without destabilising the parts customers and suppliers rely on.
A blueprint, not a manifesto
I do not offer this as a general theory of how AI should be built. I offer it as what has worked for us, in a sector that is operationally complex, digitally uneven, and unforgiving of financial errors. The pattern generalises, I think, to any operational domain where the cost of a wrong action is meaningfully higher than the cost of a slower one. In all of them, the temptation to hand an AI the keys will grow as the models grow more capable. My argument is that capability is not the constraint. The constraint is accountability and the architectures that best deliver accountability are the ones that keep intelligence at the edges and deterministic logic at the core.
The AI does what it is good at. The platform does what it is designed to do. And the people responsible for the business remain, unambiguously, the people making the decisions.
Daniele Turi
Daniele Turi is Chief Technology Officer at HSS ProService Marketplace, the digital platform connecting construction managers with a network of suppliers across the UK.
