Dr. Fabian Struck’s Post

Automation workflows are really decided by how they handle exceptions. That's where the rubber meets the road. Have you ever noticed that most automation demos are perfect by design? The business case is ideal. For example, with invoicing, the invoice always arrives in the right format. The PO reference always matches. The payment always lands in the correct account. Everything runs cleanly from start to finish. That is useful to see for a demo, but it's not the real-world test. With invoice matching and reconciliation, the heaviest workload is usually sitting in the exception queue: a missing reference, a partial payment, a duplicate invoice, a supplier name that does not quite match the record, or a transaction that needs someone to make a judgment call. That queue is not an inconvenience at the edge of the process. It is evidence of how the process actually behaves. Before diving into an automation business case, I like to ask three questions: 1. What percentage of transactions become exceptions, and what do they look like? In the real workflow, across a normal month. 2. Who owns those exceptions if automation flags them, and what are the steps to resolve? If the answer is unclear, that needs to be figured out ASAP. Otherwise, the manual work doesn't disappear (or diminish) with automation - it simply moves somewhere else. 3. Can you show why an exception was handled the way it was, and who made that decision? A completed match is not enough. You need a clear record of what was flagged, who reviewed it, and why a decision was made, so the model can be trained to handle it if it ever happens again. Good automation should make the straight-forward work quieter and the exceptions more visible. That is where human oversight belongs: not rechecking every routine transaction, but applying judgment where the rules stop being enough. A system that handles the clean path is helpful. A system that exposes, routes, and records the messy path is what makes the operating model more reliable. When assessing invoice matching or reconciliation automation, don't just ask what it can it process automatically. Ask what happens when it cannot. That is usually where the real business case is decided.

Somewhere along the way, everything became an “agent.” 📦 Check whether inventory can fulfill an order? Inventory agent. 🚚 Send a carrier a pickup or delivery update? Logistics agent. 📅 Confirm a dock or delivery appointment? Scheduling agent. 🔄 Move shipment data from a TMS to an ERP? Integration agent. I’m seeing this everywhere across supply chain: basic automations being rebranded overnight. But the more we stretch the word, the less useful it becomes. If everything is an agent, nothing is. An agent is not a marketing label. It is an architecture. A system earns that label when it can do four things: 🎯 Own a goal: Work toward an outcome, not just respond to a prompt or complete one isolated task. 🧭 Decide the steps: Plan, sequence, and revise its approach instead of following only a hardcoded path. 🛠️ Take action through tools: Call APIs, update systems, send messages, move data, or trigger real-world operations. 🔄 Check results and adapt: Observe what happened, retain context, recover from failure, and decide what to do next. That last point matters most. A workflow follows a predefined path. An agent acts, checks, and adjusts. The distinction changes what you should expect a system to handle autonomously, where operational risk enters, and where people still need to stay in the loop. LLMs did not invent agents. But they made goal-directed systems more flexible, easier to build, and more practical for messy, language-heavy work. Still: Not every LLM wrapper is an agent. Not every automation is an agent. Not every chatbot with an API key is an agent. So the next time you see “agent” on a slide or product page, ask: Is it actually planning, acting, and adapting toward a goal? Or is it just a workflow wearing an agent costume? Where have you seen “agent” used when “automation” would have been more accurate?

I couldn't be more excited for this update!! Today, LinkSquares is launching Workflow Builder Agent and Workflow Blueprints. This changes how Legal builds and evolves contract automation. Legal teams already know how their business should operate. They know the policies, approvals, and processes that need to happen for work to move forward. Yet building complex workflows has traditionally meant translating that knowledge into the software's language: steps, rules, dependencies, routing, and configuration. AI gives us an opportunity to change that relationship. With Workflow Builder Agent, Legal can describe what needs to happen in plain language and LinkSquares helps build the workflow. Workflow Blueprints give teams a ready-to-customize foundation when they don’t want to start from scratch. Throughout the process, Legal can review, refine, and decide what ultimately goes live. That balance is important to me. AI can take on more of the building and execution, giving people a better way to put their expertise into action while keeping them firmly in control. I’m excited to see what our customers build with it. Learn more about today’s launch: https://lnkd.in/ghWCm3ew

