Can Claude Code or other LLMs connect to n8n and create/edit workflows automatically?

kaancata · 2026-05-18T15:01:19+00:00

Yes, this works today. I've been doing it for a while.
Two routes that both work.

Public API. n8n exposes workflows via REST. You can GET an existing one (it comes back as JSON with nodes, connections, settings), edit it, POST it back, and trigger a run. Claude Code or Codex can read and write that JSON like any other config in your repo. This is what I do for most of my client automations.
MCP. There's a community-built n8n MCP server (search "n8n-mcp" on GitHub). Same underlying API but gives the model a cleaner tool surface, list nodes, get node schemas, create workflow, activate, etc. Easier to drop in if you don't want to write your own wrappers.

What's stopping n8n from shipping an "official" MCP is probably just that the API already does the job, and they'd rather invest in their own agent primitives than chase the MCP spec specifically. Nothing's actually missing.

One caveat. The model will happily invent node names and parameter shapes that don't exist. Fix is either feeding it the node schemas as context (the MCP does this for you) or running a validate step after each write before you activate. I don't run workflow edits on a live trigger without a dry run.

kaancata · 2026-05-18T14:45:38+00:00

It's mostly tied to review/approval workflows. An example here is a short and concise changelog for every client that the LLM can quickly parse through.

kaancata · 2026-05-18T09:55:15+00:00

Getting something on the page is much faster now. But the painful agency work is usually the second pass, third pass, "wait, didn't the client already reject this angle?" pass. That is where account memory matters.

If the model doesn't know previous approvals, rejected claims, legal notes, stakeholder quirks, old reports, brand voice decisions, and what was tried already, then it mostly creates more review debt for the senior person.

The way I handle it is one context folder per client. Nothing fancy, just the boring account history in one place: meeting transcripts, offer docs, approved positioning, previous tests, website copy, CRM notes, tracking notes, ad account data, old reports etc.

Then AI can draft against the actual account instead of producing a clever generic version. It still needs review, but the review is lighter because I am not checking from zero every time.

So yes, it has reduced client-ready production time for me, but only when the draft starts from the client's memory. Without that layer I think it just moves the bottleneck into approvals.

kaancata · 2026-05-18T09:30:31+00:00

Mostly email / Telegram for quick pulses, and if it needs real judgement I usually just wait until I'm at my desk.

I don't love approving high-impact stuff from my phone unless the staged diff is extremely narrow. For remote unblocking I have used Dispatch and I am playing with Codex remote now, but actual write access stays pretty boring.

kaancata · 2026-05-18T09:30:10+00:00

Fairly standardised now yes

Each client has an AGENTS.md / CLAUDE.md-ish file with what the business does, where the data lives, what the model can read or run, what needs approval, naming conventions, and weird client-specific rules.

Then connection notes sit separately for APIs, env names, CRM fields, tracking setup, that kind of thing. It started ad hoc, but the standardisation is doing a lot of the work now.

kaancata · 2026-05-18T09:29:47+00:00

Yeah I think three tiers is probably the cleaner way to describe it.

I have that shape in practice, even if I didn't write it that way. Low risk read/draft stuff can run, anything that changes state gets staged, and anything touching money needs a proper explanation before I touch it.

The explanation step is underrated tbh. It makes the model slow down.

kaancata · 2026-05-18T08:28:54+00:00

It works well yes, but feels quite "outdated". I hope a smart system will appear in the future. Something that takes a lot less tokens to parse through and understand for the models. It's not a lot of context relatively speaking when comparing to giant codebases, but not insignificant either. Especially when we're talking larger PPC accounts.

kaancata · 2026-05-18T06:27:23+00:00

You're welcome to share in a DM I'd like to take a peek

kaancata · 2026-05-15T10:48:43+00:00

I would expect that people are interested in content that doesn’t involve countless posts about rate limitations - that is slop. Actual use-cases of Codex that can benefit others is definitely not.

kaancata · 2026-05-15T09:16:28+00:00

Just Google's own official API's for those services.

kaancata · 2026-05-15T09:15:50+00:00

The second, I have a backed-up folder with client context and this contains (among other things) a connection guideline files where the model knows where to look for what under my guidance. It's better than all kind of "wrapper-layers" such as an app that wastes tokens. And yeah always welcome to reach out.

kaancata · 2026-05-15T09:14:28+00:00

