My automations break. So I built an agent that fixes them.
I run a lot of workflows in n8n, and like everyone here, some of them break. Instead of babysitting them, I wired up an agent that catches the failure and repairs it end to end.
How it works:
A global Error Trigger workflow catches any failure across my instance and hands the error off to a LangGraph agent.
The agent triages the error and drafts a fix with one model (Claude, in my setup).
The fix goes to a different model from another vendor (an OpenAI model) to independently review and approve it. No single model marks its own homework. This cross-vendor gate is the whole point.
Only after approval does the agent write the fix back through the n8n API (snapshot-first, so there’s a one-call rollback) and re-run the workflow to confirm it actually worked.
In the demo I break a workflow on purpose (a Code node throwing a ReferenceError) and let the agent repair it. It triaged, proposed, got the fix approved, wrote it back, and the workflow ran clean and posted to Slack. The whole run cost under 6 cents, and every step is traceable in LangSmith.
I triggered this run by hand so it’s easy to follow, but it’s built to fire automatically the moment a new error lands. It’s still in testing and I’m keeping it that way on purpose, but the autonomous loop is the goal.
The part I’d push on for anyone building something similar: when an agent acts on its own inside your systems, you have to be able to see exactly what it did. Observability isn’t a nice-to-have, it’s the architecture. The cross-vendor review gate matters for the same reason.
Happy to go deeper on any part of it. Curious if anyone else is doing auto-remediation off the Error Trigger, and how you’re handling the “should the agent be allowed to write this back” question.
This is a great approach. The key thing that makes it work is the combination of automatic detection, independent validation, and rollback capability.
For anyone implementing something similar, I’d recommend treating the Error Trigger as the central monitoring layer, keeping workflow snapshots before every change, and only allowing fixes to be deployed after they pass validation from a separate model. That creates a reliable feedback loop where workflows can recover automatically while still maintaining control and traceability.
The rollback mechanism is especially important because it ensures any incorrect fix can be reversed instantly without disrupting operations. Combined with LangSmith observability, this provides a practical framework for self-healing automations that can scale without constant manual intervention.
So I have a global error handler that pings the execution and workflow API every 5 min to surface errors to my control plan application I built. The LangGraph agents run containerized within this control plane
Really like this — the cross-vendor approval gate is the part I’d steal. To your question about whether the agent should be allowed to write back: the way I’ve come to think about it is that the write-back is less scary than the rollback. A bad fix that gets caught and reverted is fine; the thing that actually keeps me up is whether the rollback itself is guaranteed to be there when you need it.
Which makes me curious about your snapshot — where does it live? If it’s stored through the same n8n API the agent writes back to, is there a path where a bad run could clobber both the state and the snapshot in one go? Or have you put it somewhere out of the agent’s reach? Genuinely asking, because that separation feels like the hard part of making something like this safe to run unattended.
How are you scoping the agent’s API permissions, by the way — full read/write, or narrowed per run?
That reframing is exactly right, and it’s where my head is too. A bad fix that gets caught and reverted is a non-event. The whole thing leans on the rollback actually being there, so poking at the snapshot is the right place to poke.
Where it lives: on the agent’s own disk, not in n8n. The sequence is snapshot, then write, then verify, and the only thing the agent ever sends through the n8n API is the patched workflow itself. The snapshot is a separate file in the agent’s own store and is never written through n8n, so there’s no single call that can touch both the live workflow and its snapshot. A bad fix can corrupt the workflow in n8n. The rollback source sits in a different system and is untouched by that write.
Two honest caveats, since you’re asking the right question:
The snapshot is “last good as of the moment before this run,” not a pristine historical baseline. It’s captured by reading current state, so the protection is per-run. If something slipped through earlier, the snapshot captures that too.
Today that store is local disk on the agent. Different failure domain from n8n, which is the property you want, but not yet offsite or immutable. For genuinely unattended operation that’s the next hardening step: a durable, append-only snapshot store, plus an explicit abort if the snapshot didn’t persist before the write.
On permissions: today it’s one n8n key with full read/write, not narrowed per run. The public API key is instance-scoped, so there’s no per-run or per-workflow write token to hand it (honestly, that would be a great thing for n8n to support). What narrows the blast radius isn’t the key, it’s the layer around it. The model never holds the key and never calls a workflow-mutating tool. It only writes text. The snapshot, the write, and the verify are deterministic code, and every patch is scoped to the single diagnosed node and run through a deterministic diff gate before the PUT. So the key can do anything, but the one code path that uses it only ever ships a single-node, gate-checked change. For unattended runs I’d also put it behind a dedicated service account on a private network rather than a person’s key.
Full writeup and the deck if you want to go deeper:
The cross-vendor gate is yours to steal. The honest version is that the gate plus the snapshot contract is what makes it safe to leave alone, and the snapshot contract is the half I’m still hardening.
Read the deck — the deterministic diff gate is the part that stuck with me. The four red lines as pure functions with tests, sitting after the model review and trusting no model to catch a malicious change, is a much stronger guarantee than the cross-vendor gate alone. “The model that writes never grades it” plus “the code, not a model, enforces the red lines” is the right layering.
Which is why your two snapshot caveats stood out to me, because they’re the one place that same rigor isn’t fully closed yet. You’ve got the failure-domain separation right (snapshot on the agent’s disk, never through the n8n API), but “last good as of this run” on local disk is the soft spot you flagged yourself. The thing I’d reach for: an append-only, offsite store with the abort-if-snapshot-didn’t-persist check as a hard gate before the write — same “deterministic, trust nothing” philosophy as your diff gate, just applied to the rollback source instead of the patch. That closes the last gap toward genuinely unattended runs: a rollback that survives the agent’s disk dying and gives you real historical baselines instead of only the pre-run state.
The instance-scoped API key limitation is real, agreed — narrowing the blast radius at the code path rather than the key is a pragmatic answer until n8n ships per-workflow tokens.
The cross-vendor approval gate is a smart safeguard - makes it much harder for a hallucination to pass both independently. One practical thing worth adding: a circuit breaker check at the start of the error-handler to make sure it’s not responding to a failure from itself. You can do this with a simple IF node checking $json.workflow.name against the error-fixer’s own name, and if they match, send a Slack alert instead of triggering the repair loop. Saves you from infinite failure cascades when the agent hits a bug it can’t fix.
That’s actually a GREAT idea! Only issue I can see, it the error handler is failing it wont surface the error and thereby the agent will never get the webhook to kick it off
WOW, Phenomenal build! Babysitting broken production workflows is the worst part of automation, and this is a masterclass in solving it. Using Claude to draft and OpenAI to peer-review is such a clever way to handle validation. I can’t admire this enough.
This was more of an exploration of what could be done. In my experience my n8n workflows don’t randomly break unless a key expires or I get rate limited somewhere. The chances of a code node or logic breaking are slim to none, and as cool as this is it still can’t fix authentication issues…hmmmm well maybe if I give it access to Infisical which I have for my secret management, I could actually have it rotate the key there…hmmmmm
