n8n for FDEs: build an LLM workflow in an afternoon, but know when to move to code

A customer wants every support email classified automatically, with urgent ones sent straight to the right person. You have two days. If you write a service from scratch, you will probably still be building the scaffolding when the two days are up. With n8n, you can be sitting next to the customer on the first afternoon, showing them a working flow.

n8n’s homepage sums itself up in one line: build with a visual interface, go deeper with code, connect to everything. Its official GitHub repo adds more than 400 integrations, a choice between self-hosting and cloud, and built-in AI capabilities.

For an FDE, the appeal is speed. The time between a customer discovery session and the first time the customer sees a flow running on their own data gets much shorter.

Speed is not the hardest question, though. The harder one is when to leave n8n.

What can n8n’s LLM core do?

According to n8n’s documentation, you can build AI workflows that connect to many LLM providers, including OpenAI, Anthropic and Google. The most useful part is the AI Agent node. You attach a chat model and one or more tools to it, and the agent decides which tool to call to complete its task.

Here is how that could look for the email classification example. A trigger receives each new email and passes its content to an AI Agent node. The agent has two tools: one looks up the customer in the company’s own system, and the other creates a ticket.

Because the agent chooses its own tools, the tool descriptions need more care than anything else in the workflow. The sketch below is hypothetical. It shows what you should prepare before you start dragging nodes, not n8n’s exact configuration format. The original example uses Vietnamese field names: tra_cuu_khach_hang is the customer lookup, tao_ticket creates a ticket, and muc_do is the priority, either thuong (normal) or gap (urgent).

Tool 1: tra_cuu_khach_hang
  Mô tả: Dùng khi email có địa chỉ gửi hoặc mã khách hàng.
         Trả về hạng hợp đồng và người phụ trách.
  Đầu vào: email_nguoi_gui

Tool 2: tao_ticket
  Mô tả: Dùng sau khi đã biết khách là ai.
         Mức "gấp" nếu email nói hệ thống ngừng chạy.
  Đầu vào: tieu_de, muc_do (thuong | gap), nguoi_phu_trach

In plain terms, the first tool is used when an email includes a sender address or customer ID, and it returns the contract tier and account owner. The second is used once the customer is known, and it marks the ticket urgent if the email says the system is down.

The agent reads each email and decides whether to look up the customer first or create a ticket straight away. The more clearly each description says when to use the tool, the less often the agent calls the wrong one. Agree the exact wording with the customer.

If you maintain workflows that someone else built, there is one detail you need to know. Since version 1.82.0, the AI Agent node’s agent type setting has been deprecated, and every AI Agent node now runs as a Tools Agent.

An older workflow that used a different agent type may behave differently after an upgrade. Test it again before you upgrade the customer’s environment.

Errors will happen. The question is who finds out first

LLMs sometimes time out or return malformed JSON, and customer APIs sometimes go down. n8n lets you attach an error workflow to each workflow, provided that the error workflow starts with an Error Trigger node. In the email example, the error workflow could alert the customer’s operations channel and say which email failed.

A demo only has to work while you are in the room. A flow that a customer is willing to leave running overnight has to report its own failures. At handover, show the customer what happens when something fails, not only what happens when everything works.

The mistakes below follow from how n8n works, and they are worth checking before every handover:

Common mistake	Consequence	How to avoid it
Vague tool descriptions that do not say when to use the tool	The agent calls the wrong tool or skips the lookup step	Write the conditions for using each tool and agree them with the customer
No error workflow attached	Failed emails disappear without anyone noticing, and the customer finds out later	Attach an error workflow that starts with an Error Trigger and alerts the operations channel
Business logic crammed into the Code node	You hit the HTTP, file system and npm limits when the work is nearly finished	Move the logic into a separate service and use n8n only for orchestration
Upgrading n8n without testing older workflows	The AI Agent node behaves differently because agent type has been deprecated	Test on a copy before upgrading the customer’s environment

When is the Code node not enough?

n8n has a Code node for custom logic, but the documentation names two limits: the Code node cannot access the file system and cannot make HTTP calls directly. n8n Cloud adds a third: you cannot import external npm modules.

Suppose a customer needs Vietnamese addresses standardised with an internal library, or needs to call an API that signs requests in its own way. If you are on Cloud, you cannot install that library.

Even if you self-host, that logic does not belong in the Code node. It is more practical to put it in a small service that you write and test yourself, and leave n8n to handle orchestration.

When one instance is no longer enough

Load is the second signal. n8n has a queue mode with separate workers, which the documentation describes as the best way to scale: add workers when load rises and remove them when it falls.

How do you know it is time? Suppose the email flow runs smoothly all week. Then on Monday mornings, the weekend’s emails all arrive at once, and executions pile up because each one has to wait for the LLM to respond. An email from a major customer saying their system is down sits behind hundreds of routine ones and waits a long time for a ticket.

That is the symptom to watch for. The time between an email arriving and a ticket being created shoots up at peak hours, even though the flow reports no errors. Start measuring this number in the first week.

Once it goes beyond what the customer will accept, it is time to consider queue mode. It is also time to make someone properly responsible for operations, because at that point you are running real infrastructure, not a convenient tool.

Licensing is where FDEs most often get caught out

n8n is not purely open source. The repo states that the software is distributed as fair-code under the Sustainable Use License and the n8n Enterprise License.

The Sustainable Use License allows you to use or modify the software only for your own internal business purposes or for non-commercial or personal use.

You may distribute the software or make it available to others only free of charge and for non-commercial purposes.

FDEs should look closely at two scenarios. A customer running n8n to automate its own internal work is one thing. Your company packaging n8n into a solution and selling or providing it to several customers is quite another. The second needs legal review before any contract is signed.

Between these two there is a common grey area. Suppose your company self-hosts an n8n instance on its own infrastructure, serves a single customer with it and charges a monthly fee for running it.

Is that still “internal purposes”, or has it become “making it available to others”? The licence text does not settle the question for you. Write the scenario up as a specific question for legal, and ask it early, not at handover.

Enterprises also tend to ask about governance. The Community edition has almost all the features, but it does not include SSO, Projects or Git-based version control. If the customer requires centralised login or wants to review workflows the way it reviews code, say so in the first meeting.

What to learn first, and what to put on your CV

Start by self-hosting n8n. That way you avoid the Cloud edition’s npm limit and learn how to operate it at the same time. Then practise three things, in order: the AI Agent node with tools you define yourself, error workflows, and moving complex logic into a separate service that n8n calls.

On your CV, do not just write “proficient in n8n”. Describe a specific decision, for example: built an email classification prototype in n8n in two days, then moved data normalisation into a separate service when the Code node was no longer enough. A line like that shows a reader both speed and judgement.

Customers will remember the demo you built in an afternoon. An FDE’s value lies in knowing when that work needs to move into code.