n8n

n8n is a fair-code, source-available workflow automation platform. I use it to build autonomous pipelines that connect AI models, REST APIs, databases, and internal tooling without hand-writing glue code for every integration.

Its node-based editor turns business logic into reviewable, versionable graphs. For me the real value lands in the AI dimensions: n8n-native AI agents, vector-store RAG steps, and the ability to route work between deterministic workflow runs and model-in-the-loop decisions.

Because workflows are code-like (exportable JSON, git-versionable), it fits my architectural discipline — automation that is auditable, testable, and does not accumulate hidden tribal knowledge.

On the integration side I rely on the node ecosystem and webhooks. Most SaaS tools expose a REST or webhook interface, and n8n abstracts those into nodes so a pipeline can chain a CRM, a mailbox, a database, and an LLM in one visual flow rather than a pile of bespoke scripts.

I structure production n8n work around what most teams get wrong: error handling, retries, and idempotency. An automation that silently fails on step three is worse than none, so I make every branch explicit — success and failure paths, de-dup on re-runs, and alerting when a run does not finish cleanly.

For AI-specific flows I separate the deterministic plumbing from the model decisions. Embedded AI gets a tool boundary with a schema, and the agent node decides when to call tools; retrieval flows use vector stores that are kept as an explicit, maintainable index rather than an ad-hoc embedding dump.

The human-in-the-loop dimension is where n8n excels versus pure code. Approval steps, manual confirmation gates, and pause-and-resume around financial or destructive actions keep automation fast but safe, which matters when you hand a workflow to stakeholders who do not read code.

I treat the workflow definition itself as a deliverable: exported JSON committed to the repo, named steps, documented credential scope, and a clear owner for each workflow. That turns "someone set up an automation" into something the whole team can audit and operate.

Picking the right tool matters as much as the flows. When a process is a short, event-driven integration with clear retries, n8n is often the best fit; when it is a long-running, stateful, governed process, I reach for a BPMN engine like Camunda. My value is knowing which of the two each job actually wants.

I start a pipeline by naming the outcome, not the steps. Before drawing nodes I write down what the automation must guarantee — the input, the decision it makes, and the action it takes — so the workflow is built toward an agreement, not improvised node by node.

Every workflow gets a visible error path. I wire the failure branch of each step explicitly — retry, alert, or dead-letter — so a failed run is loud and recoverable instead of silently dropping work on the floor.

Credentials and connections are scoped per workflow. Each node's authentication is tied to the least access its step actually needs, which keeps one compromised credential from opening the whole estate.

I treat the exported workflow JSON as the artifact of record. It is committed, versioned, and named, and changes to it go through review like any code change — not a live edit someone forgets in the browser.

For anything retryable I lean on idempotency. A re-run of a step must not double-send an email or double-create a record, so I add de-duplication keys and guard the side effects before wiring retries in.

Human-in-the-loop steps are deliberate and rare. I put an approval gate only where a decision genuinely warrants it, so the automation stays fast while the parts that need judgement still get a person.

When AI is in the flow I isolate it. The model call sits behind a typed tool boundary with a schema, and the deterministic routing around it stays plain — so the pipeline is predictable even when the model is not.

Monitoring is wired from day one. Executions log, failures alert, and throughput is visible, so a workflow running in the background is an operated component, not a gamble someone set up once and forgot.

When a process grows past a short event-driven shape — long-running, stateful, multi-party — I escalate it to a BPMN engine like Camunda rather than stretching n8n past its comfortable lane. Knowing that boundary is part of the discipline.