Where low-code and agents both stop
Most of what gets called automation is moving data between systems, and low-code does that well. What sits on either side of the move is different work. The data arriving is not clean, and the answer coming out has to be checkable. Neither tool has anything for either one.
An agent gives you an answer. Where it came from cannot be reconstructed.
The answer reads as confident and may well be correct. What is missing is everything behind it: the document it came from, the rule that applied, which version of that rule was in force that week, and who was entitled to overrule it.
That absence has no cost on the day. It has a cost on the day someone asks — an auditor, a customer disputing an invoice, your own finance team reconciling a quarter. A year after a line was approved, "the model said so" is what the system can produce, because it is all the system ever kept.
No amount of model quality changes this, and it is not a prompting problem. A result is checkable because the system was built to record what it rested on. That is a decision taken before the first line of code, not a feature added afterwards.
We build to that requirement in all three lines of work. It has a name and a page.
Low-code assumes the input is already structured.
Orders arrive as an email. As page two of a PDF. As an export somebody wrote in 2019 and nobody has touched since. A quantity is a pack or a piece. A part number changed last quarter. "Same as last time" means an order from January that somebody has to go and find.
None of this is an edge case. It is the ordinary state of an operations inbox — and it is the exact reason automation in this category stops where it stops.
A drawn flow handles the path it was drawn for. Everything else goes to an error branch, and an error branch is a folder nobody opens.
Four principles our systems are built on
One · Rules are written while the system runs, not before it. Nobody hands you the rule set on day one. It accumulates as the system meets the cases nobody thought to describe: the customer whose units are packs, the part renamed last quarter, the contract term that means something different in one agreement. Every exception a person resolves is written down as a rule, and the rule goes back into matching — so the same case does not arrive a second time.
A drawn flow is finished the day it is drawn. A rule corpus is worth more in month six than in month one, and that difference is what decides whether the thing is still running in year two.
Two · Every result carries what it rests on. Not a log kept alongside the work, and not an explanation generated afterwards. The sources, the rule, the version of the rule and the person entitled to overrule it are part of the result itself, recorded as it is produced. It is the only form that survives being asked about a year later.
Three · The exception is the product, not the error branch. Every system in this category is judged by what it does with input it cannot handle. We route it to the one person who can answer it, with the question already formed and a clock on it. The answer becomes a rule, which is principle one.
Four · It goes on top of what you already run. Your ERP, the industry system, and the spreadsheet half of it actually runs on stay where they are. Write-back goes into the system that owns the record, in that system's own format. Replacing them is a different project carrying a different risk, and it is not this one.
None of the four is a feature. Each one shapes the build from the first day, which is why they are worth reading before you choose a tool rather than after.
The six steps, and what each one costs to build
Intake
Whatever the sender chose to send. No format is agreed with anyone, and none has to be. The work here is not parsing — it is deciding, per document, how much of what was read can be trusted, and passing that confidence forward instead of discarding it.
email "Can you do 250 by the 14th? Same as our last one."pdf · p2 Item 3 250 units delivery 14/03portal 4471-B;3;250;2026-03-14Structure
The document becomes lines: parts, quantities, terms, dates — matched against your catalogue and your master data, not against a generic dictionary. The cost sits in your data, not in ours: two spellings of the same customer, a part that exists twice, a unit that means packs in one contract and pieces in another.
CUSTOMER ITEM QUANTITY DELIVERYNordwerk GmbH line 3 of 9 250 units 14 Marchorder 4471-B · received 14:06
Decision
The system does what it can do reliably, and only that. Each result carries the source it stands on, so a person checks it in seconds instead of redoing it. Knowing where reliable stops is most of the engineering, and it is the part that cannot be bought.
"Same as our last one" their order in January
four previous orders, all the same specification · confirmed
Exception
What the system is not sure about goes to a named person with the question already formed and a clock on it. Routing is the hard half: the right person is rarely the one who owns the document, and a queue that routes to a team routes to nobody.
Their price is 4% above the agreed contract price.
ROUTED TO the account manager who agreed that contract price 14:06Write-back
Into the system that owns the record, in that system's format, unchanged. This is the step that decides the schedule — the integration is old, undocumented, or reachable only through somebody's export, and it is planned first rather than last.
order 4471-B · line 3 · 250 units · 14 March · confirmed 14:31
written at 14:31 >>> your ERPRecord
What was decided, on what basis, under which version of the rules, and who could have overruled it. Written as it happens, because a record assembled afterwards is a reconstruction and is worth what a reconstruction is worth.
14:06 RECEIVED IN email FROM purchasing
14:06 ASKED OF account manager ABOUT price above contract
14:31 ANSWERED BY account manager AS approved once
14:31 WRITTEN TO your ERP AS line 3 of 9
Where a low-code tool is the right answer
Principle one is also the test. If your rules are known, finite and stable — if they can be drawn once and left alone — then the thing that makes these systems worth their cost never comes into play, and a low-code tool will do the work for a fraction of what we charge.
That case is real and it is not rare: fixed formats from a fixed set of senders, a rule set that fits on a page, and a wrong answer that costs a redo rather than a claim.
Ten minutes on the call establishes which of the two you have. We would rather establish it then than after the invoice.
Four systems already run on these four principles
Grain trading, ship operations, an airport terminal, an industrial catalogue — four businesses that share no supplier, no regulator and no vocabulary. The six steps underneath them are the same, and so are the principles above.
Send us five of your orders
We run them and tell you what did not parse and why. That second half is the useful one: it tells you which of your formats are worth automating and which are not.