The processes you could never automate

Classic automation, rules engines and screen robots, works well as long as the input never changes. Its weakness is familiar to anyone who has maintained it. The rule that read supplier A’s invoice does not understand supplier B’s, and the robot that filled a form gets lost when the program changes version. Every new variation is a new rule to write, and the list never ends.

AI changes the division of labor. The model interprets the input even when it arrives in another format, another wording or another order, so variation stops breaking the flow. There is a quick test we run on the first call, asking for three real examples of the input. If the three look alike, your problem is rules. If each one arrives in its own way, that is where the model is needed. In exchange it demands what this whole page describes, validation and measurement, because interpreting is not infallible.

Honesty draws the border in the other direction too. If your process has clear rules over data that always arrives the same way, classic automation solves it cheaper and faster, with no model to supervise. We will say so in the first conversation, because putting AI where none is needed means paying for supervision in exchange for nothing. And when you already run classic automation that works, we do not throw it away. The two coexist well, rules moving the stable parts and the model reading the variable ones, each piece in the role that suits it.

A system can produce summaries, drafts and records by the dozen without the business noticing a thing. Producing things is not moving a gain. That is why the unit of work here is not the isolated task but the whole process, from input to result, with its metric up front: the hours that stop being paid for typing, the errors that stop needing correction, the waiting that stops existing.

An example makes it visible. A system that drafts a summary of every meeting produces output daily, and if nobody decides anything differently because of it, the gain is zero and the cost is not. A flow that leaves every invoice registered without anyone touching it turns its result into hours you can count. The difference is not in the technology. It is in whether the result changes something the business measures.

That yardstick changes design decisions. Sometimes the most profitable step is not accelerated but removed, because reorganizing the process makes the thing we were about to automate unnecessary. And a flow that resolves eighty percent of the volume with twenty percent of the effort beats the ambition of covering everything, which is what turns projects into never-ending builds. How we measure that gain, and why we refuse to call it productivity, is on the blog.

Our flows are a chain of steps that always runs the same way, with model stops where something has to be interpreted. Code moves the data, calls each system and decides the order. The model comes in only at the stops that require interpretation: reading a document, understanding a request, classifying a case. And it returns a result with a fixed structure that code can check. This is not an engineering whim. Every model call in production costs money, takes time and can vary, so the fewer and more bounded the calls, the cheaper the flow is to run and the more stable it gets.

You do not have to take our word for it. Anthropic, one of the major model makers, advises starting with workflows that code orchestrates and keeping agent autonomy for the problems that genuinely call for it. We arrived at the same rule the expensive way, by maintaining systems in production. In practice it means what one of our flows spends on model calls looks like a tool used with intent, not like a meter spinning on its own.

To keep all of this concrete, here is how the system walks an invoice from the moment it arrives to the moment it is filed.

AI business process automation fails when the model is left unsupervised. That is why the validation stop is neither optional nor saved for the end: every model result is checked before touching your systems, with the rules from the validation step you just saw, plus whatever each process adds. What passes validation flows on its own. What does not is neither discarded nor guessed, it goes to a person with the case already prepared.

Validating at the end, once the data is already registered, turns every error into an accounting correction. Validating in the middle turns it into an escalated case, which is cheaper and leaves less scar tissue. That split concentrates human review where judgment is needed and removes it from where only patience was. The goal is not a system that never asks. It is one that asks rarely and always with cause. And one that has a measured record of how much it resolves on its own, so the word “automated” comes with a number behind it.

At Stanton, a property management firm, every tenant’s power, water and gas invoice was keyed in by hand. Today the team forwards them over Telegram, an AI read extracts the data and the result lands as normalized rows in the same spreadsheet they already worked with. Two agents in production, no new tools for the team to learn, and a client that has already commissioned the next processes, the success signal we care about most.

At Barceloneta, a real-estate agency, every day dozens of rental inquiries come in over WhatsApp. Each inquiry used to eat five to ten minutes of checking by hand. Now the flow pulls the reason, the budget and the paperwork out of each conversation, and the team gets an email that already says whether the applicant fits, and why. More than three hours a day returned to the work that actually needs people.

The two cases are alike in three ways: they came in through a channel the team already used, they forced nobody to learn a new tool and their gain could be measured before and after. That is what we look for in every new process.

A flow that carries a model can degrade without throwing a single error, because the model changes or the documents do. So every modification runs against a suite of real cases before it ships, and every execution leaves a record of what was read, what was decided and what was registered. When something does not add up weeks later, we replay the exact execution instead of arguing from memory. And when a real error does slip through, the circuit is always the same: replay the execution, fix it and add the case to the test suite so it cannot slip through quietly again. A flow of ours ages by learning from its own scares.

And if one day a field is missing or a source is down, the system answers with what it has and says what was left out, rather than returning an incomplete figure that looks complete. That machine honesty is the difference between a number you can take into a meeting and one that embarrasses you there.

The monthly operation reads in three numbers: how much the flow resolved on its own, how much it escalated and with which reasons, and what each execution cost. Those three decide where to tune, which new rule to add and whether the next extension pays. Without them, “works fine” is an opinion. Every flow also inherits the house alarms, so if an external service goes down or a quota runs out, we know before your team feels it.

The automation connects to what you already run: ERP, CRM, databases, mail, messaging and, yes, the spreadsheet that quietly governs half a department. The entry point can be the channel your team already carries in their pocket, a Telegram or WhatsApp chat or a mailbox, because the best new tool is the one nobody has to learn.

And the repository is yours from day one, with its documentation and its operations manuals. If some day you want to run it with your own team or another provider, you take the whole system with you, not a subscription.

The first process pays for the setup: the connection to your systems, the record keeping, the test suite, the operation. The next ones reuse it, so every extension costs less than the one before and gets decided with the numbers of the flow that is already running. That is how Stanton grew, one flow first and the next ones on the same setup, each approved by what the previous one proved.

You do not need a transformation program to start, you need to pick one process well. The right one usually meets three conditions: it hurts measurably, it repeats with volume and someone suffers it who wants it gone. With that process in front of us, we map it step by step with the people who run it daily, what arrives, who touches it, which systems it crosses and where it jams. Then we measure what it costs today. That measured starting point is what later lets you say how much improved, with numbers instead of impressions.

The start is a pilot on a slice of the volume, with its metric agreed. Sometimes we even validate in mixed mode, a person supported by the half-built tool, because it confirms the gain before building the rest. Mapping also changes decisions before a line of code is written. At the rental agency it showed that the time was not going into answering messages but into checking each applicant, so the flow was designed around that check and not around the inbox. Without that map we would have automated the wrong part of the process.

If the pilot delivers, it grows in phases. If it does not, little was lost and the error taught us where it lived.

Some steps keep human confirmation on purpose: the ones that move real money, the irreversible ones and the ones that decide about people. The flow prepares the case, a person presses the button. That is not a technical limitation but a design choice, because an error that is cheap to correct can be automated and one that is expensive to correct must not be.

We also skip processes without volume, because a flow that runs three times a month never pays for its own upkeep, and processes that deserve a redesign more than an acceleration. If your case sits in one of those groups, we say so before anything starts and you save yourself the whole project.

The ranges are the same we publish for any agent of ours, and what moves them here is concrete: how many systems need connecting, how much validation the process demands and how much volume runs through it. The healthy rule is that the measured gain of the process sets the ceiling of the budget, not the other way round. The full breakdown is in the cost guide.