Artificial Intelligence is making possible automations that, only a few years ago, would have been extremely complex, expensive or simply impractical. A Large Language Model (LLM) can read a document, understand what it means, extract information, classify content, interpret a request written in natural language and, more and more often, decide which action to take.
So the temptation is understandable: if AI can do all of this, why not hand it the entire process?
At Sydea Lab we are experimenting with a different approach. The first question we ask is not “where can we add AI?”, but “how would we design this process if we were building it today?”. The difference seems subtle. In reality, it completely changes the architecture of the solution.
An example: from customer order to ERP
Take a process that looks simple: receiving a customer order and entering it into the ERP. The order might arrive as a PDF containing product codes, free-text descriptions, quantities, customer references, delivery addresses and special terms.
We could hand the whole process to an AI agent: ask it to read the document, identify the customer, check the customer master data, look up the products in the ERP, verify prices and availability and finally create the order. Technically, it can be done.
But is it really good architecture?
Probably not.
These are all deterministic operations:
- checking whether a customer code exists in the ERP
- checking whether an item is available
- retrieving a price list
- verifying a payment term
- creating an order through an API
Why would we use a Large Language Model to do something that a query, an API or a few lines of code can do faster, more predictably and more cheaply?
Where AI becomes genuinely interesting is when we need to understand something that isn't structured. For example: “ship the goods together with the previous order, within the first week of the month if possible.” Or when the customer uses a commercial description that doesn't exactly match the one in the product master data.
A simple rule is no longer enough here.
It takes interpretation. And that is exactly where we want to use AI.
Software, automation and AI are not competitors
One of the things we are looking into is precisely the separation of responsibilities. A modern process can combine at least four components.
Deterministic software
It handles data, APIs, authentication, databases, files, checks and fixed rules. When we know exactly what result we want, traditional software is often still the best tool for the job.
Automation
It orchestrates the process: it moves information, triggers workflows, calls services, tracks states and runs operational sequences.
Artificial Intelligence
It steps in when the system needs to understand, interpret, classify, reason or work with unstructured information.
People
They keep control and accountability wherever a decision requires experience, authorization, risk assessment or handling an exception.
So the value doesn't lie in replacing everything with an AI agent.
It lies in deciding how to combine these components.
The questions we ask before adding AI
When we analyze a process in our experiments, the first thing we try to do is identify where AI is actually needed. For each activity, we ask ourselves a few questions.
Do we really need AI?
- Is the outcome deterministic? If the same input should always produce the same output, we probably don't need an LLM.
- Is there already a rule that solves the problem? If we can express it clearly in code, a query, an API or a workflow, that is often the better choice.
- Do we actually need to understand something? Free text, unstructured documents, images, intent, context and ambiguity are areas where AI can have a huge advantage.
What does it cost, and what are the risks?
- Can we narrow the problem down before calling the AI? If our ERP holds 100,000 items, there is no need to give the model the entire item master to work out which item a description refers to. An application can deterministically narrow the field down to ten possible products: the AI reasons over ten options, not a hundred thousand, which makes it faster, easier to control and cheaper.
- How much context do we need to give the model? Every piece of information we send has a computational cost. Passing entire documents, conversations or large amounts of context with every request may work technically, but that doesn't make it a good solution.
- Do we really need the most powerful model? Not every task calls for the same level of intelligence: extracting five fields from a document, classifying a request and reasoning through a complex commercial exception are three different problems, which may call for three different approaches.
- How many times will this operation run? An AI call that costs next to nothing may seem irrelevant, but what happens when it runs 100, 10,000, a million times? When we design business processes, we have to think about scale, not the single interaction.
- What happens when the AI gets it wrong? Perhaps the most important question of all. Can we verify the result automatically? Can we undo the action? Does a person need to approve it? What does a mistake cost? How much autonomy a system is given should also depend on the answers to these questions.
A business process doesn't run once: it runs continuously.
AI has a cost, even when we don't see it
There is one phenomenon we find particularly interesting. As users, we have grown used to tools like ChatGPT or Claude on a monthly subscription: we pay a fixed fee and use the service. This inevitably shapes how we perceive the cost of AI. We ask a question, get an answer, have a document analyzed, ask for a second pass: we never see a meter ticking up with every token.
The cost is there, but it is hidden inside the product experience.
When we move from individual use to building a business process, the perspective changes completely.
Every call to a model uses computing capacity. Every token processed has a cost. Providing large amounts of context has a cost. Asking an agent to reason, use tools, check its own output and perhaps try again has a cost.
And above all, it is something that repeats over time, call after call.
From cost per token to cost per process
That is why at Sydea Lab we are trying to shift the focus from a purely technological metric to a business one: not just “how much does a model call cost?”, but “how much does it cost to run this process?”.
If an order is processed with fifteen AI calls, maybe we can bring that down to three. If we send fifty pages of context every time, maybe we can build an application that first selects the five pieces of information that really matter. If we use an extremely powerful model to sort a document into one of four known categories, maybe something much simpler would do.
Optimizing AI thus becomes part of the application architecture.
The hidden costs beyond tokens
There is a second level to consider. The real cost of an AI solution is not simply the number of tokens multiplied by the model's price: we also have to account for latency, infrastructure, observability, error handling, security, quality evaluation, model evolution and human oversight.
Then there is a cost that is even harder to measure: unpredictability. A traditional program that checks whether “customer_id = 12345” exists in the database is relatively simple to test; a probabilistic system calls for a different approach.
That is why using an LLM for something we could have solved with a query is not just a waste of money: it can also be a waste of complexity.
We don't want to build agents, we want to build better processes
This is perhaps the main point of the experimentation we are carrying out at Sydea Lab. The market talks more and more about AI agents: agents are an extremely interesting technology, but they remain one of the tools available. In some processes they will be central, in others a small component of a larger architecture, and in others still they probably won't be needed at all.
So we try not to start from the question “which agent can we build?”, but from a blank page: we look at the work being done today and ask ourselves “if we had to design this process from scratch, with the technology we have today, how should it work?”. Only then do we decide what should be software, what should be automation, what should be AI and what should remain human.
Toward a Digital Workforce
This experimentation is gradually leading us toward a broader concept: that of a Digital Workforce.
We don't picture a Digital Worker as simply a chatbot with a name and an avatar, but as a system able to take on a clearly defined operational responsibility within the organization. Behind that digital worker there may be APIs, databases, traditional applications, workflows, language models, specialized models and different levels of human oversight.
Artificial intelligence is a fundamental component, but it doesn't have to do everything. What the end user cares about, above all, is one thing: that the work gets done well.
And this is probably the most interesting challenge ahead of us: not figuring out how much AI we can put into companies, but figuring out how much intelligence is really needed to build a better way of working.
Sydea Lab is the space, a bit like the computer labs at university, where we test the method described in this article before applying it to our clients' real processes. It didn't come out of a specific project, but from a need that cuts across all of them: before proposing AI, automation or traditional software, understanding which of the three is really needed, and why.
It is ongoing work, process after process, together with the companies we work with.