I am working with @LinkSquares and they are launching Workflow Builder AI Agent and Workflow Blueprints. This changes how Legal builds and evolves contract automation. Legal teams already know how their business should operate. They know the policies, approvals, and processes that need to happen for work to move forward. Yet building complex workflows has traditionally meant translating that knowledge into the software's language: steps, rules, dependencies, routing, and configuration. AI gives us an opportunity to change that relationship. With Workflow Builder Agent, Legal can describe what needs to happen in plain language and LinkSquares helps build the workflow.  Workflow Blueprints give teams a ready-to-customize foundation when they don’t want to start from scratch. Throughout the process, Legal can review, refine, and decide what ultimately goes live. That balance is important to me. AI can take on more of the building and execution, giving people a better way to put their expertise into action while keeping them firmly in control. I’m excited to see what our customers build with it. Learn more about today’s launch: https://lnkd.in/gMBS5QuH

The first 70% of an automation is usually the part that looks impressive in a demo. Purchase request: €800. Manager approves. Purchase order is generated. Done. It takes 20 seconds and everyone in the room thinks: “Why weren’t we doing this years ago?” Then the automation meets an actual company. The manager is on holiday. The project is already over budget. The supplier changed the price after the request was approved. The amount is €5,400, so now two people need to approve it. Someone approves the request three days later, but the project has already been closed. Another employee accidentally submits the same request twice. The PO is generated correctly, but the email to the supplier fails. None of these are unusual situations. They’re just not the situations we normally put in the demo. And this is where automation projects become interesting. The workflow is no longer: request → approve → PO It becomes: request → rules → approvals → exceptions → recovery → audit trail The happy path is still important. But people don’t really learn whether they trust a system when everything goes right. They learn it the first time something goes wrong. Does the automation stop safely? Does somebody know why? Can the right person override it? Can it recover without creating duplicate orders? Can we see who approved what and when? Can we continue from the failed step, or does somebody have to start again? This is one reason I’m cautious when someone says: “We can automate this process very quickly.” Maybe we can automate the happy path quickly. The business process is usually hiding in the exceptions. And whether we’re talking about ERP, AI agents or traditional workflow automation, I think the same rule applies: A useful automation doesn’t only know what to do next. It also knows what to do when “next” is no longer obvious.

An automation becomes trustworthy the day it knows how to stop and ask. Most builds fail on the odd/edge cases, and they fail quietly, because nobody gave the workflow anywhere to put a job it did not recognize. Five parts to the exception path. One: Write the conditions that make a run standard, as checks, the system can evaluate. The contract has one delivery address. The amount is under 5,000. The client exists in the billing system. Anything failing a check is an exception by definition, so nobody has to guess whether something qualifies. Two: Set up the automation to alert you rather than guess the answer. I realize that stopping halfway is annoying, but it is also recoverable. One that finishes on a bad assumption can send a customer the wrong number, and you will find out weeks later from the customer. Three: Give exceptions a named person and a deadline. One name, one stated turnaround like 1 business day. An exception queue that belongs to everybody is where automated work goes to age. Four: Make it loud. The exception has to interrupt that person where they already work, with the record attached and the reason on the front. Anything that requires someone to remember to go and look will sit for a week. Five: Log every exception in one line. What tripped it, and what the human decided. Almost everyone skips this, and it is the part that pays. A 21-person equipment rental company automated the step from signed contract to invoice, about 190 rentals a month. In the first month, the automation guessed on unusual contracts, and 4 incorrect invoices were sent to customers. Two were multi-site deliveries billed to a single address. They rebuilt it with the 5 parts. Exceptions ran at 8%, so 15 a month, handled the same day. Over 3 months of this automation running, it held 41 exceptions, and 23 were the same reason: one contract covering delivery to more than one site. That belonged in the standard path. Three days of work later, exceptions dropped to about 3%. Read the log monthly. Any reason appearing 5 or more times is an unwritten rule waiting to be built in. The objection: "If we still handle exceptions by hand, what did the automation buy us?" The 92% are handled without a person. The alternative for the other 8% is a machine making up an answer, which is what produced the 4 wrong invoices. If you already have an automation running, go and find where its odd cases currently go. In most builds I look at, the system guesses and nobody checks.

