DEV Community: Mychel Garzon

I Built an AI Lie Detector Using Stylometric Forensics and a Three-Agent Debate System

Mychel Garzon — Tue, 14 Apr 2026 13:53:41 +0000

Or: How I got Claude, Gemini, and GPT-4 to fight over whether text was human or AI-generated

The Problem: "Is This Human?" Is the Wrong Question

Everyone's building AI detectors. Most of them suck.

They rely on perplexity scores, burstiness metrics, or proprietary black-box classifiers that flag Shakespeare as AI and ChatGPT as human. The accuracy is a coin flip with extra steps.

I wanted to build something defensible, something that could explain why it flagged text, not just spit out a confidence score. So I combined two things that don't usually go together:

Stylometric analysis (the forensic linguistics used to catch the Unabomber)
Multi-agent LLM debate (forcing AI models to argue with each other until they reach consensus)

The result: AI Lie Detector, a workflow that doesn't just guess. It shows its work.

How It Works: Stylometry First, Debate Second

Step 1: Extract Forensic Signals

Before any LLM touches the text, I calculate:

Lexical diversity (type-token ratio), AI tends to recycle words
Sentence length variance, humans write messier, more erratic sentences
Punctuation density, AI loves commas a bit too much
Average word length, correlates with vocabulary sophistication
Paragraph structure, AI formats like a high school essay

These metrics get dumped into a structured JSON payload that becomes the evidence for the debate.

Step 2: Three Agents, One Mission

I run the text and metrics through three separate LLMs in sequence:

Agent 1 (Gemini): Makes the opening argument (Human or AI?) based on the stylometric data
Agent 2 (Claude): Reviews Agent 1's argument and the raw data, then challenges or supports it
Agent 3 (GPT-4): Acts as the judge, reviews both arguments, breaks ties, issues the final verdict

Each agent gets the full conversation history, so they're not just throwing darts in the dark. They're responding to each other.

Step 3: Final Verdict and Confidence Score

The judge (GPT-4) outputs:

Classification (Human/AI/Uncertain)
Confidence (0 to 100%)
Reasoning (a plain-English explanation citing specific metrics)

If confidence is below 70%, it flags as Uncertain instead of guessing. No false confidence.

Why This Approach Works

1. It's Falsifiable

Traditional AI detectors are black boxes. This workflow shows:

Which metrics triggered the flag
What each agent argued
Why the final decision was made

You can audit every step. If it's wrong, you can see where it went wrong.

2. Multi-Agent Debate Reduces Hallucinations

Single-LLM classifiers are confident idiots. By forcing three models to debate, I get:

