The most expensive way to automate a process you already understand is to give it to an agent.
Right now everyone is building agents. Some of that is justified. A lot of it is a deterministic process wearing a costume.
Most SAP processes are already fully specified
Look at what actually gets automated in an SAP context. Incoming invoices. Purchase orders. Delivery notes. Service entry sheets. Quality certificates. For every one of these, someone wrote down the process years ago, the business has been running it ever since, and the exceptions are documented in a spreadsheet that a key user maintains.
Every step is known. Every branch is known. Every exception is known.
Handing that to an agent means paying tokens for a decision that was never open. It also means accepting that the same input might take a different path tomorrow, which is a strange thing to accept for a process whose whole value is that it always does the same thing.
The cost is the smaller problem. The bigger one is the question you get six weeks after go live: why was this invoice posted to that cost center? With a flow you open the execution, look at the node, and you have an answer in two minutes. With an agent you have the tool call log and, if you built them, evaluations. Those tell you what happened and how often it goes right. What they do not give you is the guarantee that the same input takes the same path tomorrow.
The pattern that keeps working
I like building document based processes in n8n, because they explain themselves in a demo and because the shape is always the same.
1 to n sources. Email, a file share, a chat message, or the internal app someone vibe coded last month. It does not matter which. They all end up as a document plus some metadata.
Extraction. A local or cloud hosted model pulls the text and the structure out of the document. This is the one step where a model earns its keep, because unstructured input really is unpredictable. Which model you use is a data protection decision as much as a quality decision, and n8n lets you make that decision per workflow instead of per platform.
Enrichment. Pull master data and open items from the follow-on systems. Vendor, contract, purchase order, tolerances, cost center defaults. Now you know what the document should look like, not just what it says.
Processing. Validate, map, calculate, decide. Plain logic, visible in the canvas, testable with a handful of fixtures. Three way match, tolerance checks, duplicate detection. None of this needs a model.
Human in the loop where it matters. An approval in MS Teams or the SAP Workplace, with the extracted values and the source document side by side, so the person deciding can actually decide instead of guessing.
Posting. The data lands in SAP through the predefined OData services. No screen scraping, no batch input sessions, no surprises. The service validates, and if it rejects the document you get a real message instead of a hallucinated success.
What changes between invoices and purchase orders is the extraction prompt, the validation rules and the target service. The skeleton stays. We built processes exactly like this long before anyone said agentic, and they still work. They are cheap to run, they fail loudly instead of quietly, and a new colleague can read the canvas and understand the business process without asking anyone.
Where agents clearly win: the purchaser
None of this is an argument against agents. It is an argument against using them as a default. So here is the case where I would build one without hesitating.
Take purchasing. A large part of the daily work in that team is not a process, it is a queue of questions. Suppliers ask when an invoice will be paid. Requesters ask whether they can order something and against which contract. Somebody has to chase a missing order confirmation, explain a price difference, or work out why a payment is blocked.
Consider the most common one. A supplier writes: "Can you tell me the status of our invoices from July?"
Today somebody opens the supplier account, checks the documents, checks whether one of them is blocked, checks whether the goods receipt was posted, looks at the payment terms and the next payment run, and then writes a reply. Ten minutes, maybe twenty if the mail names three documents and one number is wrong. Multiply that by the volume a shared service center receives in a week.
An agent is a good fit here, and the reason is specific: the path is not knowable in advance. The mail arrives in free text. It might reference an invoice number, a delivery note, or nothing at all. It might turn out to be about a credit memo. It might actually be a question about a delivery date wearing an invoice question as a disguise. You cannot draw that decision tree up front, and every attempt to draw it produces a flow with forty branches that still misses the case that arrived this morning.
If you are the one signing this off, the interesting part is not the model. It is what the agent is allowed to do.
A fixed set of capabilities, not open access. The agent chooses which question to answer and what it needs to know. It does not choose how the data is read.
The agent acts inside the same authorizations as the person doing that job today. An agent is not a reason to work around your role concept.
Read-only first. Anything that writes or sends comes later, and behind an approval.
A record instead of a reconstruction. Every step is logged with what went in and what came out. When somebody asks six months later why a supplier received that answer, the log is the answer.
A named owner for everything the agent should not decide on its own. Escalation is part of the design, not what happens when the design fails.
Start with the supplier status question, because it is high volume, low risk and easy to measure. The effect worth measuring is not headcount. It is response time, and the end of "I will look into it and come back to you".
The rule of thumb
If you can draw the process on a whiteboard, build it as a flow. If your explanation starts with "it depends on the case", build an agent.
And the part that gets missed in most agent discussions: an agent is only as good as the capabilities you give it, and those come out of the automation you already have. Audited, versioned, boring.
The agent decides what to do. The automation underneath decides how it is done.
So build the boring flows first. They are not the thing you replace with agents later. They are what makes the agents worth having.
How all of this is wired depends on the systems, the release and the governance model in front of you, so that part is a workshop conversation rather than a blog post. Everything above I have put together from our own project work. It reflects how we build today, and that can change tomorrow.