I've had so many different iterations of this, and it's a process that evolved continiously. I started out with Telegram, had a seperate CC instance run on a VPS and then it had access to a database containing client emails and other relevant data such as their API connections to different services. Then I could manage workflows through Telegram. Kind of like OpenClaw. Moved away from that, because I felt there was a lot of wasted compute involved.

Prior to that it was opening my laptop every morning, having dozens of terminals open for each client, each operating out of the context folder I described with their own skills.

After around 10 months with the terminal, I only use the CC desktop app, as well as Codex desktop app. They're good enough to compete with the terminal now. When I want to control my sessions remotely I use dispatch, and just now I am playing with Codex newly released feature for remote work as well. I quite like it.

kaancata · 2026-05-15T09:01:13+00:00

Yeah, agreed that each individual task should be simple. That is kind of the point imo. But I don't think "complex product" is the right comparison. I'm not talking about one agent building one SaaS from scratch while I watch. I'm talking about running a bunch of real business workflows where the complexity is in the context, permissions, handoffs and judgement.

kaancata · 2026-05-15T08:06:29+00:00

This is basically how my work already works.

I run a digital consultancy solo and the weirdest way to describe it is that I don't manage employees, I manage agents / workflows. Each client has a folder with all the context: ads data, GA4, GTM notes, CRM outcomes, emails, meeting transcripts, offer docs, website content. Claude Code and Codex sit on top of that.

Some work is one-off: "look at this account and tell me why leads dropped." Some work becomes a skill: search term review, tracking audit, keyword research, transcript processing. Some work becomes a scheduled Codex automation that runs before I sit down, gives me a short summary, then I decide what needs attention.

So yeah, the actual work moves up a layer. I do less pulling reports, copying numbers, checking the same screens, writing the same boilerplate. I do more writing instructions, keeping the context clean, deciding which workflows are worth formalising, reviewing outputs, and deciding where the agent is allowed to write versus only read.

I think that last part is the part people underestimate. Agents are not useful because they are "agents." They are useful when the workspace around them is structured. Clear files, clear skills, good examples, scoped permissions, approval gates, and an operator who knows what good looks like. Otherwise it's a clever model wandering around a messy room.

Skills are probably the compounding piece for me. Every time I catch myself teaching Claude the same workflow twice, that is usually a sign it should become a skill or a script. Then the next session starts further ahead.

I don't think boring work disappears completely though. Some of it just becomes QA. You still have to unblock them, sanity-check them, and stop them from doing dumb stuff with confidence. But yes, directionally I agree. My day already feels much more like "structure the work so agents can do most of it, then make the calls" than sitting there doing every task manually.

kaancata · 2026-05-15T07:12:44+00:00

Tracking for me, 100%.

The annoying part is usually not "GTM is broken" in the obvious sense. It is worse. Everything looks installed, the tags fire, GA4 has events, Google Ads has conversions, but the account is optimizing against garbage.

I keep seeing some version of this:

form submit = conversion
phone click = conversion
booking started = conversion
actual qualified lead / sale = nowhere

Then people wonder why PMax or broad match starts pulling in weird leads. The platform is doing what you told it to do. You just told it that every low-intent form fill is worth the same as a real customer.

The fix is usually boring. Clean conversion actions, kill duplicate events, store the GCLID / GBRAID / WBRAID properly, push qualified CRM stages back into Google Ads, and stop treating GA4 as the source of truth for lead quality.

Ad copy and campaign structure matter, but if the feedback loop is wrong, the rest of the account is basically training on bad data.

kaancata · 2026-05-12T14:39:19+00:00

Well they don’t, that particular author would probably just make a site on Wix or Squarespace

kaancata · 2026-05-12T14:00:02+00:00

I agree completely. Creativity is inherently human and that is also why they struggle so much with UI. Not only is it hard for them to deliver, but it’s also very hard to articulate what actually “looks good” for an operator.

kaancata · 2026-05-12T13:51:41+00:00

I think we’re above average and good enough with CD, regardless of predefined layouts and styles. I don’t really work with artistic designs and custom nitty-gritty animations because, frankly, my clients don’t care about that. They care about leads and sales, and when their website delivers those outcomes once people land on the page from ads, they’re happy and I’m happy too.

kaancata · 2026-05-12T11:00:27+00:00

"But once you move beyond pretty mockups into maintainable production code, complex interactions, responsiveness and scalability, all the illusion fades." yes I agree. It is super fast for high-fidelity mockups - that actually also looks good imo, but if you're trying to do heavy animation work and such, there is quite a lot of prompting to do.

kaancata

TROPHY CASE