Today, LinkSquares is launching Workflow Builder Agent and Workflow Blueprints. This changes how Legal builds and evolves contract automation. Legal teams already know how their business should operate. They know the policies, approvals, and processes that need to happen for work to move forward. Yet building complex workflows has traditionally meant translating that knowledge into the software's language: steps, rules, dependencies, routing, and configuration. AI gives us an opportunity to change that relationship. With Workflow Builder Agent, Legal can describe what needs to happen in plain language and LinkSquares helps build the workflow.  Workflow Blueprints give teams a ready-to-customize foundation when they don’t want to start from scratch. Throughout the process, Legal can review, refine, and decide what ultimately goes live. That balance is important to me. AI can take on more of the building and execution, giving people a better way to put their expertise into action while keeping them firmly in control. I’m excited to see what our customers build with it. Learn more about today’s launch: https://lnkd.in/guM98PHx

The scariest automation bug is not the one that crashes, it's the one that doesn't. A crash is easy to spot because the system literally stops everything and you just go and fix it. The dangerous bug is the one you can't see because it reports "success" while the workflow happily does the wrong thing. An invoice system I built once said "success" and processed nothing. Another version took in three invoices, filed one, and lost the other two without a single warning. If you don't catch the bug, the owner's monthly report with wrong numbers is the least of your worries. Lost invoices mean bills that never get paid, so vendors start chasing you, late fees stack up, and the suppliers you count on stop trusting you. Duplicates go the other way and you pay for the same thing twice. And at tax time your books are fiction, which is the expensive kind of wrong. The worst part is the timing: by the time anyone notices, months of records are already corrupted, and you can't tell which numbers are real. So when I test a system like this, I don't trust the "success" label. I trace every input and output myself: three invoices went in, so three rows should come out, and every number has to match the actual PDF. If one goes missing, I want to catch it on the test bench, not once it's live. Then I build the guards so it can't fail quietly on its own. The system counts what came in against what got filed, so an invoice can't just disappear without flagging it. And anything the AI isn't confident about, or that trips a validation rule, never gets filed automatically. It stops and waits for a human to approve it. "It ran without errors" was never the goal. "It did the right thing, and it told someone if it couldn't" is. If you've automated something in your business, the question worth asking isn't whether it works when you watch it. It's what happens the day it quietly doesn't, and whether anyone would find out.

You're automating the wrong process. Here's how you know. If your process is 40% exception handling, you have a process problem, not a technology problem. I watched an organization invest €2M in invoice automation. They expected 70% cost reduction. Got 15%. Why? 60% of their invoices were exceptions. Non-standard formats. Missing line items. Custom payment terms. The automation handled the 40% of standard invoices. The 60% of exceptions still required humans. Money spent. Nothing gained. The problem wasn't the automation. It was they automated a broken process. They should have asked first: Why do 60% of invoices come in as exceptions? Why do vendors send things however they want? Why isn't there standardization? If they'd fixed that first worked with vendors, enforced standard formats then 95% of invoices would be standard. Then automation would actually work. Most teams do it backwards. Automate first, fix process later. The fix never happens. Start with process redesign. Eliminate exceptions. Standardize requirements. Then automate. The tool you pick matters 20%. The process you design matters 80%. What process are you planning to automate?

Most SMEs feel the pain of supplier invoices long before they feel ready for "AI". So they sit in the worst middle ground. Too many invoices for easy manual checks. Not enough volume or error cost to justify a chunky automation project. Vendors will happily tell you 3-way match automation is always a good idea. It is not. For a 20–100 person UK business, the only sensible question is: "Are we wasting enough time and money on PO-GRN-invoice checks that automation clearly pays for itself in year one?" You do not need a consultant or a complex ROI model to answer that. You need a single, blunt break-even test you can run in 10 minutes, using numbers you already have. The method is simple: Work out what you spend each month on manual matching time and invoice errors. Apply conservative assumptions about what automation could realistically save. Compare that to a realistic monthly automation cost. If the savings comfortably beat the cost, plan a pilot. If they do not, tighten manual controls and revisit later. The 10-minute version is in the deck. Slides two to seven walk through the exact inputs, the formula, and how to read the result.