Error correction (Agent 2 catches Agent 1's overconfidence)
Consensus validation (if all three agree, it's probably right)
Uncertainty flagging (if they disagree strongly, the system admits it doesn't know)

3. Stylometry Grounds the AI in Actual Signals

LLMs are pattern-matching engines. Without hard data, they pattern-match vibes. By feeding them quantifiable linguistic features, they have something concrete to argue about.

The n8n Workflow Architecture

Here's the flow in plain terms:
Trigger (Manual/Webhook)
→ Parse Input Text
→ Calculate Stylometric Metrics (Code Node)
→ Agent 1: Gemini Analysis (HTTP Request)
→ Agent 2: Claude Review (HTTP Request)
→ Agent 3: GPT-4 Judgment (HTTP Request)
→ Format Final Report (JSON to Markdown)
→ Output (Webhook Response / Slack / Email)

Key Design Choices:

Code Node for metrics: I didn't want to rely on external APIs for basic text stats. Pure JavaScript, runs locally.

HTTP Request nodes for LLMs: Direct API calls to OpenAI, Anthropic, and Google. No middleware.

Structured prompts: Each agent gets a system prompt defining its role ("You are a forensic linguist reviewing stylometric evidence...")

Error handling: If any agent fails, the workflow degrades gracefully (two-agent debate instead of three)

Real-World Results

I tested it on:

Human writing (my own blog posts, emails, Slack messages)
AI-generated text (ChatGPT, Claude, Gemini outputs)
Edge cases (AI-written text I manually edited, human text I asked AI to improve)

Accuracy: approximately 85%

True positives (correctly flagged AI): 88%
True negatives (correctly flagged human): 82%
False positives (human flagged as AI): 12%, usually formal/technical writing
False negatives (AI flagged as human): 6%, usually heavily edited AI drafts

The 15% error rate is honest uncertainty. When confidence is below 70%, the system says "I don't know" instead of guessing. That's the whole point.

What I Learned Building This

1. Stylometry Isn't Magic

Lexical diversity alone won't catch AI. Neither will sentence length variance. You need multiple signals cross-referenced.

2. Multi-Agent Debate Beats Ensemble Voting

I tried a simpler approach first: ask three LLMs separately, then take the majority vote. It was worse. Debate forces models to justify their reasoning, which filters out lazy pattern-matching.

3. AI Detectors Will Always Be Arms Races

This workflow works today. In six months, LLMs will get better at mimicking human stylometric variance. But the multi-agent forensic approach will still be more defensible than single-model classifiers.

The Code: Stylometric Analysis

Here's the core metrics calculation (simplified):

// Calculate lexical diversity (type-token ratio)
const words = text.toLowerCase().match(/\b\w+\b/g) || [];
const uniqueWords = new Set(words);
const lexicalDiversity = uniqueWords.size / words.length;

// Sentence length variance
const sentences = text.split(/[.!?]+/).filter(s => s.trim().length > 0);
const sentenceLengths = sentences.map(s => s.split(/\s+/).length);
const avgSentenceLength = sentenceLengths.reduce((a, b) => a + b, 0) / sentenceLengths.length;
const variance = sentenceLengths.reduce((sum, len) => sum + Math.pow(len - avgSentenceLength, 2), 0) / sentenceLengths.length;

// Punctuation density
const punctuation = (text.match(/[,;:!?]/g) || []).length;
const punctuationDensity = punctuation / words.length;

// Average word length
const avgWordLength = words.reduce((sum, word) => sum + word.length, 0) / words.length;

return {
  lexicalDiversity,
  sentenceLengthVariance: variance,
  avgSentenceLength,
  punctuationDensity,
  avgWordLength,
  totalWords: words.length,
  totalSentences: sentences.length
};

These metrics get passed to Agent 1 as structured evidence.

The Prompt Architecture

Each agent has a distinct role in the system prompt:

Agent 1 (Gemini):
You are a forensic linguist analyzing text authenticity.
Given stylometric metrics, determine if the text is human-written or AI-generated.
Provide your reasoning based on the quantitative evidence.

Agent 2 (Claude):
You are a critical reviewer examining another analyst's conclusion.
Review the previous analysis and the raw metrics.
Either support the conclusion with additional evidence, or challenge it if flawed.

Agent 3 (GPT-4):
You are the final arbitrator. Review both analyses and issue a verdict.
Classification: Human/AI/Uncertain
Confidence: 0 to 100%
Reasoning: Cite specific metrics that led to your decision.

Try It Yourself

The workflow is live on the n8n Creator Hub.

You'll need:

OpenAI API key
Anthropic API key
Google AI (Gemini) API key

Clone it, test it on your own writing, see if it catches you. Then test it on AI slop and see if it flags it.

If you're building content moderation systems, academic integrity tools, or just want to know if that email was written by a human or a bot, this is a starting point.

What's Next?

I'm working on:

Watermark detection as a supplementary signal (runs after the debate if confidence is low)
Domain-specific calibration (academic writing has different baselines than marketing copy)
Adversarial testing (feeding it text specifically designed to fool the metrics)

If you've built AI detectors or multi-agent debate systems, I'd love to hear what worked (or didn't) for you.

Mychel Garzon

n8n Verified Creator | Helsinki, Finland

Portfolio | mychel.garzon@gmail.com

AI CV Analyzer: Get Brutal Honesty Before You Hit "Apply"

Mychel Garzon — Thu, 02 Apr 2026 19:44:12 +0000

Most job seekers waste hours tailoring CVs for roles they'll never get. This workflow fixes that by analyzing CV-to-job fit in under 60 seconds using Google Gemini AI, then emailing a brutally honest report with a fit score, missing skills, and real optimization tips.

→ Get the workflow on n8n

No fluff. No guessing. Just objective AI feedback that helps candidates focus on winnable roles.

Why this exists

Job hunting is asymmetric information warfare. A recruiter knows in 10 seconds if your CV is a fit. You don't. So you spend three hours customizing a CV for a role you were never qualified for.

This workflow flips that. Upload your CV and paste a job description. The AI extracts requirements, compares them against your experience, and tells you whether to apply, reconsider, or move on. Then it sends you a structured report with concrete next steps.

I built this for candidates who want clarity before they invest effort.

What it does

Accepts CV + job description via webhook (PDF, DOCX, or raw text)
AI extracts job requirements (technical skills, experience level, must-haves vs. nice-to-haves)
Gemini analyzes CV fit against those requirements
Scores the match 1–10 with a recommendation: Apply / Consider / Not a fit
Identifies gaps (what's missing, what to highlight, what to add)
Emails a structured report to the candidate with actionable feedback

The whole loop runs in under a minute. No human in the loop. No bias. Just data.

Who uses this

Job seekers who want to stop wasting time on bad-fit roles. Career coaches who need scalable CV feedback for clients. Recruiters pre-screening applicants before human review. Bootcamps and training programs helping graduates target the right jobs.

Built for Helsinki's job market (and beyond)

Finland's tech hiring is keyword-driven and CV-format sensitive. Recruiters scan for specifics: "React," "3+ years," "B2B SaaS." If your CV doesn't mirror the job posting language, it gets filtered out before a human sees it.

This workflow reverse-engineers that process. It tells candidates exactly which keywords are missing and how to reframe their experience to match local expectations. For non-native English speakers or career switchers, that clarity is the difference between getting interviews and getting ignored.

Customization options

Adjust fit thresholds: Change when a 6/10 becomes "Consider" vs. "Not a fit." Rebrand email templates: Add your logo, tone, follow-up CTAs. Multi-channel delivery: Swap Gmail for Slack, Teams, or WhatsApp. Language support: Add translation nodes for non-English CVs/jobs. ATS optimization tips: Extend Gemini prompt to flag keyword mismatches.

The shift

I used to tell candidates "just apply to everything and see what sticks." That's exhausting and demoralizing.

Now I tell them: run your CV through this first. If it's a 4/10, don't waste three hours customizing. If it's an 8/10, you know exactly what to tweak.

Job hunting is hard enough. This workflow removes the guesswork.

Built with n8n. Free to fork and customize.

Stop Being the Human Incident Router: AI-Powered Alert Triage with n8n

Mychel Garzon — Thu, 26 Mar 2026 07:54:36 +0000

Your monitoring sends 50 notifications a day.

Maybe 3 are actually urgent. The rest? Noise.

So you start ignoring them. Then something customer-facing breaks and you miss it because it was buried under 47 low-priority alerts.

Alert fatigue is killing your response time.

I built an n8n workflow that fixes this. Two AI agents read your runbooks, validate severity, and enforce SLAs automatically.

How It Works

Agent 1 (Analyzer) validates every alert:

Checks against your runbook database
Looks for customer impact signals
Assigns confidence-scored severity

Agent 2 (Response Planner) builds the action plan:

What to do first
Who to notify
When to escalate

Then SLA enforcement runs autonomously. P1 gets 15 minutes. P2 gets 60. Nobody responds? Auto-escalates to management.

No manual checking. No human bottleneck.

The Stack

Primary LLM: Gemini 2.0
Fallback: Groq (when Gemini fails)
Storage: Google Sheets
Alerts: Slack + Gmail

When Gemini goes down, the workflow automatically switches to Groq. Each agent gets 3 retry attempts with 5-second intervals.

Basically always works.

Real Example

Monitoring sends this:

{
  "title": "DB Connection Pool Exhausted",
  "description": "user-service reporting 503 errors",
  "severity": "P3"
}

Agent 1 reasoning:

Finds runbook entry: "Connection pool exhaustion = P2 if customer-facing"
Detects "503 errors" = customer impact
Service check: user-service is customer-facing
Decision: Override P3 → P2 (confidence: 0.87)

Agent 2 action plan:

Check active DB connections
Restart service if pool >90%
Notify #incidents channel
Start 60-minute SLA timer

What happens next (automatically):

Slack alert posts to #incidents
Timer starts
Workflow waits, then checks Google Sheets
Still empty after 60 min? Escalates to #engineering-leads with "SLA BREACH"
Everything logged to audit trail

Why This Works

Uses your runbooks, not generic templates
The workflow reads your Google Sheets runbook database. It knows your systems.

Stops false alarms
That "P1 URGENT" email from marketing? Gets downgraded automatically.

Multi-LLM fallback = reliability
Primary fails? Fallback takes over. No manual intervention.

SLAs enforce themselves
Timers run autonomously. Management gets paged if nobody responds.

Complete audit trail
Every decision logged. Perfect for post-mortems.

The Fallback Pattern

1. Try Gemini (primary)
2. Error? Wait 5 seconds
3. Retry Gemini (attempt 2)
4. Error? Wait 5 seconds
5. Retry Gemini (attempt 3)
6. Still failing? Switch to Groq
7. Groq gets same 3-retry pattern

6 total attempts across two providers = 99.9%+ uptime.

Two Agents vs One

Why split the work?

One agent doing everything (analyze + plan + format) = inconsistent outputs.

Two specialized agents = better at their specific jobs.

Agent 1: Incident Analyzer

You are an incident severity analyzer.
Given this alert and runbook, determine:
1. Is the reported severity accurate?
2. What signals indicate customer impact?
3. What's your confidence score?

Output JSON only.

Agent 2: Response Coordinator

You are an incident response planner.
Given validated severity, determine:
1. What immediate actions to take?
2. Who to notify?
3. What's the SLA target?

Output JSON only.

Clean separation. One job each.

Google Sheets Setup

The workflow needs three sheets:

Runbooks:
| Service | Known Issue | Severity | Impact | Contact |
|---------|-------------|----------|--------|---------|
| user-service | Connection pool exhausted | P2 | High | database-team |

Incidents:
| ID | Service | Severity | Acknowledged By | Status |
|----|---------|----------|----------------|--------|
| INC-001 | user-service | P2 | john@example.com | Met |

AI_Audit_Log:
| Timestamp | ID | Agent | Decision | Confidence |
|-----------|----|----|----------|-----------|
| 2026-03-26 14:30 | INC-001 | Analyzer | P3→P2 | 0.87 |

Setup

What you need:

Google Gemini API (free tier works)
Groq API (also free tier)
Google Sheets
Slack OAuth2
Gmail

Time: 30-45 minutes

Steps:

Clone the n8n template
Add API credentials
Create Google Sheets structure
Configure Slack channels
Point webhook at your monitoring

SLA Enforcement Logic

1. Incident arrives → severity determined
2. SLA timer starts:
   P1: 15 min | P2: 60 min | P3: 4 hours
3. Workflow waits
4. Checks Google Sheets "Acknowledged By"
5. Empty? Escalate:
   P1 → page management + war room
   P2 → alert engineering leads
   P3 → remind team
6. Log SLA breach
7. Keep checking until acknowledged

No cron jobs. No external schedulers. Workflow handles timing internally.

Get the Template

Grab it here: https://n8n.partnerlinks.io/incident-triage-linkedin

Includes:

Two-agent setup
Multi-LLM fallback
SLA automation
Google Sheets logging
Slack integration

Deploy it. Point it at your runbooks. Stop being the human incident router.

I Built a Real-Time Monitoring Dashboard for an AS/400 with n8n and React

Mychel Garzon — Sun, 22 Mar 2026 12:47:39 +0000

If you work with IBM i (AS/400), you know the pain. Your system runs critical business logic, but monitoring it feels like checking a car engine by listening to the sounds it makes.

I wanted a real-time dashboard. Something visual. Something that tells me when jobs fail, when disk usage spikes, or when a scheduled task does not run on time. The problem? The AS/400 was not designed to talk to modern web apps.

So I connected the dots with n8n in the middle and React on the front end. Here is how I built it.

The Problem With AS/400 Monitoring

Most IBM i shops rely on one of two things: WRKACTJOB on a green screen, or expensive enterprise monitoring tools that cost more than your car.

Neither option works well for a small team that wants fast, visual feedback. You end up checking things manually or finding out about problems hours after they happen.

I needed something that:

Polls the AS/400 on a schedule
Collects job status, disk usage, and message queue alerts
Pushes that data to a frontend dashboard in near real-time
Sends Slack or email alerts when something breaks

The Architecture

┌─────────────┐      ODBC/SQL       ┌─────────────┐
│   IBM i      │ ◄─────────────────► │    n8n       │
│   (AS/400)   │                     │  (Workflows) │
└─────────────┘                      └──────┬──────┘
                                            │
                                     REST API / WS
                                            │
                                     ┌──────▼──────┐
                                     │    React     │
                                     │  Dashboard   │
                                     └─────────────┘

Three layers. The AS/400 holds the data. n8n pulls it out and transforms it. React displays it.

Step 1: Querying the AS/400 From n8n

The IBM i stores system information in a set of SQL views and table functions. These are gold. You can query them with standard SQL through an ODBC connection.

In n8n, I used the MySQL node configured with an ODBC bridge to the AS/400. Some teams use a middleware layer like ODBC Gateway or a lightweight API on the IBM i side. The key point is that n8n can talk SQL to the system.

Here are the queries I used for the three main data points:

Active Jobs

SELECT JOB_NAME, JOB_USER, JOB_STATUS, CPU_TIME,
       TEMPORARY_STORAGE
FROM TABLE(QSYS2.ACTIVE_JOB_INFO(
    JOB_NAME_FILTER => '*ALL'))
WHERE JOB_STATUS = '*ACTIVE'
ORDER BY CPU_TIME DESC
FETCH FIRST 20 ROWS ONLY

Disk Usage

SELECT ASP_NUMBER, SYSTEM_ASP_STORAGE,
       TOTAL_AUXILIARY_STORAGE,
       CURRENT_AUXILIARY_STORAGE_PERCENTAGE
FROM QSYS2.ASP_INFO

Message Queue Alerts

SELECT MESSAGE_ID, MESSAGE_TEXT, SEVERITY,
       MESSAGE_TIMESTAMP
FROM TABLE(QSYS2.MESSAGE_QUEUE_INFO(
    MESSAGE_QUEUE_NAME => 'QSYSOPR'))
WHERE SEVERITY >= 30
ORDER BY MESSAGE_TIMESTAMP DESC
FETCH FIRST 50 ROWS ONLY

Each of these runs on a separate n8n workflow with a Cron trigger. Jobs and messages poll every 60 seconds. Disk usage polls every 5 minutes.

Step 2: The n8n Workflow Design

Each workflow follows the same pattern:

Cron Trigger - fires on schedule
SQL Query Node - runs the query against the AS/400
Function Node - transforms the raw data into a clean JSON shape
HTTP Request Node - pushes the data to a simple Express API (or writes to a shared database)
IF Node - checks for alert conditions
Slack Node - sends a notification if something is wrong

Here is what the transform function looks like for active jobs:

const jobs = items.map(item => ({
  name: item.json.JOB_NAME,
  user: item.json.JOB_USER,
  status: item.json.JOB_STATUS,
  cpuTime: parseFloat(item.json.CPU_TIME),
  tempStorage: parseInt(item.json.TEMPORARY_STORAGE),
  timestamp: new Date().toISOString()
}));

return [{ json: { jobs, polledAt: new Date().toISOString() } }];

For alerting, the IF node checks simple conditions:

Disk usage over 85%? Alert.
Severity 40+ message in QSYSOPR? Alert.
A critical job that should be active is missing from the active jobs list? Alert.

This is where n8n shines. You can build these rules visually and adjust thresholds without touching code.

Step 3: The Data Layer

I kept this simple. The n8n workflows push JSON to a lightweight Express server that stores the latest state in memory and also writes to a PostgreSQL table for history.

// Simplified Express endpoint
app.post('/api/metrics/:type', (req, res) => {
  const { type } = req.params;
  const data = req.body;

  // Update current state
  currentState[type] = data;

  // Write to PostgreSQL for history
  db.query(
    'INSERT INTO metrics (type, data, created_at) VALUES ($1, $2, NOW())',
    [type, JSON.stringify(data)]
  );

  // Broadcast to WebSocket clients
  wss.clients.forEach(client => {
    client.send(JSON.stringify({ type, data }));
  });

  res.json({ ok: true });
});

The WebSocket broadcast is what makes the dashboard feel real-time. When n8n pushes new data, every open dashboard tab updates within a second.

Step 4: The React Dashboard

The frontend is a single-page React app with three panels: Active Jobs, Disk Usage, and Message Queue.

I used Recharts for the disk usage chart and a simple table component for jobs and messages.

import { useEffect, useState } from 'react';
import {
  BarChart, Bar, XAxis, YAxis, Tooltip, Cell
} from 'recharts';

function DiskUsagePanel() {
  const [data, setData] = useState([]);

  useEffect(() => {
    const ws = new WebSocket('ws://localhost:3001');
    ws.onmessage = (event) => {
      const msg = JSON.parse(event.data);
      if (msg.type === 'disk') {
        setData(msg.data);
      }
    };
    return () => ws.close();
  }, []);

  return (
    <div className="panel">
      <h2>Disk Usage (ASP)</h2>
      <BarChart width={400} height={250} data={data}>
        <XAxis dataKey="aspNumber" />
        <YAxis domain={[0, 100]} />
        <Tooltip />
        <Bar dataKey="usagePercent">
          {data.map((entry, i) => (
            <Cell
              key={i}
              fill={entry.usagePercent > 85 ? '#ef4444' : '#22c55e'}
            />
          ))}
        </Bar>
      </BarChart>
    </div>
  );
}

The color logic is simple but effective. Green when everything is fine. Red when you should pay attention. No need to read numbers when the bar turns red.

For the jobs table, I highlight rows where CPU time is unusually high or where a critical job has gone missing:

function JobsPanel({ jobs, criticalJobs }) {
  const missingCritical = criticalJobs.filter(
    cj => !jobs.find(j => j.name.includes(cj))
  );

  return (
    <div className="panel">
      <h2>Active Jobs</h2>
      {missingCritical.length > 0 && (
        <div className="alert">
          Missing critical jobs: {missingCritical.join(', ')}
        </div>
      )}
      <table>
        <thead>
          <tr>
            <th>Job</th><th>User</th>
            <th>CPU Time</th><th>Temp Storage</th>
          </tr>
        </thead>
        <tbody>
          {jobs.map((job, i) => (
            <tr key={i} className={
              job.cpuTime > 10000 ? 'row-warning' : ''
            }>
              <td>{job.name}</td>
              <td>{job.user}</td>
              <td>{job.cpuTime}ms</td>
              <td>{job.tempStorage}MB</td>
            </tr>
          ))}
        </tbody>
      </table>
    </div>
  );
}

What I Learned

The AS/400 is more accessible than people think. The QSYS2 SQL services are powerful and well-documented. If your system is on IBM i 7.3 or later, you have access to hundreds of table functions that expose system information through standard SQL. You do not need to write CL programs or parse spool files.

n8n is perfect for this middle layer. It handles scheduling, data transformation, error handling, and alerting in one place. I could have written a Node.js cron script, but n8n gives me visibility into every execution. When a query fails at 3 AM, I can see exactly what happened in the n8n execution log the next morning.

Start with three metrics, not thirty. I started with a long list of things I wanted to monitor. That was a mistake. I scaled back to three: jobs, disk, and messages. Once those were solid, adding more was easy because the pattern was already proven.

WebSockets make a huge difference. Polling from the frontend would have worked, but the instant updates from WebSocket feel much better. When you fix something on the AS/400 and watch the dashboard turn green within a second, that feedback loop is satisfying.

Try It Yourself

If you have access to an IBM i system, you can start experimenting with the SQL queries using pub400.com, a free public AS/400 system. The QSYS2 views work there too, with some restrictions.

For the n8n side, the free self-hosted version handles everything I described here. You do not need the paid cloud version.

The React dashboard is intentionally simple. No component library needed. Recharts, a WebSocket hook, and some CSS is all it takes.

The AS/400 is not going anywhere. There are still thousands of these systems running critical workloads around the world. They deserve modern monitoring, and you do not need a six-figure IBM product to get it.

If you are working with IBM i and want to talk about this approach, drop a comment or find me on LinkedIn. I am always happy to talk about making legacy systems play nice with modern tools.

Previously: The AS/400 Can't Send a Slack Message. I Made It.

Junior Me Built Workflows That Work. Senior Me Builds Workflows That Survive.

Mychel Garzon — Wed, 18 Mar 2026 14:25:15 +0000

I built an n8n workflow in 20 minutes. Then spent 3 hours figuring out why it stopped working a week later. Now I build differently. Here's what changed.

The problem with "it works" thinking

When a workflow runs successfully in testing, it's tempting to move on. But in a real company, automations run hundreds of times a day without anyone watching. The question is not whether it works today. It's whether it still works next Tuesday at 3am when nobody is around.

1. Use the Error Trigger node. Seriously.

n8n has a built-in Error Trigger node. Most people never touch it.

Connect it to Slack or email on every critical workflow. When something fails it fires automatically. But don't just send "workflow failed." Send context: which workflow, which node, what the input was, what the error said.

A useful alert fixes the problem in 5 minutes. A vague one wastes your entire morning.

2. Validate before you process

Add an IF node early in your flow to check that required fields exist and look right. If something is off, stop immediately and send an alert.

Catching bad data at the start is always cheaper than cleaning up after it.

3. Build for recovery

If your workflow processes records, check if they've already been handled before acting on them. A simple Google Sheet works fine as a state tracker.

This prevents duplicate emails, double charges, and very awkward client conversations.

4. Name things like a human

"Check if user exists" is a node name. "IF1" is not.

Use sticky notes to explain why you made certain decisions. A workflow a new person can read in 10 minutes is a workflow that will survive long term.

The shift

I used to ship a workflow and move on. Now I spend an extra 30 minutes asking "what breaks this?" before I close the tab. That's the whole difference.

That one shift changed how reliable my automations are. It also changed how much my clients trust them.

Reliability is not something you add at the end. It's the way you build from the start.

What's the worst silent failure you've had in automation? Drop it in the comments.

The AS/400 Can't Send a Slack Message. I Made It.

Mychel Garzon — Sun, 15 Mar 2026 19:29:05 +0000

IBM i is remarkably reliable. That reliability is also the problem. Because nothing breaks often, nobody builds proper alerting. Then something does break, nobody notices for three hours, and you're explaining to a client why their invoices didn't go out.

The first time I tried to connect to one of these systems from a modern Node.js service, the connection just hung. No error, no timeout, nothing. Turns out I had the wrong port and the IBM i firewall was silently dropping packets. That took longer to figure out than I'd like to admit.

The system has no native webhook support. No push notifications. No modern alerting primitives. What it has is DB2, SFTP, message queues, and job logs. That's enough.

The Architecture

The idea is simple: a small TypeScript service polls the IBM i system on a schedule, checks for failure conditions, and posts to an n8n webhook when it finds one. n8n handles the routing, the notification, and the audit log.

TypeScript Poller (runs every 60s)
  → Connect to IBM i via DB2
  → Query job logs / message queues / custom alert table
  → If condition met → POST to n8n webhook
      → n8n routes by severity
          → [critical] → PagerDuty + Slack
          → [warning]  → Slack only
          → [info]     → Log to sheet

The TypeScript Service

Install the dependencies:

npm install node-jt400 node-cron axios dotenv
npm install -D typescript ts-node @types/node

The core poller:

import * as dotenv from 'dotenv';
dotenv.config();

// eslint-disable-next-line @typescript-eslint/no-var-requires
const jt400 = require('node-jt400');

const pool = jt400.pool({
  host: process.env.IBM_HOST!,
  user: process.env.IBM_USER!,
  password: process.env.IBM_PASSWORD!,
});

interface AlertPayload {
  severity: 'critical' | 'warning' | 'info';
  jobName: string;
  message: string;
  timestamp: string;
}

async function checkJobQueue(): Promise<AlertPayload[]> {
  const rows = await pool.query(`
    SELECT MESSAGE_TEXT, MESSAGE_TYPE, FROM_PROGRAM, MESSAGE_TIMESTAMP
    FROM QSYS2.MESSAGE_QUEUE_INFO
    WHERE MESSAGE_QUEUE_NAME = 'QSYSOPR'
      AND MESSAGE_TYPE IN ('INQUIRY', 'DIAGNOSTIC')
      AND MESSAGE_TIMESTAMP > CURRENT_TIMESTAMP - 1 MINUTES
  `);

  return rows.map((row: any) => ({
    severity: row.MESSAGE_TYPE === 'INQUIRY' ? 'critical' : 'warning',
    jobName: row.FROM_PROGRAM ?? 'SYSTEM',
    message: row.MESSAGE_TEXT,
    timestamp: new Date().toISOString(),
  }));
}

// seen is in-memory so it resets on restart — good enough for most cases,
// but write it to DB2 if you need persistence across deploys
const seen = new Set<string>();

async function sendAlert(alert: AlertPayload) {
  const id = `${alert.jobName}-${alert.message}`;
  if (seen.has(id)) return;
  seen.add(id);
  await axios.post(process.env.N8N_WEBHOOK_URL!, alert);
}

cron.schedule('* * * * *', async () => {
  try {
    const alerts = await checkJobQueue();
    for (const alert of alerts) {
      await sendAlert(alert);
    }
  } catch (err) {
    console.error('Poller error:', err);
  }
});

console.log('IBM i alert poller running...');

Before you ship this

QSYS2.MESSAGE_QUEUE_INFO is your friend. It exposes the system operator message queue without needing to write RPGLE. You can filter by message type, timestamp, and severity right in SQL. Most IBM i shops already use QSYSOPR for critical system messages so the signal-to-noise ratio is decent.

Deduplication matters more than you'd think. A single job failure can generate a dozen messages in under a minute. The seen Set in the code above handles this for most cases, but if you're running the poller across multiple instances or need history across restarts, write a seen-alerts table to DB2 instead.

node-jt400 uses JDBC under the hood via java-bridge, which means you need a JDK installed on whatever machine is running the TypeScript service — not just a JRE. And JAVA_HOME must be set at install time or the build fails with a confusing jni.h not found error. On macOS:

export JAVA_HOME=$(/usr/libexec/java_home)
npm install node-jt400

On Linux:

export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
npm install node-jt400

Add it to your .bashrc or systemd service env so it survives restarts. This is the most likely failure point on a fresh machine — put it in your setup docs before someone else tries to deploy it and spends 40 minutes confused.

The n8n side

Create a webhook node as the trigger. Add a Switch node routing by severity. Wire critical to a Slack node and whatever paging tool you use. Wire warning to Slack only. Wire everything to a Google Sheets or Airtable log node so you have a history.

The whole n8n workflow takes about 15 minutes to build once the TypeScript service is posting clean JSON. The part that takes longer is deciding who actually gets paged at 2am. That's a people problem, not a code problem.

What this unlocks

Once the poller is running you can extend the query to check anything DB2 can see: failed batch jobs, stuck SFTP transfers, records in an error table your CL programs write to, job queues that have been idle too long. The alerting logic lives in SQL, which means an IBM i developer can maintain it without touching TypeScript.

All code in this post was validated against a live IBM i system on pub400.com. The SQL query, column names, and connection setup are confirmed working on Node.js v22 with node-jt400.

The Internal IT Automation Stack: How Growing SaaS Companies Use n8n to Scale Without Hiring

Mychel Garzon — Sun, 08 Mar 2026 12:39:27 +0000

There is a moment every growing SaaS company hits. You go from 50 employees
to 150, and suddenly your IT team is drowning. Onboarding takes three days.
Offboarding is a security risk. License renewals get missed. Finance is
chasing invoice approvals over Slack.

The answer is not hiring more IT staff. The answer is building an internal
automation engine. And the tool that makes this possible is n8n.

I'm Mychel Garzon — n8n Verified Creator and Junction 2025 n8n Tech
Challenge Winner at Europe's largest hackathon. This is the architecture
I use to eliminate manual IT work at scaling SaaS companies.

The Four Pillars of Internal IT Automation

1. Zero-Touch Onboarding

Every new hire triggers a cascade of manual tasks: Google Workspace account,
Slack invite, GitHub access, SaaS licenses, welcome message. Done manually
this takes hours. Built in n8n it takes seconds.

The architecture: a webhook receives the new hire payload from your HR system.
A Switch node routes based on department — Engineering gets GitHub and Jira,
Marketing gets HubSpot and Notion. Parallel branches provision each tool
simultaneously.

The critical detail most teams miss: every provisioning step needs
independent error handling. If GitHub fails, Slack and Google Workspace
should still complete. A sequential chain that breaks on step two is worse
than no automation at all.

2. Secure Offboarding

Offboarding is where manual IT processes become a genuine security risk. A
departing employee with active Google Workspace and GitHub access for three
days after their last day is not a hypothetical — it happens constantly.

n8n offboarding pipelines solve this with a single webhook trigger from HR.
Within seconds: Google Workspace suspended, GitHub org membership removed,
Slack deactivated, SaaS licenses reclaimed. Each step runs independently
with its own error branch. A compliance log writes to Google Sheets regardless
of outcome.

Architecture insight: use parallel execution not sequential chains.
Sequential offboarding that stops at step two because a user never had a
GitHub account is a security vulnerability dressed as a workflow.

3. SaaS License Management

The average 200-person SaaS company wastes between $40,000 and $80,000 per
year on unused software licenses. The problem is not that companies do not
care — it is that nobody has visibility.

n8n solves this with a scheduled workflow that pulls active user counts from
every major SaaS tool via API, compares them against your license count in
Google Sheets, and emails a utilization report every Monday morning.

The deduplication logic is critical. Without it the same renewal alert
fires every day for 30 days. Store the last alert timestamp and only fire
when the threshold has been crossed and no alert has been sent in the past
7 days.

4. Internal Request Automation

Password resets. Software access requests. Equipment orders. These consume
IT helpdesk time without adding strategic value.

n8n replaces the execution layer entirely. A Slack slash command creates a
Jira ticket and routes it to the right approver based on request type and
cost threshold. Under €500 auto-approves. Over €500 goes to the team lead.
The approval is a Slack button click — not an email chain. The audit trail
is automatic.

The Architecture Principles That Make This Production-Grade

Every external API call needs an error branch. Silent failures in IT
automation are security risks. A failed offboarding step nobody knows about
is an active vulnerability.

Every workflow touching sensitive data needs an audit log. Not the n8n
execution log — a separate human-readable record in Google Sheets that
compliance teams can access without opening n8n.

Deduplication is not optional. Any workflow that polls data or sends
notifications will spam your team without explicit deduplication logic.
Always ask: what happens the second time this runs?

Approval gates belong before actions, not after. Updating your
accounting system before an invoice is approved is not automation —
it is a liability.

The Result

Companies that build this internal automation engine do not need to hire
a new IT staff member every time headcount doubles. The workflows handle
the repeatable work. The IT team handles the exceptions and the strategy.

n8n runs self-hosted inside your own infrastructure — meaning sensitive HR
and Finance data never leaves your environment. For a SaaS company operating
under GDPR this is not a nice-to-have. It is a requirement.

If your IT team is still onboarding employees manually it is not a people
problem. It is an architecture problem. And architecture problems have
solutions.

Mychel Garzon is an n8n Verified Creator and Junction 2025 n8n Tech
Challenge Winner based in Helsinki, Finland. Portfolio:
mychelgarzon.netlify.app |
GitHub: github.com/MychelGarzon