AI Integrator: a profession not found in textbooks — I built it myself on n8n

One of the most in-demand professions in Europe, the US, and Russia in 2026–2027, why it is not an ML engineer or Data Science specialist, and what the working pipeline looks like: webhook → LLM → CRM → Telegram — no team of ten people required.

My name is Daniil. I am an integration developer — previously working with Kafka, REST, highload systems. In 2024–2025, I was given a task for the first time that HR calls by different names: AI automation, n8n integrator, applied AI engineer. I call this role an AI integrator: a person who builds business processes from events, APIs, and LLMs — mostly without a classic release cycle, using a no-code/low-code orchestrator.

I am not an ML engineer. I am not a prompt engineer working in a vacuum. I was the first to set up and bring to operational status a self-hosted n8n instance with an LLM embedded in the pipeline: an event comes in → the model processes it → data is sent to Google Sheets, Telegram, amoCRM / Bitrix24.

The topic is different: AI integrators are already being sought on the market, but there is almost no one who can explain what this work looks like from the inside. There are almost no videos on this topic on Russian YouTube, and n8n + LLM + CRM is an uncharted territory between "wrote a Python script" and "set up ChatGPT for managers".

The goal was as follows: the event has already occurred, but the business still processes it manually — via spreadsheet, Telegram, CRM, notifications. The payment provider or marketplace delivers the event — that is their responsibility. But what to do next — a row in Google Sheets, a message in Telegram, a lead in CRM — is still done manually by a huge number of teams. According to various surveys, sales departments spend a quarter of their working time entering data into CRM; almost half of companies have not implemented automation tools at all. In mature products, the core pipeline is automated. The "last mile" for business is often Excel, chat, and copy-paste. That is exactly what I wanted to eliminate. When an event arrives, the team does not transfer anything manually: accounting, alerts, and the CRM update on their own. Any external event should turn into a business action within seconds — with AI embedded in the process, not replacing the process. I wanted to create not a fragmented event ingress, but a single production loop for integration. I managed to assemble a self-hosted loop in Docker in just a couple of days:

• n8n — queue mode, PostgreSQL, 3 workers, Redis queue

• nginx — single entry point

• gateway — thin layer

• Observability — Prometheus, Grafana, Loki

Workflows that are actually running:

This is not "a single OpenAI node for demo purposes". This is a pipeline: the event passes through multiple systems, the LLM is a step in the chain, just like an HTTP request or a record written to a spreadsheet.

For this project, I stuck with ChatGPT: gpt-4o-mini and the free generation platform. You can pick any other option, it is not a critical factor.

What this looks like in practice

Let's take payment-succeeded — conditional 9 752 ₽.

Previously: the event is received somewhere, then ops checks the provider's email or personal account, manually adds a row to the spreadsheet, manually sends a message to Telegram, and sales manually creates a deal in amoCRM.

Now it's a single chain in n8n:

1. Event → gateway → workflow Google Sheet

2. gpt-4o-mini receives a JSON and writes a short breakdown for ops: what happened, the amount, what to pay attention to

3. The row automatically ends up in Google Sheets

4. A ready-made message is sent to Telegram — not a copy-paste from the provider's personal account

5. A deal is created in the required sales funnel in amoCRM

A person does not transfer data between systems. They set up the pipeline once — and then check that the chain is running properly.

The n8n interface really does look like Draw.io: nodes, arrows, branches. You can set up a webhook → Telegram chain in an evening.

No-code gave us speed. Docker, nginx, gateway, and Grafana are in place to keep the pipeline from falling apart at the first production event.

Agent Router Filter is not "AGI in a chat". It is an intent router: it performs the task a human used to do — "is this a lead or just a regular question?".

Of course, there were also a few fuckups along the way.

What happens to the spreadsheet technically

1. OAuth2 — this is the n8n credential for Google (Sheets API + Drive API). You connect it once → then the node writes data on behalf of the service account / Google user.

2. Append Row — not a trigger, not "open the spreadsheet and add a row manually". Each new event adds a row to the bottom.

3. Column mapping — data is pulled from the saved payload (Edit Fields), because after the Redis nodes, the current $json is already different:

   timestamp — when the event arrived
   event — type (payment_succeeded, payment_failed…)
   amount — amount
   raw_payload — full JSON of the event (archived for troubleshooting purposes)

The screenshot shows: the row appeared on its own — the manager did not create it and did not copy it from a webhook.

4. Workflow order — the entry to Sheets happens after LLM processing and before Telegram and amoCRM. First we log the fact, then we send a notification and create a deal.

5. Duplicates don't spawn rows — we use gateway idempotency, and deduplication via Redis in the workflow. Repeated events do not reach Append Row → no second identical row appears in the table.

6. If Sheets crashes — the event is not lost: DLQ + Retry_runner retries it. After a successful retry, a row with a retry marker may appear in the table — ops can see that this is a repeated delivery, not "two different payments".

Summary

AI integrator in 2026–2027 — definitely will not replace backend (or not right away), but it will bring a clear objective: close the loop of the "event → AI → accounting → alert → CRM" flow without manual data re-entry.